Before, the Maven Clean configuration overrode the one from the parent
POM. Now it leaves it intact, adding a separate module-specific
execution to delete the downloads and libraries.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Module 'asm-renamed' now deploys to GitHub Packages
This means that instead of a system-scoped dependency we now have a
regular one.
The 'libx' module also downloads binary and source JARs redundantly into
the libraries directory in order to be found there by other scripts and
tests.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Replace JDT Core system dependency by deployed one
Get rid of system paths. Instead, rely on JDT Core Shadows to deploy
both binary and source JARs to GitHub Packages. The former module
directory was deleted completely. Instead, the JARs are redundantly
copied into 'libs/jdtcore-aj' in order to be found there by tests and
other Ant scripts.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Build libs without additional profiles, add Enforcer rule
Because 'libx' no longer is a submodule of the AspectJ parent POM, it
will not be built automatically each time an AspectJ build runs.
Therefore, is is no longer necessary to shield the zip/unzip steps from
repetitive execution by profiles with auto-activation based on the
(non-)existence of files. An AspectJ developer knows when to build the
module, she does it manually anyway.
A new Enforcer rule makes sure to warn the developer if some files it
expects to exist in the libs folder are not actually present.
Now we also have a Maven Clean rule which wipes away all downloaded and
(un-)zipped files.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Replace system-scoped dependency on commons by granular dependencies
There are only two direct dependencies used in AspectJ code:
- Commons Digester (module 'testing')
- Commons Logging (module 'org.aspectj.matcher')
I declared those two and experimentally removed all the other
system-scoped dependencies, as it should be. Let's see if the build
works with transitive dependencies.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Recreate lib/commons from Apache Commons downloads
Project archeology, binary and source code comparisons of contents in
lib/commons/commons.jar and lib/commons/commons-src.zip yielded the
following results:
- All binaries are available on Maven Central in 4 different legacy
Apache Commons dependencies:
* commons-beanutils:commons-beanutils:1.4
* commons-collections:commons-collections:2.0
* commons-digester:commons-digester:1.3
* commons-logging:commons-logging:1.0.1
- Those Maven Central binaries are not accompanied by source JARs,
i.e. in order to recreate lib/commons/commons-src.zip we have to
download source archives from the corresponding Git tags. All
projects are available on GitHub, so it is possible to download them
using Maven Download Plugin.
- Both the compound binaries and compound sources archives currently
checked in in AspectJ can be recreated using TrueZIP Maven Plugin.
This is rather tedious and involves additional Maven profiles in
order not to generate the compound archives during every build, but
fully implemented now.
Unfortunately, all of the above does not make the system-scoped
dependency on commons.jar obsolete. In order to achieve that, we either
have to publish the compound files on Maven Central or GitHub Packages,
or we find out which AspectJ modules use classes from which of the 4
individual Apache Commons packages and replace the compound system
dependency by the relevant single dependencies. Probably I am going to
try that in a next step.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Recreate lib/ant from Apache source/binary downloads
- Download Ant 1.6.3 binaries and sources ZIPs from Apache releases
download server
- Verify expected SHA-1 checksums
- Unpack binary distribution
- Repack main sources into source package as it is checked in now
- Redundantly add JUnit JAR in order to 100% replicate existing
directory layout
- Move downloads from 'validate' phase to 'generate-resources'
- Unpack/repack phase is 'process-resources'
- Make sure that download, unpack, repack only occur if necessary
instead of overwriting existing artifacts during each build
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>