Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

We are not using Jupiter yet, but this is nice to have for the future.
Thanks to @larsgrefer for his initiative to prepare AspectJ for
JUnit Jupiter and for his other PR which also contains the same change
in the parent POM. :-)

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

In module 'tests', our tests need Ant launcher. Hence, dependency
ant:ant-launcher was re-added to the POM (with test scope this time)
and Maven Dependency plugin configured to regard it as a used
dependency and not falsely report it as unused.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

In module 'ajdoc', our tests need tools.jar when running on JDK 8 in
order to dynamically compile during runtime. Hence, dependency
com.github.olivergondza:maven-jdk-tools-wrapper was re-added to the POM
(with test scope this time) and Maven Dependency plugin configured to
regard it as a used dependency and not falsely report it as unused.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Notably, this change involves a partial revert of @4a5660b3, because we
are not using JUnit Jupiter yet but still JUnit 4 tests. See discussion
under commit at https://github.com/eclipse/org.aspectj/commit/4a5660b3.

Many other warnings - concerning both used undeclared and unused
declared dependencies - were eliminated by adding or removing the
corresponding dependencies from the POMs. Furthermore, I tried to make
sure that some clearly test-scoped dependencies are now actually
declared as such, so as to avoid unwanted transitivity bleeding into
compile scope and maybe unwanted classes ending up in uber JARs via
Maven Shade or Maven Assembly.

TODO: I am not so sure why modules other than 'run-all-unit-tests' would
depend on test JARs. I hope I broke nothing essential there. As of
today, the other modules where I found '<type>test-jar</type>'
dependencies are:
  - ajde
  - testing
  - testing-drivers
  - tests
  - weaver

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

An image which should be in its own paragraph was shown inline with the
text, somewhere to the right in the middle of a text paragraph. I
noticed while visually checking if docs generation still works as
expected after the last few commits, so I quickly fixed it.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Actually, only fop:fop:0.20.5 and batik:batik-1.5-fop:0.20-5 are really
used in addition to lib/saxon/saxon.jar (saxon:saxon:6.5.3). So the rest
does not need to be replaced and can just be wiped.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

It was kind of difficult to identify and find the vintage versions used
in AspectJ in download archives, but finally I managed to. Docs
generation looks good visually, tests to be run on GitHub CI.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Many dozens (hundreds?) of documentation code blocks were indented to
match the surrounding XML or just arbitrarily. The thing is: Inside
<programlisting> tags, similar to <pre> tags, line feeds and leading
whitespace are being preserved, which looked very awkward in the HTML
documentation. While a few files were mostly correct in this respect,
which shows that it was meant to be like that, many others were not.
This was tedious, stupid work to fix, but it had to be done.

Please note that the documentation was in no way updated content-wise.
This is also overdue, but not my focus here.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Of 6 classpath entries for Ant taskdef "fop", only 2 are actually
correct. That might mean that the others are not necessary, because docs
generation works correctly anyway.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

AFAIK, Jython is not used anywhere in out tests, also not in combination
with Ant. So I have decided to delete it altogether. If the build
passes, we should be fine and be able to travel more lightly in the
future.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Because 'cd lib && mvn compile' can now download and (un)zip many
previously SCM-committed third-party dependencies, the following 'lib'
subdirectories have been deleted:
 - ant
 - asm
 - commons
 - jarjar
 - junit
 - regexp
 - saxon
This one is new (but not stored in SCM):
 - jdtcore-aj

For each of them, there now is a .gitignore entry, so as to prevent
developers from accidentally committing the downloaded binaries again.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Now there is no system-scoped dependency left anymore in the Maven
build, i.e. the corresponding warnings are gone and we can focus on the
actual build log.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

In two places, the documentation now contains this text:

"Since AspectJ 1.9.7, the obsolete Oracle/BEA JRockit agent is no longer
part of AspectJ. JRockit JDK never supported Java versions higher than
1.6. Several JRockit JVM features are now part of HotSpot and tools like
Mission Control available for OpenJDK and Oracle JDK."

The decision to drop JRockit support was made during a discussion
between Alexander Kriegisch and Andy Clement:

Andy Clement wrote on 26 Mar 2021:

> Yes I think so.
>
>
> Alexander Kriegisch wrote on 26 Mar 2021:
>
>> https://en.wikipedia.org/wiki/JRockit
>>
>> Can we get rid of that? AspectJ requires Java 8, JRockit never
>> supported more than Java 6.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

It was the only subdirectory under lib/ext anyway and somehow always
irritating and difficult to find when just using a directory browser in
the IDE.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

One less SCM-committed binary, one less system-scoped dependency.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

This enables us to replace the original file from SCM. There is even an
improvement, like in other packages before: We create separate binary
and source archives, copying files from the compound download archive.
This way the library should be easy to use in an IDE.

TODO: This still does not get rid of the system path. Maybe it is better
to upload source and binary JARs to GitHub Packages.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

The access token is for the 'kriegaex' account. Can be adjusted or
extended in order to support other Package registries, too. for now, I
just want to see it this solves the authentication error problems during
GitHub CI builds.

The new file .mvn/settings-read-github-packages.xml contains additional
information and links to online sources, explaining why this is
necessary.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

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>

Maven Clean now deletes '' directories if it finds any. Furthermore,
AsynchronousFileCacheBackingTestSupport now not just deletes directory
contents but also removes the empty corresponding directories
afterwards.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

On GitHub CI, there is a very strange error while downloading the POM,
which does not occur locally. Maybe this is due to the usage of
inline XML tags inside a CDATA section in the 'description' tag text.
The default mode removes the description.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

