| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
If any of the old Ant builds, e.g. tests/profiling/build.xml, which
have never been mavenised, need JDT Core, they should be converted to
Maven builds and refer to it as a regular dependency. As is, the Ant
builds would not run anyway, because other dependency locations have
changed as well.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
| |
The jarjar library seems to be unused.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
| |
The library seems to be unused.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
|
|
| |
Both bcel.jar and bcel-verifier.jar seem to be obsolete.
Possible next step: Remove bcel-builder/verifier-src.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
|
|
|
|
|
| |
Of beanutils, collections, digester and logging actually only digester
and logging are directly used in AspectJ code. Therefore, remove the
unused ones and upgrade the remaining libraries' versions to ones which
also have source JARs on Maven Central. This makes downloading sources
from GitHub and packaging separate commons.jar and commons-src.zip
artifacts superfluous. Hence, we can get rid of them completely.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Also update lib/aspectj/aspectjweaver.jar to fix integration tests.
Fixes #285.
Co-authored-by: Kimming Lau <294001791@qq.com>
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
|
| |
This reproduces regression bug #285 when running
org.aspectj.systemtest.ajc171.NewFeatures::testSharedCache.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
| |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
|
|
|
| |
Maybe, the XML files and Maven wrapper files will follow. First, let us
find out if this breaks the build, maybe some tests are asserting on
"http:". But there, the replacement would also have taken place, so
probably it just works.
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>
|
|
|
|
|
|
|
| |
In the next step, the content, which is still HTML at this point, is
going to be converted.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Along with the Ant and Maven build configs, downloads of
- DocBook DTD,
- DocBook XSL,
- FOP,
- Batik,
- Saxon
also become obsolete.
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>
|
|
|
|
| |
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>
|
|
|
|
| |
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>
|
|
|
|
| |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
| |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
| |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
| |
|
| |
|
|
|
|
|
|
|
| |
It makes sense to indicate the Java version in the minor-minor of
AspectJ artifacts.
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>
|
|
|
|
| |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
| |
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was referring to a no longer existent weaver under
aj-build/dist/tools/lib/aspectjweaver.jar, which now has been replaced
by the new file lib/aspectj/lib/aspectjweaver.jar.
Several tests were broken, not finding the agent. But because those
tests make no assertions, nobody ever noticed. Only when I had to change
some LTW tests from in-process to full LTW mode (see next commit) due to
them now obviously calling some code paths which need '--add-opens', I
even noticed the problem.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
|
|
|
|
| |
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>
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
https://github.com/maven-download-plugin/maven-download-plugin/issues/186
I requested that the option be renamed and described better.
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|