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>
Revert "Always run javadoc using the ToolProvider API"
This reverts commit f70aeb5e, except for some commented-out parts of
code and an unused method. I also simplified the code, e.g. with regard
to exception handling, and did some more cosmetic stuff, but basically
it is a revert.
In order to make it compile on more recent JDKs which doe not have class
com.sun.tools.javadoc.Main, I used Class.forName in the method being
called on JDK 8 only.
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>
In order to keep developers from creating AspectJ releases manually or
using Ant script 'build/build.xml', get rid of all POM templates. This
step does not involve updating any build or release how-to documents or
any other clean-up work under 'build', but it is a first step and a
simple, implicit reminder that now we can build and release using Maven.
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>
Even with the 'release' profile, it is not necessary to sign each
artifact, because only the ones to be published on Maven Central need
signatures.
Similarly, make Nexus staging deployment to Sonatype OSSRH dependent on
'maven.deploy.skip' and skip staging for non-public artifacts.
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>
Replace links to aspectj.org by links to eclipse.org/aspectj
As discussed with Andy Clement, domain aspectj.org seems to still be
owned by Xerox, and currently no website for it is online. Therefore, it
is better to link to the AspectJ Eclipse homepage.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Revert "use the alternate maven settings by default"
This reverts commit @95fc5eec, because that commit was only helpful
before merging branch 'migrate-to-aspectj-dev' with PR #49, but was
actually committed afterwards, making it obsolete.
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>
There is a strange effect in Maven builds: Depending on which profiles
are active when building the project - even seemingly unrelated ones
like 'create-docs' or 'clean-libs' - the execution order of plugins in
the 'process-resources' phase can vary. Specifically, Build Helper vs.
Enforcer in module 'lib', which both were in the same phase, can
sometimes be executed in lexical order, which I expected, or the other
way around, which makes the build fail if the existence of the marker
file is checked by Enforcer before Build Helper even had a chance to
create it. Probably, this is because Build Helper is defined inside a
profile and Enforcer outside of any.
Therefore, the safest way to ensure correct ordering of the two is to
place Enforcer in a later phase, in this case 'compile'.
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>
In the previous GitHub build, there were warnings in the log because of
failed downloads. Actually, the default is to fail the build, but that
did not happen. Let us try a more recent version, maybe it fixes an old
bug, even though in the diff between the versions I did not see anything
obvious here.
Anyway, I created an issue ticket:
https://github.com/maven-download-plugin/maven-download-plugin/issues/185
BTW, our build only failed later during the Maven Enforcer sanity check,
because several files from the check list were missing after a seemingly
successful provisioning. Actually, I am glad I added this "redundant"
double-checking step to the build, otherwise the build would not have
failed in the 'lib' module but much later in a hard to detect spot.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Upon special request by Andy Clement, I included 'lib' as a child module
in the parent POM again, making several modules which refer to
downloaded library files dependent the 'lib' module. I am not sure I
caught all of them, but I hope so.
Now after cloning the project and configuring the token for reading from
GitHub Packages (sorry!), you can just run a Maven build for the main
project and no longer need to fail the first build, read the Maven
Enforcer message and run 'cd lib && mvn compile' as a first step. This
convenience comes at the price of a more complex POM and two new
profiles:
- Profile 'provision-libs' is auto-activated by the absence of a
marker file, kicking off the library provisioning process and
creating same marker file at the end, if successful. Therefore,
during subsequent builds libraries will not be re-provisioned,
because the marker file exists and Maven skips all download and
(un)zip steps, which saves build time and bandwidth. Otherwise
offline builds would not work either.
- Profile 'clean-libs' needs to be activated manually, because by
default 'mvn clean' will not erase provisioned libraries. In most
cases, even after a clean a developer does not want to re-provision
all libraries if they have not changed (e.g. new JDT Core build).
But if you do wish too erase the libraries and the marker file, just
call 'cd lib && mvn -P clean-libs clean'.
Please note: The Maven Enforcer build step, which additionally checks
for existence of other files, still exists and was moved from the parent
POM to 'libs'. No matter if provisioning was just done or skipped
because the main marker file exists, a quick heuristic check for that
list of files is done during each build, failing the build with a
comprehensive message if an inconsistency was found. The error message
says which files are missing and tells the user:
"There is an inconsistency in module subdirectory 'lib'. Please run
'mvn --projects lib -P clean-libs clean compile'. This should take
care of cleaning and freshly downloading all necessary libraries to
that directory, where some tests expect them to be."
This should cover the topic.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch
Andy Clement