Add docs/dist/LICENSE-AspectJ.html to all public artifacts
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>
Document build profiles and properties in docs/developer/BUILD.md
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>
This is a bugfix release, reverting the essential parts of commit
f70aeb5e, because it causes AspectJ Maven integration tests using
javadoc to fail on JDK 8.
See commit discussion on
https://github.com/eclipse/org.aspectj/commit/f70aeb5e#commitcomment-51417353
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix Javadoc generation by also unpacking relocated ASM sources
Suddenly, for AspectJ Weaver + Tools Javadoc generation started to fail.
This might be due to switching from ASM-renamed to dynamically shaded
ASM. Either way, the Javadoc tool complains about the missing source
files. Therefore, we also unpack them from the source uber JAR now via
TrueZIP before generating Javadoc.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Upgrade Maven Shade Plugin to 3.2.4.MSHADE-252-391
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>
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>
This involves replacing references in weaver application code as well as
a few tests.
In order to make AspectJ weaver + tools contain a relocated ASM version,
I added a Maven Shade relocation step after Maven Assembly created the
uber JARs. Relocation works for both binaries and sources and also
encompasses Class::forName calls like in class AsmDetector.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
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 dependencies
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 POMs
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 2
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>
I tripped over not finding aspectjtools in my IntelliJ Maven view many
times, because it was listed as "AspectJ Compiler". So I renamed it to
"AspectJ Tools (Compiler)". Now it resembles more the artifact ID and
still retains the information that it is the artifact containing AJC.
For the 'lib' module I removed the 'name' tag again, because it is not
one of the main artifacts we publish. Now the POMs are more like Andy
might have intended them to be, using a human-readable 'name' only for
the main artifacts.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>