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>

Migrate deployment from GitHub Packages to aspectj.dev

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

Only deploy main artifacts, default to no deployment for all others

Provision libraries in `lib` automatically

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>

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>

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>