aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Revert "use the alternate maven settings by default"Alexander Kriegisch2021-05-151-1/+0
| |/ | | | | | | | | | | | | | | 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>
* | Merge pull request #53 from kriegaex/remove-asm-renamedAndy Clement2021-05-2222-243/+145
|\ \ | |/ |/| Remove ASM-renamed, replace by dynamic relocation via Maven Shade
| * Completely remove module ASM-renamed + referencesAlexander Kriegisch2021-05-162-189/+0
| | | | | | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
| * Replace use of ASM-renamed by original ASMAlexander Kriegisch2021-05-1620-54/+145
|/ | | | | | | | | | | | 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>
* use the alternate maven settings by defaultAndy Clement2021-05-141-0/+1
|
* Merge pull request #49 from kriegaex/migrate-to-aspectj-devAndy Clement2021-05-142-34/+88
|\ | | | | Migrate deployment from GitHub Packages to aspectj.dev
| * Migrate deployment from GitHub Packages to aspectj.devAlexander Kriegisch2021-05-112-34/+88
| | | | | | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
* | Remove jdiffAndy Clement2021-05-147-485/+147
|/
* Merge pull request #48 from kriegaex/deploy-main-artifacts-onlyAndy Clement2021-05-107-0/+32
|\ | | | | Only deploy main artifacts, default to no deployment for all others
| * Prepare main artifacts to be deployed via Maven, step 2Alexander Kriegisch2021-05-087-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge pull request #46 from kriegaex/lib-auto-provisioningAndy Clement2021-05-1018-636/+774
|\ \ | |/ |/| Provision libraries in `lib` automatically
| * Move Enforcer Plugin to 'compile' phase in 'lib'Alexander Kriegisch2021-05-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Improve 'name' tags in POMsAlexander Kriegisch2021-05-062-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Bump download-maven-plugin 1.6.1 -> 1.6.3Alexander Kriegisch2021-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Remove obsolete separate GitHub build step for provisioning librariesAlexander Kriegisch2021-05-051-3/+0
| | | | | | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
| * Provision libraries in 'lib' automaticallyAlexander Kriegisch2021-05-0516-631/+773
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge pull request #44 from kriegaex/run-all-junit-tests-dependenciesAndy Clement2021-04-283-13/+71
|\ | | | | Fix missing dependencies in module 'run-all-junit-tests'
| * Fix missing dependencies in module 'run-all-junit-tests'Alexander Kriegisch2021-04-283-13/+71
|/ | | | | | | | | | 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>
* Merge pull request #41 from kriegaex/libs-refactoringAndy Clement2021-04-251043-185622/+8588
|\ | | | | Libs refactoring (remove libs from Git SCM)
| * Prepare main artifacts to be deployed via Maven, step 1Alexander Kriegisch2021-04-268-10/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Remove build/scripts/*Alexander Kriegisch2021-04-178-483/+0
| | | | | | | | | | | | These scripts look pretty antique and obsolete. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
| * Fix: make sure that source assemblies are attached to buildAlexander Kriegisch2021-04-179-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Remove some cruft from test classes Ajc, AjcTestCase, AntSpecAlexander Kriegisch2021-04-163-87/+32
| | | | | | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
| * Remove managing obsolete folder lib/asmAlexander Kriegisch2021-04-164-71/+25
| | | | | | | | | | | | | | | | 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>
| * Use dependencies instead of copies under 'lib' for assembliesAlexander Kriegisch2021-04-1612-165/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Manage version version maven-assembly-plugin:3.1.1Alexander Kriegisch2021-04-166-25/+10
| | | | | | | | | | | | No more manual version setting everywhere. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
| * Remove redundant 'name' and 'packaging' tags from POMsAlexander Kriegisch2021-04-1524-62/+6
| | | | | | | | | | | | | | 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>
| * Remove remaining usage message duplication between ECJ and AJCAlexander Kriegisch2021-04-142-201/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Add lib/docbook to Maven CleanAlexander Kriegisch2021-04-131-0/+1
| | | | | | | | Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
| * Upgrade JUnit BoM to 5.7.1Alexander Kriegisch2021-04-121-1/+1
| | | | | | | | | | | | | | | | | | 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>
| * Fix undetected runtime dependency usage problem from previous commitAlexander Kriegisch2021-04-121-0/+17
| | | | | | | | | | | | | | | | | | 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>
| * Fix undetected runtime dependency usage problem from previous commitAlexander Kriegisch2021-04-122-1/+27
| | | | | | | | | | | | | | | | | | | | 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>
| * Clean up Maven dependencies using 'dependency:analyze' goalAlexander Kriegisch2021-04-1219-352/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Fix image formatting glitch in docs/devGuideDB/ajbrowser.xmlAlexander Kriegisch2021-04-101-18/+22
| | | | | | | | | | | | | | | | | | 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>
| * Delete all remaining docbook contents, download them insteadAlexander Kriegisch2021-04-1010-61/+26
| | | | | | | | | | | | | | | | 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>
| * Delete docbook XSL + DTD directories from libs, download insteadAlexander Kriegisch2021-04-10386-91700/+64
| | | | | | | | | | | | | | | | 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>
| * Remove indentation from <programlisting> blocks in docsAlexander Kriegisch2021-04-1028-4590/+4472
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Add comments about wrong classpath entries to docs/build.xmlAlexander Kriegisch2021-04-101-9/+9
| | | | | | | | | | | | | | | | 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>
| * 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>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-15 19:38:00 +0000