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>

Fix missing dependencies in module 'run-all-junit-tests'

Some runtime dependencies are reported as unused in Maven Dependency
Plugin goal 'dependency:analyze', but actually they are needed. I
noticed by chance when running RunTheseBeforeYouCommitTests in IntelliJ
IDEA for the first time after a while and dependency modules could not
find classes.

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

Libs refactoring (remove libs from Git SCM)

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>

These scripts look pretty antique and obsolete.

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

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>

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

The new string AjcTestCase.CLASSPATH_ASM_RENAMED dynamically determines
the 'asm-renamed' location from the classpath, system property
'java.class.path'.

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

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>

No more manual version setting everywhere.

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

If 'name' is identical to 'artifactId' and 'packaging' has the default
value 'jar', we can just remove those tags from the POM.

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

The resource key 'misc.usage' is completely gone from
.../jdt/internal/compiler/batch/messages_aspectj.properties. Instead,
JDT Core was adjusted in such a way as to patch the new resource key
'misc.usage.aspectj' into the upstream 'misc.usage' in the right place.

Now finally the properties file is as lean as I envisioned it to be,
without any loss of information and without the need of future manual
synchronisation of duplicate texts for every release.

At the same time, usage text detection in AjdtCommand::inferKind was
improved and also adjusted to the new situation.

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

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>