aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Fix faulty path in docs/progGuideDB/progguide.html.xslAlexander Kriegisch2021-04-101-9/+9
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Completely delete Jython in lib/jythonAlexander Kriegisch2021-04-10331-73434/+0
| | | | | | | | | 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>
* Switch from 'libx' to 'lib', delete all obsolete binariesAlexander Kriegisch2021-04-1095-11092/+25
| | | | | | | | | | | | | | | | | | | | 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>
* Clean up remaining references to system-scoped dependenciesAlexander Kriegisch2021-04-105-124/+0
| | | | | | | | 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>
* Remove JRockit LTW support, particularly JRockitAgentAlexander Kriegisch2021-04-1015-525/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Move lib/ext/jrockit to just lib/jrockitAlexander Kriegisch2021-04-107-3/+3
| | | | | | | | 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>
* Replace JDiff by regular Maven dependency from GitHub PackagesAlexander Kriegisch2021-04-106-49/+29
| | | | | | One less SCM-committed binary, one less system-scoped dependency. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Download correct JDiff binaries and sources to 'libx'Alexander Kriegisch2021-04-101-30/+84
| | | | | | | | | | | | 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>
* Use special Maven settings with access token to GitHub PackagesAlexander Kriegisch2021-04-092-3/+28
| | | | | | | | | | | | | 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>
* Use additional Maven Clean execution in 'libx'Alexander Kriegisch2021-04-091-19/+29
| | | | | | | | 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>
* Make sure to clean up temp-dirs in 'weaver' moduleAlexander Kriegisch2021-04-092-2/+8
| | | | | | | | | 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>
* CI test still failing, try 'mvn -U' in order to refreshAlexander Kriegisch2021-04-091-2/+2
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Use flattenMode=defaults for 'asm-renamed'Alexander Kriegisch2021-04-091-1/+1
| | | | | | | | | 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>
* Centrally manage ASM version in parent POMAlexander Kriegisch2021-04-092-1/+5
| | | | | | | | | | 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>
* Remove duplicate Maven Clean declaration in parent POMAlexander Kriegisch2021-04-091-18/+0
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix missing ASM version in 'aspectj-renamed' POMAlexander Kriegisch2021-04-091-0/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* POM cosmetics, e.g. plugin version managementAlexander Kriegisch2021-04-095-40/+92
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Improve 2 tests do delete temporary filesAlexander Kriegisch2021-04-092-20/+26
| | | | | | | | | 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>
* Module 'asm-renamed' now deploys to GitHub PackagesAlexander Kriegisch2021-04-096-17/+239
| | | | | | | | | | | 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>
* Replace JDT Core system dependency by deployed oneAlexander Kriegisch2021-04-0920-453/+371
| | | | | | | | | | 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>
* Build libs without additional profiles, add Enforcer ruleAlexander Kriegisch2021-04-092-276/+291
| | | | | | | | | | | | | | | | | 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>
* Enable CI build to be run manually and add download libs stepAlexander Kriegisch2021-04-091-1/+5
| | | | | | | | | | | 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>
* Get rid of some Maven warnings concerning plugins + dependenciesAlexander Kriegisch2021-03-305-14/+2
| | | | | | Duplicate dependencies, missing or mismatching versions Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Remove ASM 2.0 dependency from AtAjLTWTests::testLTWUnweavableAlexander Kriegisch2021-03-293-28/+25
| | | | | | | | | | | | | | | | | | | | 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>
* Replace system-scoped dependency on commons by granular dependenciesAlexander Kriegisch2021-03-298-30/+45
| | | | | | | | | | | | 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>
* Remove JDiff sources + binaries accidentally committed in @c89830feAlexander Kriegisch2021-03-2912-1096/+0
| | | | | | | The deleted files are just the unpacked + content of lib/jdiff/jdiff.jar. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Recreate lib/commons from Apache Commons downloadsAlexander Kriegisch2021-03-291-3/+298
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Replace Ant and Xerces system-scopes libraries by normal dependenciesAlexander Kriegisch2021-03-298-73/+60
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Recreate lib/ant from Apache source/binary downloadsAlexander Kriegisch2021-03-291-31/+140
| | | | | | | | | | | | | | | | - Download Ant 1.6.3 binaries and sources ZIPs from Apache releases download server - Verify expected SHA-1 checksums - Unpack binary distribution - Repack main sources into source package as it is checked in now - Redundantly add JUnit JAR in order to 100% replicate existing directory layout - Move downloads from 'validate' phase to 'generate-resources' - Unpack/repack phase is 'process-resources' - Make sure that download, unpack, repack only occur if necessary instead of overwriting existing artifacts during each build Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add POM to download libs (WIP) which previously were committed to SCMAlexander Kriegisch2021-03-293-17/+185
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Bump maven-antrun-plugin from 1.6 to 3.0.0Alexander Kriegisch2021-03-294-14/+14
| | | | | | | | This is not strictly necessary, but probably does not hurt either. While upgrading, '<tasks>' tags have been renamed to the new standard '<target>'. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Install module org.eclipse.jdt.core in 'install' phase, not 'verify'Alexander Kriegisch2021-03-282-2/+4
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Reformat org.eclipse.jdt.core POMAlexander Kriegisch2021-03-281-48/+46
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Unzip dependencies in phase 'prepare-package' before building assembliesAlexander Kriegisch2021-03-283-5/+5
| | | | | | | | Before it was phase 'validate', which was way too early and somewhat annoying and time-consuming when during development we just call validate in order to check if the POMs are valid, as the name implies. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix JRockitAgentTest.testJrockitRecursionProtection for JVM 9+Alexander Kriegisch2021-03-281-14/+1
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add developer info + sample config about how to work with a RAM diskAlexander Kriegisch2021-03-254-0/+73
| | | | | | | | | | | | | | | | | | There are two files: - docs/developer/ram-disk/maven.config - docs/developer/ram-disk/settings-ramdisk.xml The latter contains info about how to set up a development environment inside a RAM disk. Both files are to be copied to the project's '.mvn' folder in the root directory and adjusted according to the description. Just in case, .gitignore ignores the files if they exist in '.mvn', so they are not being staged and committed accidentally. An additional screenshot shows how to configure the Windows Recycle Bin to immediately delete files in order too save space on the RAM disk. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Try to avoid 'HeadlessException: No X11 DISPLAY' on GitHub ActionsAlexander Kriegisch2021-03-241-1/+5
| | | | | | | | | | | | | | | | We have 84 times this kind of exceptions in 'ajde' tests in our build logs on GitHub, even though the tests seem to pass: HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. I found this discussion: https://github.com/juliangruber/browser-run/issues/147 And then this GitHub Action: https://github.com/marketplace/actions/gabrielbb-xvfb-action Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Make all tests run on Java 16 via '-add-opens' JVM optionjava16-add-opensAlexander Kriegisch2021-03-2315-162/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to JEP 260 (Encapsulate Most Internal APIs), aspect weaving on Java 16 now requires '--add-opens java.base/java.lang=ALL-UNNAMED' on the command line. Otherwise there will be illegal access exceptions for some internal API calls AspectJ needs, most prominently when trying to define classes in other packages or modules. This had to be done on several levels: - Maven Surefire: running tests in a JVM directly forked by Surefire. In order to make this backwards compatible, I added two profiles with JDK-level-dependent auto-activation, one 8-15 and one 16+. In the latter a property containing the JVM parameter is defined, in the former it is empty, i.e. the JVM is started without the parameter. In Java 8 the parameter did not even exist, in Java 9+ we could use it, but we need to test how users use AspectJ. - RunSpec: Whenever an XML test is declared to use '<run>', we need to determine the current JVM version and again dynamically add the parameter when forking the target JVM. - AntSpec: Whenever an XML test is declared to use '<ant>', we need to determine the current JVM version dynamically add two properties usable from within Ant scripts: 'aj.addOpensKey' and 'aj.addOpensValue'. Unfortunately, Ant needs to use two '<argLine>' parameters, because the two parts of the option are separated by a space character. - Ant scripts: When triggered by an AntSpec, each Ant target using LTW needs to manually set <jvmarg value="${aj.addOpensKey}"/> <jvmarg value="${aj.addOpensValue}"/> for each '<java>' task. It was quite tedious to find all(?) of them. TODO: In the AspectJ 1.9.7 release notes we need to document that this parameter is now needed for LTW. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix AtAjLTWTests::testLTWDumpProxy for Java 16Alexander Kriegisch2021-03-231-2/+14
| | | | | | | | | | | | | | | Before Java 16, JDK proxies were given a virtual package name of 'com.sun.proxy'. Now the packages are numbered 'jdk.proxy[n]', i.e. 'jdk.proxy1', 'jdk.proxy2' etc. This makes the package-name-derived path name here less predictable. In our simple runtime scenario, we can be pretty sure than the counter starts at 1 because it is the first and only proxy we create. TODO: A better solution would be a recursive filtered search via Files.walk, ideally added as a recursive search option for CountingFilenameFilter. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Deactivate test run in 'run-all-unit-tests' module by defaultAlexander Kriegisch2021-03-231-6/+56
| | | | | | | | | | | | | There is a new Maven profile 'repeat-all-unit-tests', and the name already implies what a comment in the Maven module explains like this: ATTENTION: This profile is inactive by default, because when active and running a full reactor build, it makes almost all tests run 2x, doubling the build time without any added value. This Maven module only exists for convenience: As a developer, your IDE can detect and run 'RunTheseBeforeYouCommitTests'. That way, you do not have to use Maven and get the test results reported within the IDE's JUnit user interface. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Revert "Remove module 'run-all-junit-tests' from root POM -> speed up the build"Alexander Kriegisch2021-03-236-119/+110
| | | | | | This reverts commit a1867b05ba6443d32abc4049c26b92fc226d6f78. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add link to JDK-8263924 bug ticket to POMs using maven-assembly-pluginAlexander Kriegisch2021-03-224-0/+12
| | | | | | | | This is a follow-up on commit @0b182d60. I have just received confirmation from Oracle that my issue was accepted: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263924 Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add Java 16 Linux matcher variant to HtmlDecoratorAlexander Kriegisch2021-03-222-90/+121
| | | | | | | | | | | | | | | | | | | The Java 16 Javadoc generator has changed the HTML structure once again even compared to Java 15. I adjusted the matching in HtmlDecorator and also fixed CoverageTestCase. Most methods there I just made to work quickly, but method 'testInnerAspect()' I actually refactored. Some other methods could (probably should) be restructured in a similar fashion, but for now I just wanted to understand what the test does and see how much work it would be to refactor it. But finally, I just want to get the GitHub CI build running on Java 16. TODO: I did not check if the decorated HTML actually looks OK and am unsure if the tests cover that sufficiently, I never reviewed the tests. It would also be better to do regex matches instead of looking for variants of fixed strings or maybe even to operate on a DOM. But I am not in a mood to refactor that tonight. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Add diagnostic output to HtmlDecorator if AJ-Doc generation failsAlexander Kriegisch2021-03-212-0/+14
| | | | | | | | | | | | | | HtmlDecorator.decorateHTMLFile is where after Java version upgrades (i.e. also new Javadoc generator version) usually tests fail for the first time during builds because strings no longer match as expected. There now is this log message on stdOut: "Something unexpected went wrong in HtmlDecorator. Here is the full file causing the problem:" After that, a full HTML page is logged. I hope this helps me identify the new error on GitHub Linux Java 16, because the same test works on Windows and I have no idea how to remote-debug a GitHub CI build. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Make BCEL classpath utility recognise Java 16-19, fixing many testsAlexander Kriegisch2021-03-211-1/+1
| | | | | | | | | | | | | | | | | This is a follow-up commit on @07af5d41: Inside org.aspectj.apache.bcel.util.ClassPath.getClassPath(), some JVM version matching occurs which previously did not include Java 16 (I also added 17-19 to the regex matcher). This fixes test errors like: java.lang.ClassCastException: class org.aspectj.weaver.MissingResolvedTypeWithKnownSignature cannot be cast to class org.aspectj.weaver.ReferenceType (org.aspectj.weaver.MissingResolvedTypeWithKnownSignature and org.aspectj.weaver.ReferenceType are in unnamed module of loader 'app') Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix AjcTaskTest regarding Ajc outputAlexander Kriegisch2021-03-211-3/+3
| | | | | | Another follow-up commit on @31b2d60b Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix OutjarTest regarding Ajc output (usage messages etc.)Alexander Kriegisch2021-03-211-46/+39
| | | | | | | | | After Ajc usage text output is filtered into its own category IMessage.USAGE now - see commit @31b2d60b - some tests in module 'org.aspectj.ajdt.core' were failing. I fixed and also improved them a bit in @e4a2a5a5, but forgot to commit this one. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Set explicit en_US locale for build timestamps in Build Helper MavenAlexander Kriegisch2021-03-212-3/+6
| | | | | | | | There were warnings that builds were dependent on the system local (de_DE in my case). In patterns like "EEEE MMM d, yyyy", parts like day of week or month names would change otherwise. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix some deprecated Java and JUnit warnings by using newer API callsAlexander Kriegisch2021-03-2133-71/+73
| | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* Fix + improve some tests regarding Ajc output (usage messages etc.)Alexander Kriegisch2021-03-216-92/+114
| | | | | | | | | After Ajc usage text output is filtered into its own category IMessage.USAGE now - see commit @31b2d60b - some tests in module 'org.aspectj.ajdt.core' were failing. I fixed and also improved them a bit. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 10:04:49 +0000