- Fix one fault sanity test configuration
- Deactivate Java 16 preview tests (no longer supported by Java 17
compiler)
- Test sealed classes as final on Java 17 (no longer preview)
- Add tests for JEP 406, pattern matching for switch (preview). At
present, the beta 17 branch of JDT Core does not handle the tested
features and expected compile errors correctly yet, so I had to
temporarily deactivate test execution, only printing TODO messages.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
In ITD processing, use setter instead of assigning Scope directly
Change calls like
pre.scope.parent = newParent;
to this pattern:
// Use setter in order to also update member 'compilationUnitScope'
pre.scope.setParent(newParent);
This should fix lots of failing tests after updating JDT Core.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
After my PR https://github.com/maven-download-plugin/maven-download-plugin/pull/191
was merged and https://github.com/maven-download-plugin/maven-download-plugin/issues/186
was closed, use a new release containing the option misnomer fix in
order to make the POM more readable.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Remove logging dots per test step in AjcTest.runTest
Methods AjcTest.runTest was logging something like "TEST: ...."
(4 dots), i.e. one dot per performed test step. Not only did this not
add much value, but due to usage of PrintStream.print for line
continuation it also messed up test step logging by scattering seemingly
random dot characters across test step logs. This looked quite ugly, so
I simply removed it.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
By using System.nanoTime() instead of currentTimeMillis(), the flakiness
even with the original 10,000 rounds is significantly lower than before.
Making my IDE repeat the test until failure, it took on average 150 runs
to make it fail. So, the more accurate timing helps. With 100,000
rounds, it was even more stable, but eventually I could make it fail.
With 1,000,000 rounds however, even running the test 500x could not make
it fail. So for all practical purposes, I think the test is reasonably
stable now.
Closes #83.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
By increasing from 10,000 to 1,000,000 rounds, the times compared for
performance become considerably longer (but still in the tens or
hundreds or milliseconds), decreasing the probability of the test
failing due to CPU load or some other random effect.
Closes #83.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Document build profiles and properties in docs/developer/BUILD.md
In doing so, I also noticed a few things in need of improvement. So,
documenting the build also drive those enhancements, such as
- the new 'fast-build' profile skipping test compilation and execution
as well as documentation generation,
- an option to skip generating source assemblies,
- to skip unzipping source assemblies if javadoc generation for them
is to be skipped too,
- activating the 'create-docs' profile by property which is
true by default instead of using 'activeByDefault=true', because the
latter does not work reliably if other profiles are activated
manually according to a Maven bug that was closed as "won't fix",
- no longer generating separate javadocs for the 'runtime' module,
because that module is not deployed and the main artifacts recreate
Javadocs from scratch for all of their constituent sources anyway.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Detect previously failed downloads by verifying existing file checksums
There was a helpful option hiding in Download Maven plugin, which we use
to download artifacts unavailable on Maven Central, such as the Ant
installer and several source packages: 'checkSignature'. It has the
effect of verifying checksums of existing, i.e. previously downloaded
files too, not only newly downloaded ones. This helps detect interrupted
downloads from previous runs or generally invalid files, whatever the
reason. I was looking for this option before, but did not notice it
because of the name. This is about verifying checksums, not checking
signatures. Anyway, a maintainer just told me about it here:
This is a bugfix release, reverting the essential parts of commit f70aeb5e, because it causes AspectJ Maven integration tests using
javadoc to fail on JDK 8.
See commit discussion on
https://github.com/eclipse/org.aspectj/commit/f70aeb5e#commitcomment-51417353
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Revert "Always run javadoc using the ToolProvider API"
This reverts commit f70aeb5e, except for some commented-out parts of
code and an unused method. I also simplified the code, e.g. with regard
to exception handling, and did some more cosmetic stuff, but basically
it is a revert.
In order to make it compile on more recent JDKs which doe not have class
com.sun.tools.javadoc.Main, I used Class.forName in the method being
called on JDK 8 only.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Fix Javadoc generation by also unpacking relocated ASM sources
Suddenly, for AspectJ Weaver + Tools Javadoc generation started to fail.
This might be due to switching from ASM-renamed to dynamically shaded
ASM. Either way, the Javadoc tool complains about the missing source
files. Therefore, we also unpack them from the source uber JAR now via
TrueZIP before generating Javadoc.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Upgrade Maven Shade Plugin to 3.2.4.MSHADE-252-391
Unfortunately, the issues fixed in the aspectj.dev fork are still not
available upstream (MSHADE-252 is merged, but unreleased, MSHADE-391 is
in review).
Also use Maven Javadoc Plugin version from parent POM.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Before, we used 1.9.7.BUILD-SNAPSHOT, which according to Andy Clement
was originally an intent across a group of Spring projects he was
involved in, to ensure that SNAPSHOTS were sorted alphabetically ahead
of MILESTONEs and ahead of RCs.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
In order to keep developers from creating AspectJ releases manually or
using Ant script 'build/build.xml', get rid of all POM templates. This
step does not involve updating any build or release how-to documents or
any other clean-up work under 'build', but it is a first step and a
simple, implicit reminder that now we can build and release using Maven.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
This involves replacing references in weaver application code as well as
a few tests.
In order to make AspectJ weaver + tools contain a relocated ASM version,
I added a Maven Shade relocation step after Maven Assembly created the
uber JARs. Relocation works for both binaries and sources and also
encompasses Class::forName calls like in class AsmDetector.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Other than Maven Deploy, Nexus Staging plugin cannot just be added to
the 'build/plugins' section of the parent POM once and (de-)activated
with a simple property like 'maven.deploy.skip' on a per-module basis.
See also https://issues.sonatype.org/browse/OSSRH-68966. Consequently,
we do not add it to the parent but separately to each module meant to be
published.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Create javadoc for all public artifacts, fix dependencies
Sonatype OSSRH repository rules require source and javadoc JARs in
order to create staging repositories for releases to be promoted to
Maven Central. So I added build steps to unzip the source JARs and then
create Javadocs for them.
FIXME: This configuration works with JDK 16, but throws errors on other
JDK versions, e.g. 14. It looks as if the Maven Javadoc plugin does not
do a particularly good job applying the plugin settings in a way making
it work with different JDK javadoc tool versions. I am saying that,
because when using the tool directly on the console, it works with basic
settings and the correct classpath.
In order to enable creating uber JARs via Maven Shade in the future, I
also added missing dependencies. Maven Assembly descriptors just assume
that all the necessary class files and sources already exist where it
copies them from. But several of the dependency modules were not
explicitly listed as such by the uber JAR modules. I fixed that.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Add information required by Maven Central to public artifact POMs
This is another step away from manual deployment towards Maven-triggered
deployment for both releases and snapshots. The 5 main POMs (matcher,
runtime, weaver, tools, installer) now contain information required by
Sonatype for Maven Central deployments according to:
https://central.sonatype.org/publish/requirements/
TODO:
- Add corresponding 'distributionManagement' section and necessary
release plugins for Sonatype OSS repositories to parent POM.
- Enable Maven to also use Install plugin in order to automatically
set release versions, commit to Git and tag releases, then upgrade
to a new snapshot afterwards.
- Make sure that Flatten Maven plugin does not strip off the required
tags we just added to the POMs. It looks as if the chosen
flattenMode=oss already retains the exact tags we need, only
slightly reformatting (hence "uglifying") the POM. But an ugly POM
does not block Maven Central deployments, as long as it is complete.
So it looks as if this to-do item is already done.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Replace links to aspectj.org by links to eclipse.org/aspectj
As discussed with Andy Clement, domain aspectj.org seems to still be
owned by Xerox, and currently no website for it is online. Therefore, it
is better to link to the AspectJ Eclipse homepage.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
Revert "use the alternate maven settings by default"
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>
Prepare main artifacts to be deployed via Maven, step 2
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>
projects / aspectj.git / log