There is a warning because 'asm-renamed' uses
<version>${asm.version}</version> in its artifact descriptor instead of
a fixed version. but as long as Maven still permits it, let us use it
this way. Flatten Maven plugin replaces it by a resolved number anyway
for the dependency-reduced POM.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

There were some problems in file handling: One file in was not deleted
in case an exception was thrown during the test. Another case was a
JarFile which was not closed before deletion, which might work on Linux,
but not on Windows where the open file is still locked after usage.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

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>

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>

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>

Via 'workflow_dispatch' users with the necessary access rights can now
run the GitHub Actions workflow from the web UI.

Still in testing stage in redundant module 'libx', prepare for the
future situation that currently committed binaries in 'lib' shall be
replaced by downloaded ones.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Duplicate dependencies, missing or mismatching versions

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

The test class UnweavableTest used ASM 2.0 API. I upgraded in two ways:
  1. Now the ASM 9.1 API is used. Probably works with much older
     versions too (just not as old as 2.0), as long as the method and
     constructor signatures are the same).
  2. The class now uses the AspectJ version of ASM (i.e. package names
     aj.org.objectweb.asm.*) and therefore can just use ASM as it is on
     the classpath for module 'tests' already. There is no more need to
     manually add '<pathelement path="${aj.root}/lib/asm/asm-2.0.jar"/>'
     to the Ant build script for that test.

Consequently, asm-2.0.jar can be eliminated from Git SCM completely,
because it was only used in this one test.

BTW, I also removed some deprecated API and other types of warnings in
UnweavableTest.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

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>

The deleted files are just the unpacked + content of
lib/jdiff/jdiff.jar.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

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>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

- 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>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

This is not strictly necessary, but probably does not hurt either. While
upgrading, '<tasks>' tags have been renamed to the new standard
'<target>'.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Before it was phase 'validate', which was way too early and somewhat
annoying and time-consuming when during development we just call
validate in order to check if the POMs are valid, as the name implies.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

There are two files:
  - docs/developer/ram-disk/maven.config
  - docs/developer/ram-disk/settings-ramdisk.xml

The latter contains info about how to set up a development environment
inside a RAM disk. Both files are to be copied to the project's '.mvn'
folder in the root directory and adjusted according to the description.

Just in case, .gitignore ignores the files if they exist in '.mvn', so
they are not being staged and committed accidentally.

An additional screenshot shows how to configure the Windows Recycle Bin
to immediately delete files in order too save space on the RAM disk.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

We have 84 times this kind of exceptions in 'ajde' tests in our build
logs on GitHub, even though the tests seem to pass:

  HeadlessException: No X11 DISPLAY variable was set,
  but this program performed an operation which requires it.

I found this discussion:
https://github.com/juliangruber/browser-run/issues/147

And then this GitHub Action:
https://github.com/marketplace/actions/gabrielbb-xvfb-action

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Due to JEP 260 (Encapsulate Most Internal APIs), aspect weaving on
Java 16 now requires '--add-opens java.base/java.lang=ALL-UNNAMED' on
the command line. Otherwise there will be illegal access exceptions for
some internal API calls AspectJ needs, most prominently when trying to
define classes in other packages or modules.

This had to be done on several levels:

  - Maven Surefire: running tests in a JVM directly forked by Surefire.
    In order to make this backwards compatible, I added two profiles
    with JDK-level-dependent auto-activation, one 8-15 and one 16+. In
    the latter a property containing the JVM parameter is defined, in
    the former it is empty, i.e. the JVM is started without the
    parameter. In Java 8 the parameter did not even exist, in Java 9+ we
    could use it, but we need to test how users use AspectJ.

  - RunSpec: Whenever an XML test is declared to use '<run>', we need to
    determine the current JVM version and again dynamically add the
    parameter when forking the target JVM.

  - AntSpec: Whenever an XML test is declared to use '<ant>', we need to
    determine the current JVM version dynamically add two properties
    usable from within Ant scripts: 'aj.addOpensKey' and
    'aj.addOpensValue'. Unfortunately, Ant needs to use two '<argLine>'
    parameters, because the two parts of the option are separated by a
    space character.

  - Ant scripts: When triggered by an AntSpec, each Ant target using LTW
    needs to manually set
      <jvmarg value="${aj.addOpensKey}"/>
      <jvmarg value="${aj.addOpensValue}"/>
    for each '<java>' task. It was quite tedious to find all(?) of them.

TODO: In the AspectJ 1.9.7 release notes we need to document that this
parameter is now needed for LTW.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

Before Java 16, JDK proxies were given a virtual package name of
'com.sun.proxy'. Now the packages are numbered 'jdk.proxy[n]', i.e.
'jdk.proxy1', 'jdk.proxy2' etc. This makes the package-name-derived path
name here less predictable. In our simple runtime scenario, we can be
pretty sure than the counter starts at 1 because it is the first and
only proxy we create.

TODO: A better solution would be a recursive filtered search via
Files.walk, ideally added as a recursive search option for
CountingFilenameFilter.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>

There is a new Maven profile 'repeat-all-unit-tests', and the name
already implies what a comment in the Maven module explains like this:
ATTENTION: This profile is inactive by default, because when active and
running a full reactor build, it makes almost all tests run 2x, doubling
the build time without any added value. This Maven module only exists
for convenience: As a developer, your IDE can detect and run
'RunTheseBeforeYouCommitTests'. That way, you do not have to use Maven
and get the test results reported within the IDE's JUnit user interface.

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>