aboutsummaryrefslogtreecommitdiffstats
path: root/aspectjrt
Commit message (Collapse)AuthorAgeFilesLines
* Set version to 1.9.23-SNAPSHOTAlexander Kriegisch2024-03-231-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release AspectJ 1.9.22Alexander Kriegisch2024-03-231-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.22-SNAPSHOTAlexander Kriegisch2024-03-131-1/+1
|
* Release AspectJ 1.9.21.2V1_9_21_2Alexander Kriegisch2024-03-131-1/+1
|
* Run Antrun post-javadoc task depending on Javadoc executionAlexander Kriegisch2024-02-171-2/+3
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Use Antrun plugin to eliminate javadoc version number in HTMLAlexander Kriegisch2024-02-171-0/+13
| | | | | | | | | | This is the one issue that cannot be solved regarding reproducible builds by setting javadoc options, because that header comment is hard-coded into the JDK with no option to avoid it. I just created an OpenJDK issue (internal review ID 9076583, not published yet) for it, but that does not help us today. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.22-SNAPSHOTAlexander Kriegisch2024-02-141-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release 1.9.21.1V1_9_21_1Alexander Kriegisch2024-02-141-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* DRY: Centralise common Maven Javadoc configurationAlexander Kriegisch2024-02-011-8/+0
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Update assemblies to include AspectJ licenceAlexander Kriegisch2024-01-062-4/+4
| | | | | | | | | | | | | | | | | | | | | | The former HTML file was moved up one directory level and converted to asciidoc format. Therefore, include the ADOC file from the correct location now. Alternatively, we could have included the generated HTML from the aj-build/dist/docs/doc directory, but that would have meant adding a dependency to the 'docs' module to several other modules for this one file. Actually, asciidoc has become a widely used and accepted format for documentation and is human-readable by design. Therefore, it is OK to include the ADOC file. The important thing is that the licence information - is contained in each published artifact, - can be found easily, - its content is human-readable. All these requirements are still met with this change. Arguably, ADOC is easier to read than HTML and does not even need a web browser. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add runtime and weaver API javadocs to installer againAlexander Kriegisch2024-01-061-0/+28
| | | | | | Closes #271. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.21.1-SNAPSHOTAlexander Kriegisch2023-12-151-1/+1
| | | | | | | Currently, the situation looks more like a Java 21 maintenance release than directly a Java 22 release. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.22-SNAPSHOTAlexander Kriegisch2023-12-111-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release AspectJ 1.9.21V1_9_21Alexander Kriegisch2023-12-111-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.21-SNAPSHOT againAlexander Kriegisch2023-12-021-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release candidate 1.9.21.RC1V1_9_21_RC1Alexander Kriegisch2023-12-021-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version 1.9.21-SNAPSHOTAlexander Kriegisch2023-11-191-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release milestone 1.9.21.M1V1_9_21_M1Alexander Kriegisch2023-11-191-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.21-SNAPSHOTAlexander Kriegisch2023-09-041-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* AspectJ release 1.9.20.1Alexander Kriegisch2023-09-041-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.21-SNAPSHOTAlexander Kriegisch2023-08-161-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release 1.9.20V1_9_20Alexander Kriegisch2023-08-161-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.20-SNAPSHOTAlexander Kriegisch2022-12-211-1/+1
|
* AspectJ release 1.9.19V1_9_19Alexander Kriegisch2022-12-211-1/+1
|
* Set Maven version to 1.9.19-SNAPSHOTAlexander Kriegisch2022-10-021-1/+1
| | | | | | | It makes sense to indicate the Java version in the minor-minor of AspectJ artifacts. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add docs/dist/LICENSE-AspectJ.html to all public artifactsAlexander Kriegisch2022-10-012-2/+14
| | | | | | | | | | | | | | The license file will be included right in the main directory of both binary and source artifacts for - AspectJ Matcher, - AspectJ Runtime, - AspectJ Weaver, - AspectJ Tools (Compiler), - AspectJ Installer. Fixes #185. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.10-SNAPSHOTAlexander Kriegisch2022-03-311-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Release AspectJ version 1.9.9.1V1_9_9_1Alexander Kriegisch2022-03-311-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.10-SNAPSHOTAlexander Kriegisch2022-03-241-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.9V1_9_9Alexander Kriegisch2022-03-241-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.9-SNAPSHOTAlexander Kriegisch2022-02-111-1/+1
|
* Set version to 1.9.8V1_9_8Alexander Kriegisch2022-02-111-1/+1
|
* Set version to 1.9.8-SNAPSHOTAndy Clement2021-06-241-1/+1
|
* 1.9.7 releaseV1_9_7Andy Clement2021-06-241-1/+1
|
* Document build profiles and properties in docs/developer/BUILD.mdAlexander Kriegisch2021-06-101-0/+3
| | | | | | | | | | | | | | | | | | | In doing so, I also noticed a few things in need of improvement. So, documenting the build also drive those enhancements, such as - the new 'fast-build' profile skipping test compilation and execution as well as documentation generation, - an option to skip generating source assemblies, - to skip unzipping source assemblies if javadoc generation for them is to be skipped too, - activating the 'create-docs' profile by property which is true by default instead of using 'activeByDefault=true', because the latter does not work reliably if other profiles are activated manually according to a Maven bug that was closed as "won't fix", - no longer generating separate javadocs for the 'runtime' module, because that module is not deployed and the main artifacts recreate Javadocs from scratch for all of their constituent sources anyway. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Upgrade license from CPLv1/EPLv1 to EPLv2Alexander Kriegisch2021-06-041-2/+2
| | | | | | | This was required by the Eclipse team as one precondition for the next release. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.7-SNAPSHOT againAlexander Kriegisch2021-05-241-1/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set version to 1.9.7.M2V1_9_7_M2Alexander Kriegisch2021-05-241-1/+1
| | | | | | Also depend on JDT Core 1.9.7.M2 Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Upgrade Maven Shade Plugin to 3.2.4.MSHADE-252-391Alexander Kriegisch2021-05-241-1/+0
| | | | | | | | | | Unfortunately, the issues fixed in the aspectj.dev fork are still not available upstream (MSHADE-252 is merged, but unreleased, MSHADE-391 is in review). Also use Maven Javadoc Plugin version from parent POM. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* housekeepingAndy Clement2021-05-231-0/+35
|
* Use canonical snapshot version 1.9.7-SNAPSHOTAlexander Kriegisch2021-05-231-1/+1
| | | | | | | | | Before, we used 1.9.7.BUILD-SNAPSHOT, which according to Andy Clement was originally an intent across a group of Spring projects he was involved in, to ensure that SNAPSHOTS were sorted alphabetically ahead of MILESTONEs and ahead of RCs. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix selective Nexus deployment to Sonatype OSSRHAlexander Kriegisch2021-05-161-0/+6
| | | | | | | | | | | Other than Maven Deploy, Nexus Staging plugin cannot just be added to the 'build/plugins' section of the parent POM once and (de-)activated with a simple property like 'maven.deploy.skip' on a per-module basis. See also https://issues.sonatype.org/browse/OSSRH-68966. Consequently, we do not add it to the parent but separately to each module meant to be published. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Create javadoc for all public artifacts, fix dependenciesAlexander Kriegisch2021-05-161-8/+62
| | | | | | | | | | | | | | | | | | | | | | Sonatype OSSRH repository rules require source and javadoc JARs in order to create staging repositories for releases to be promoted to Maven Central. So I added build steps to unzip the source JARs and then create Javadocs for them. FIXME: This configuration works with JDK 16, but throws errors on other JDK versions, e.g. 14. It looks as if the Maven Javadoc plugin does not do a particularly good job applying the plugin settings in a way making it work with different JDK javadoc tool versions. I am saying that, because when using the tool directly on the console, it works with basic settings and the correct classpath. In order to enable creating uber JARs via Maven Shade in the future, I also added missing dependencies. Maven Assembly descriptors just assume that all the necessary class files and sources already exist where it copies them from. But several of the dependency modules were not explicitly listed as such by the uber JAR modules. I fixed that. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add information required by Maven Central to public artifact POMsAlexander Kriegisch2021-05-161-2/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | This is another step away from manual deployment towards Maven-triggered deployment for both releases and snapshots. The 5 main POMs (matcher, runtime, weaver, tools, installer) now contain information required by Sonatype for Maven Central deployments according to: https://central.sonatype.org/publish/requirements/ TODO: - Add corresponding 'distributionManagement' section and necessary release plugins for Sonatype OSS repositories to parent POM. - Enable Maven to also use Install plugin in order to automatically set release versions, commit to Git and tag releases, then upgrade to a new snapshot afterwards. - Make sure that Flatten Maven plugin does not strip off the required tags we just added to the POMs. It looks as if the chosen flattenMode=oss already retains the exact tags we need, only slightly reformatting (hence "uglifying") the POM. But an ugly POM does not block Maven Central deployments, as long as it is complete. So it looks as if this to-do item is already done. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Prepare main artifacts to be deployed via Maven, step 2Alexander Kriegisch2021-05-081-0/+5
| | | | | | | | | | | | | | | | | | | | This change affects the following modules: - aspectjmatcher - aspectjrt - aspectjtools - aspectjweaver - installer - asm-renamed Set maven.deploy.skip=false in parent POM, i.e. Maven Deploy by default will *not deploy anything. Only in the modules above, we change the value to 'true' in order to deploy those artifacts. This setting works for both snapshot repositories (GitHub Packages, soon to be migrated to aspectj.dev in a separate PR) and release repositories, i.e. in the future also for Maven Central. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Prepare main artifacts to be deployed via Maven, step 1Alexander Kriegisch2021-04-261-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change affects the following modules: - aspectjmatcher - aspectjrt - aspectjtools - aspectjweaver - installer They have in common that they all use Maven Assembly Plugin in order to create some kind of uber JARs with constituent modules and/or libraries. Except for the installer, they are all available on Maven Central today, but I think it would not hurt to deploy the installer to there, too. Changes made: - Use Flatten Maven Plugin in order to create simple POMs with only basic information and - most importantly - without dependencies. - The new dependency-reduced POM (DRP) or "flattened POM" gets attached to the build, i.e. it will be installed and deployed as a replacement of the original POM. - Attaching the DRP only works for 'jar' type modules, which is why I changed the packaging type for each module from 'pom' to 'jar'. - Deactivate generation of the default JAR for each module. This is necessary now, since we have the 'jar' packaging type. - Make sure that assembly descriptors using 'dependencySet' entries have set option 'useProjectArtifact=false' in order to avoid warnings about the non-existing main artifact. TODO: - Explore option to migrate from Maven Assembly to Maven Shade, because it does not need descriptor files, can also generate source JARs and can automatically create and attach a DRP which is less fragmentary than the one created by Flatten Maven, basically the original JAR minus the dependencies. - If in the future we want to make sure to only deploy the modules listed above, e.g. to Maven Central, if simply calling 'mvn deploy' for the whole project, we could use 'maven.deploy.skip=true' in the parent POM and override it by 'maven.deploy.skip=false' just in the few modules which need to be deployed. See also: https://stackoverflow.com/a/29574812/1082681 Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix: make sure that source assemblies are attached to buildAlexander Kriegisch2021-04-172-4/+5
| | | | | | | | | | | | Previously I renamed the source assemblies from the uniform name 'sources' to something more individual like 'aspectjtools-sources', not realising that the magic name 'sources' in combination with the default configuration value 'appendAssemblyId=true' results in an artifact classifier equal to the assembly ID, i.e. 'sources', which is exactly what we need here, but not quite obvious. Therefore, I documented it with comments in both the assemblies and the POMs. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Use dependencies instead of copies under 'lib' for assembliesAlexander Kriegisch2021-04-162-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is one step to get rid of org.aspectj:org.eclipse.jdt.core and org.aspectj:asm-renamed in the 'lib' directory. AspectJ tools + weaver uber JAR builds now use dependencies in the POM in order to deal with creating binary + source assemblies. They no longer rely on manually updated copies under 'lib'. Details: - Binaries are copied via 'dependencySets' in the assembly descriptor. - Sources are unzipped via Maven Dependency Plugin before including them into the source uber JAR via assembly descriptor. - NEW: This also includes ASM-renamed sources which so far were ignored. It is a positive side-effect from the fact that for ASM-renamed Maven Shade automatically creates a source JAR. - Maven Ant Run is no longer used for unzipping binary + source JARs. - While working in parallel with JDT Core and AspectJ it is now much easier to produce up to date artifacts, e.g. for consumption by AJDT, because it does not matter anymore if we forget to run the build in module 'lib' in order to update the JDT Core copy. Status quo: - Folder lib/asm is no longer used and will be removed in a subsequent commit. - Folder lib/jdtcore-aj is no longer used by the Maven build, but still referenced in a few UNIX shell scripts and Ant build files. TODO: Find out if those are still actively used. If yes, refactor them to look for the file in the local Mavven repository. Otherwise, delete the referencing files and also lib/jdtcore-aj. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Manage version version maven-assembly-plugin:3.1.1Alexander Kriegisch2021-04-161-5/+1
| | | | | | No more manual version setting everywhere. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add link to JDK-8263924 bug ticket to POMs using maven-assembly-pluginAlexander Kriegisch2021-03-221-0/+3
| | | | | | | | This is a follow-up on commit @0b182d60. I have just received confirmation from Oracle that my issue was accepted: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263924 Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-23 03:06:44 +0000