On my workstation, more recent JDKs generate partly German javadocs.
Background: Avoid non-English javadoc generation. Due to
https://bugs.openjdk.org/browse/JDK-8222793 reoccurring at least in JDKs
19-21 and also being broken in some older JDKs, we cannot rely on just
setting the locale parameter, but also need the 'user.language' and
'user.country' parameters in 'additionalJOptions' as a workaround.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Overhaul ClassLoaderWeavingAdaptor to use statically initialised Unsafe
instances and method handles pointing to their 'defineClass' methods.
Those now work universally on JDKs 8-21. In older JDKs, the method used
to be in sun.misc.Unsafe, in more recent ones on jdk.internal.misc.Unsafe.
It is challenging to fetch instances, especially as reflection
protection and module boundaries have been increased in the JDK
progressively. But finally, a solution was adapted from Byte Buddy (BB).
Kudos to BB author Rafael Winterhalter. The previous solution to use
ClassLoader::defineClass and require '--add-opens' is no longer
necessary for the first time since it became necessary in AspectJ 1.9.7
with Java 16 support.
Add org.ow2.asm:asm-common as a dependency everywhere org.ow2.asm:asm
was used before. Maybe that is too many places, but no worse than before.
Add missing dependency on loadtime to aspectjweaver. This kept a build
like "mvn install -am -pl aspectjweaver" from picking up changed
loadtime classes.
Fixes #117.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
If we ever decide to add Maven site docs to the AspectJ website, now we
can deploy them locally using 'mvn site:deploy' and publish them on a
web server or even incorporate them into the binary distribution in the
installer's belly.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Docs: Create separate CSS files, do not embed into HTML
TODO: There still is one set of CSS files per subdirectory due to the
way the docs directories are organised. It would be better to have them
just once. But to achieve that, the ADOC-to-HTML conversion would have
to be changed, e.g. using one central directory for images and
reorganisation of the overall directory structure and build options.
See https://github.com/asciidoctor/asciidoctor-maven-plugin/issues/729.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Using Asciidoctor Maven, we now produce PDFs (which are also linked to
from the main documentation index page) for
- Programming Guide,
- AspectJ 5 Developer's Notebook,
- Development Environment Guide,
- Problem Diagnosis Guide,
- AspectJ Design Overview.
Attention! PDF generation alone takes 3+ minutes, almost 4 minutes
including asciidoc to HTML conversion. Just deactivate the 'create-docs'
profile if you do not need docs during the build.
Closes #272.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
User relative paths for images instead.
In one case, we need to copy images from a subdirectory one level up,
because otherwise the images are only found in the included document,
but not in the single-page one including it from the subdirectory. In
all other cases, included ADOCs are located in the same directory as the
including document.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
The new version is compiled to target 17. This should avoid the strange
"NoSuchFieldError: RELEASE_17" error message in AJC.
Closes #269.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Currently, the situation looks more like a Java 21 maintenance release
than directly a Java 22 release.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Let's find out if the tests still pass
- on Java 19, except for J19 preview features,
- on Java 20, also except for J19 with changed syntax.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Even though we just upgraded to 9.3 for Java 19, it does not hurt to
have ASM recognise the Java 20 class file major version.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove Aspectj.dev artifact and plugin repositories
After having removed the custom-built Maven Shade version, there should
be no more references to artifacts in that repository left. Let us see
if the build passes.
Furthermore, since being a committer, I can also attach AspectJ
installers to GitHub releases.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Bump Maven Shade Plugin to 3.3.0, add TODO to remove Flatten Maven Plugin
Fixed issues of concern include MSHADE-252, MSHADE-396, MSHADE-391.
TODO: MSHADE-36 is in Maven Shade 3.3.0 -> it should be possible to
include the dependency-reduced POM there directly. So maybe, we can rid
of Flatten Maven Plugin.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
POM bug: separate jvm.arg.allowSecurityManager from jvm.arg.addOpens
Before, this was in a single variable, and for JDK 18+, the security
manager setting also falsely overwrote the '--add-opens' command. This
was the root cause for a few dozen LTW tests to fail on JDK 18, if they
were not run in full LTW mode, i.e. in a separate JVM.
After this fix, it should be possible to revert the corresponding
commits, at least their non-cosmetic parts.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Use upstream method to generate '--add-reads', '--add-exports' info
and copy it into our FileSystem instance. In order to be able to access
JDT Core's FileSystem.moduleUpdates field, we had to make it public
there first.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Alexander Kriegisch