You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

pom.xml 17KB

5 years ago
5 years ago
5 years ago
5 years ago
Provision libraries in 'lib' automatically 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>
3 years ago
5 years ago
5 years ago
5 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
5 years ago
5 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
Prepare main artifacts to be deployed via Maven, step 1 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>
3 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
5 years ago
Make all tests run on Java 16 via '-add-opens' JVM option 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>
3 years ago
Provision libraries in 'lib' automatically 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>
3 years ago
5 years ago
Provision libraries in 'lib' automatically 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>
3 years ago
5 years ago
5 years ago
5 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3. xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  4. <modelVersion>4.0.0</modelVersion>
  5. <groupId>org.aspectj</groupId>
  6. <artifactId>aspectj-parent</artifactId>
  7. <version>1.9.20-SNAPSHOT</version>
  8. <packaging>pom</packaging>
  9. <name>AspectJ Parent Project</name>
  10. <properties>
  11. <!-- Basic build properties -->
  12. <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  13. <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  14. <!-- By default, do not deploy artifacts - override for the ones which actually should be deployed -->
  15. <maven.deploy.skip>true</maven.deploy.skip>
  16. <!-- By default, do not create javadoc - override in release profile or manually -->
  17. <maven.javadoc.skip>true</maven.javadoc.skip>
  18. <!-- Dependency versions -->
  19. <jdt.core.version>1.9.19</jdt.core.version>
  20. <asm.version>9.4</asm.version>
  21. <lib.ant.version>1.6.3</lib.ant.version>
  22. <lib.ant.xerces.version>2.6.2</lib.ant.xerces.version>
  23. <lib.regexp.version>1.2</lib.regexp.version>
  24. <lib.commons.beanutils.version>1.4</lib.commons.beanutils.version>
  25. <lib.commons.beanutils.tag>BEANUTILS_1_4</lib.commons.beanutils.tag>
  26. <lib.commons.collections.version>2.0</lib.commons.collections.version>
  27. <lib.commons.collections.tag>collections-2.0</lib.commons.collections.tag>
  28. <lib.commons.digester.version>1.3</lib.commons.digester.version>
  29. <lib.commons.digester.tag>DIGESTER_1_3</lib.commons.digester.tag>
  30. <lib.commons.logging.version>1.0.1</lib.commons.logging.version>
  31. <lib.commons.logging.tag>LOGGING_1_0_1</lib.commons.logging.tag>
  32. </properties>
  33. <distributionManagement>
  34. <snapshotRepository>
  35. <id>ossrh</id>
  36. <url>https://oss.sonatype.org/content/repositories/snapshots</url>
  37. </snapshotRepository>
  38. <repository>
  39. <id>ossrh</id>
  40. <url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
  41. </repository>
  42. </distributionManagement>
  43. <repositories>
  44. <!--
  45. Repeat Central definition from super POM https://maven.apache.org/ref/3.6.3/maven-model-builder/super-pom.html.
  46. Define it as the first repository to search at, otherwise Maven would always search any other repositories defined
  47. in the POM or in settings.xml first, slowing down the build, because most artifacts reside at Maven Central. See
  48. https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order for more details.
  49. -->
  50. <repository>
  51. <id>central</id>
  52. <name>Central Repository</name>
  53. <url>https://repo.maven.apache.org/maven2</url>
  54. <layout>default</layout>
  55. <snapshots>
  56. <enabled>false</enabled>
  57. </snapshots>
  58. <releases>
  59. <enabled>true</enabled>
  60. <updatePolicy>never</updatePolicy>
  61. </releases>
  62. </repository>
  63. <repository>
  64. <id>ossrh-snapshots</id>
  65. <name>Sonatype OSSRH snapshots</name>
  66. <url>https://oss.sonatype.org/content/repositories/snapshots</url>
  67. <layout>default</layout>
  68. <snapshots>
  69. <enabled>true</enabled>
  70. <updatePolicy>always</updatePolicy>
  71. </snapshots>
  72. <releases>
  73. <enabled>true</enabled>
  74. <updatePolicy>never</updatePolicy>
  75. </releases>
  76. </repository>
  77. </repositories>
  78. <pluginRepositories>
  79. <!--
  80. Repeat Central definition from super POM https://maven.apache.org/ref/3.6.3/maven-model-builder/super-pom.html.
  81. Define it as the first repository to search at, otherwise Maven would always search any other repositories defined
  82. in the POM or in settings.xml first, slowing down the build, because most artifacts reside at Maven Central. See
  83. https://maven.apache.org/guides/mini/guide-multiple-repositories.html#repository-order for more details.
  84. -->
  85. <pluginRepository>
  86. <id>central</id>
  87. <name>Central Repository</name>
  88. <url>https://repo.maven.apache.org/maven2</url>
  89. <layout>default</layout>
  90. <snapshots>
  91. <enabled>false</enabled>
  92. </snapshots>
  93. <releases>
  94. <enabled>true</enabled>
  95. <updatePolicy>never</updatePolicy>
  96. </releases>
  97. </pluginRepository>
  98. <pluginRepository>
  99. <id>ossrh-snapshots</id>
  100. <name>Sonatype OSSRH snapshots</name>
  101. <url>https://oss.sonatype.org/content/repositories/snapshots</url>
  102. <layout>default</layout>
  103. <snapshots>
  104. <enabled>true</enabled>
  105. <updatePolicy>always</updatePolicy>
  106. </snapshots>
  107. <releases>
  108. <enabled>true</enabled>
  109. <updatePolicy>never</updatePolicy>
  110. </releases>
  111. </pluginRepository>
  112. </pluginRepositories>
  113. <modules>
  114. <module>lib</module>
  115. <module>util</module>
  116. <module>bridge</module>
  117. <module>testing-util</module>
  118. <module>org.aspectj.matcher</module>
  119. <module>asm</module>
  120. <module>testing-client</module>
  121. <module>runtime</module>
  122. <module>bcel-builder</module>
  123. <module>weaver</module>
  124. <module>loadtime</module>
  125. <module>org.aspectj.ajdt.core</module>
  126. <module>ajde.core</module>
  127. <module>ajde</module>
  128. <module>ajdoc</module>
  129. <module>taskdefs</module>
  130. <module>testing</module>
  131. <module>testing-drivers</module>
  132. <module>tests</module>
  133. <module>build</module>
  134. <module>run-all-junit-tests</module>
  135. <module>docs</module>
  136. <!-- create the important artifacts we care about -->
  137. <module>aspectjrt</module>
  138. <module>aspectjweaver</module>
  139. <module>aspectjtools</module>
  140. <module>aspectjmatcher</module>
  141. <!-- build the java -jar'able installer -->
  142. <module>installer</module>
  143. </modules>
  144. <!--
  145. Caveat: Automatic, JDK-based profile activation can *not* be inherited by child POMs defining
  146. the same profiles. Thus, we have to repeat activation conditions there.
  147. Note: We can check if automatic profile activation works via mvn help:active-profiles.
  148. -->
  149. <profiles>
  150. <profile>
  151. <id>jdk-8-to-15</id>
  152. <activation>
  153. <jdk>[1.8,16)</jdk>
  154. </activation>
  155. <properties>
  156. <jvm.arg.addOpens/>
  157. <jvm.arg.allowSecurityManager/>
  158. </properties>
  159. </profile>
  160. <profile>
  161. <id>jdk-16-to-xx</id>
  162. <activation>
  163. <jdk>[16,)</jdk>
  164. </activation>
  165. <properties>
  166. <jvm.arg.addOpens>--add-opens java.base/java.lang=ALL-UNNAMED</jvm.arg.addOpens>
  167. <jvm.arg.allowSecurityManager/>
  168. </properties>
  169. </profile>
  170. <profile>
  171. <id>jdk-18-to-xx</id>
  172. <activation>
  173. <jdk>[18,)</jdk>
  174. </activation>
  175. <properties>
  176. <!--
  177. JEP 411: Deprecate the Security Manager for Removal, see https://openjdk.java.net/jeps/411.
  178. As of Java 18, the new API for blocking System.exit is not available yet, see
  179. https://bugs.openjdk.java.net/browse/JDK-8199704.
  180. -->
  181. <jvm.arg.allowSecurityManager>-Djava.security.manager=allow</jvm.arg.allowSecurityManager>
  182. </properties>
  183. </profile>
  184. <profile>
  185. <id>release</id>
  186. <properties>
  187. <maven.javadoc.skip>false</maven.javadoc.skip>
  188. <maven.source.skip>false</maven.source.skip>
  189. </properties>
  190. <build>
  191. <plugins>
  192. <plugin>
  193. <groupId>org.apache.maven.plugins</groupId>
  194. <artifactId>maven-gpg-plugin</artifactId>
  195. </plugin>
  196. </plugins>
  197. </build>
  198. </profile>
  199. <profile>
  200. <id>fast-build</id>
  201. <properties>
  202. <!-- Do not compile tests (also skips execution) -->
  203. <maven.test.skip>true</maven.test.skip>
  204. <!-- Do not execute tests (redundant, but just to be sure) -->
  205. <skipTests>true</skipTests>
  206. <!-- Do not create documentation for AspectJ website -->
  207. <createDocs>false</createDocs>
  208. </properties>
  209. </profile>
  210. </profiles>
  211. <build>
  212. <pluginManagement>
  213. <plugins>
  214. <plugin>
  215. <groupId>org.apache.maven.plugins</groupId>
  216. <artifactId>maven-compiler-plugin</artifactId>
  217. <version>3.8.1</version>
  218. <configuration>
  219. <source>1.8</source>
  220. <target>1.8</target>
  221. </configuration>
  222. </plugin>
  223. <plugin>
  224. <groupId>org.apache.maven.plugins</groupId>
  225. <artifactId>maven-surefire-plugin</artifactId>
  226. <version>2.22.2</version>
  227. <configuration>
  228. <!--<testFailureIgnore>true</testFailureIgnore>-->
  229. <argLine>
  230. ${jvm.arg.addOpens}
  231. ${jvm.arg.allowSecurityManager}
  232. </argLine>
  233. <excludes>
  234. <exclude>**/*ModuleTests.java</exclude>
  235. </excludes>
  236. </configuration>
  237. </plugin>
  238. <plugin>
  239. <groupId>org.apache.maven.plugins</groupId>
  240. <artifactId>maven-help-plugin</artifactId>
  241. <version>3.2.0</version>
  242. </plugin>
  243. <plugin>
  244. <groupId>org.apache.maven.plugins</groupId>
  245. <artifactId>maven-source-plugin</artifactId>
  246. <version>3.2.0</version>
  247. <executions>
  248. <execution>
  249. <id>attach-sources</id>
  250. <phase>package</phase>
  251. <goals>
  252. <goal>jar-no-fork</goal>
  253. </goals>
  254. </execution>
  255. </executions>
  256. </plugin>
  257. <plugin>
  258. <groupId>org.apache.maven.plugins</groupId>
  259. <artifactId>maven-jar-plugin</artifactId>
  260. <version>3.2.0</version>
  261. <configuration>
  262. <archive>
  263. <addMavenDescriptor>false</addMavenDescriptor>
  264. </archive>
  265. </configuration>
  266. <executions>
  267. <execution>
  268. <id>test-jar</id>
  269. <goals>
  270. <goal>test-jar</goal>
  271. </goals>
  272. </execution>
  273. </executions>
  274. </plugin>
  275. <plugin>
  276. <groupId>org.apache.maven.plugins</groupId>
  277. <artifactId>maven-shade-plugin</artifactId>
  278. <version>3.3.0</version>
  279. <configuration>
  280. <createSourcesJar>true</createSourcesJar>
  281. <createDependencyReducedPom>false</createDependencyReducedPom>
  282. <shadedArtifactAttached>false</shadedArtifactAttached>
  283. </configuration>
  284. </plugin>
  285. <plugin>
  286. <groupId>org.apache.maven.plugins</groupId>
  287. <artifactId>maven-install-plugin</artifactId>
  288. <version>2.5.2</version>
  289. </plugin>
  290. <plugin>
  291. <groupId>org.apache.maven.plugins</groupId>
  292. <artifactId>maven-enforcer-plugin</artifactId>
  293. <version>3.0.0-M3</version>
  294. </plugin>
  295. <plugin>
  296. <groupId>org.codehaus.mojo</groupId>
  297. <artifactId>build-helper-maven-plugin</artifactId>
  298. <version>3.2.0</version>
  299. </plugin>
  300. <plugin>
  301. <groupId>org.apache.maven.plugins</groupId>
  302. <artifactId>maven-clean-plugin</artifactId>
  303. <version>3.1.0</version>
  304. </plugin>
  305. <plugin>
  306. <groupId>org.apache.maven.plugins</groupId>
  307. <artifactId>maven-dependency-plugin</artifactId>
  308. <version>3.1.2</version>
  309. </plugin>
  310. <plugin>
  311. <groupId>org.apache.maven.plugins</groupId>
  312. <artifactId>maven-assembly-plugin</artifactId>
  313. <version>3.1.1</version>
  314. </plugin>
  315. <!--
  316. TODO: MSHADE-36 is in Maven Shade 3.3.0 -> it should be possible to include the dependency-reduced POM there
  317. directly. So maybe, we can rid of Flatten Maven Plugin.
  318. -->
  319. <plugin>
  320. <groupId>org.codehaus.mojo</groupId>
  321. <artifactId>flatten-maven-plugin</artifactId>
  322. <version>1.2.2</version>
  323. </plugin>
  324. <plugin>
  325. <groupId>org.apache.maven.plugins</groupId>
  326. <artifactId>maven-gpg-plugin</artifactId>
  327. <version>1.6</version>
  328. <executions>
  329. <execution>
  330. <id>sign-artifacts</id>
  331. <phase>verify</phase>
  332. <goals>
  333. <goal>sign</goal>
  334. </goals>
  335. <configuration>
  336. <!-- Only sign artifacts which are also meant to be deployed -->
  337. <skip>${maven.gpg.skip}</skip>
  338. </configuration>
  339. </execution>
  340. </executions>
  341. </plugin>
  342. <plugin>
  343. <artifactId>maven-deploy-plugin</artifactId>
  344. <version>2.8.2</version>
  345. <executions>
  346. <execution>
  347. <id>default-deploy</id>
  348. <phase>deploy</phase>
  349. <goals>
  350. <goal>deploy</goal>
  351. </goals>
  352. </execution>
  353. </executions>
  354. <configuration>
  355. <!-- Deploy at the end of a multi-module build -->
  356. <deployAtEnd>true</deployAtEnd>
  357. </configuration>
  358. </plugin>
  359. <plugin>
  360. <!--
  361. Other than Maven Deploy, this plugin cannot just be added to the 'build/plugins' section of the parent POM
  362. once and (de-)activated with a simple property like 'maven.deploy.skip' on a per-module basis. See also
  363. https://issues.sonatype.org/browse/OSSRH-68966. Consequently, we do not add it to the parent but separately
  364. to each module meant to be published.
  365. -->
  366. <groupId>org.sonatype.plugins</groupId>
  367. <artifactId>nexus-staging-maven-plugin</artifactId>
  368. <version>1.6.8</version>
  369. <extensions>true</extensions>
  370. <configuration>
  371. <serverId>ossrh</serverId>
  372. <nexusUrl>https://oss.sonatype.org/</nexusUrl>
  373. <!-- Activate in order to directly release to Maven Central after successful staging -->
  374. <autoReleaseAfterClose>false</autoReleaseAfterClose>
  375. </configuration>
  376. <dependencies>
  377. <!--
  378. Plugin version 1.6.8 does not work on JDK 16+ without special MAVEN_OPTS opening certain modules,
  379. because the XStream version used needs it. One workaround is to use a more recent XStream version.
  380. Attention: Do *not* upgrade to e.g. 1.4.18, because it causes exceptions during deployment.
  381. TODO: remove plugin dependency after OSSRH-66257, NEXUS-26993 are fixed.
  382. -->
  383. <dependency>
  384. <groupId>com.thoughtworks.xstream</groupId>
  385. <artifactId>xstream</artifactId>
  386. <version>1.4.15</version>
  387. </dependency>
  388. </dependencies>
  389. </plugin>
  390. <plugin>
  391. <groupId>org.codehaus.mojo</groupId>
  392. <artifactId>truezip-maven-plugin</artifactId>
  393. <version>1.2</version>
  394. </plugin>
  395. <plugin>
  396. <groupId>org.apache.maven.plugins</groupId>
  397. <artifactId>maven-javadoc-plugin</artifactId>
  398. <version>3.2.0</version>
  399. </plugin>
  400. </plugins>
  401. </pluginManagement>
  402. <plugins>
  403. <plugin>
  404. <groupId>org.apache.maven.plugins</groupId>
  405. <artifactId>maven-jar-plugin</artifactId>
  406. </plugin>
  407. <plugin>
  408. <artifactId>maven-clean-plugin</artifactId>
  409. <configuration>
  410. <filesets>
  411. <fileset>
  412. <directory>.</directory>
  413. <includes>
  414. <!-- AspectJ core dumps -->
  415. <include>**/ajcore.*.txt</include>
  416. <!-- Test temp-dirs in 'weaver' module, see AsynchronousFileCacheBackingTestSupport.getCacheDir -->
  417. <include>**/dir-0.*/**</include>
  418. </includes>
  419. <followSymlinks>false</followSymlinks>
  420. </fileset>
  421. <fileset>
  422. <directory>aj-build</directory>
  423. <followSymlinks>false</followSymlinks>
  424. </fileset>
  425. </filesets>
  426. </configuration>
  427. </plugin>
  428. <!--
  429. This plugin is nice to have in the POM, because then it is easy to double-click a goal such as 'effective-pom',
  430. 'active-profiles', 'effective-settings' or 'evaluate' from a modern IDE in order to get quick information about
  431. the current build configuration for any given module.
  432. -->
  433. <plugin>
  434. <groupId>org.apache.maven.plugins</groupId>
  435. <artifactId>maven-help-plugin</artifactId>
  436. </plugin>
  437. <!--
  438. This plugin is nice to have in the POM, because then it is easy to double-click a goal such as 'analyze' or
  439. 'tree' from a modern IDE in order to inspect dependency management in the project.
  440. Tip: If you want a quick overview, run this from the project from the project root directory:
  441. mvn -P \!create-docs dependency:analyze | grep -E '\[(WARNING|INFO\] -+< .+:.+ >-+)' > dependency-analyze.txt
  442. But be careful that all modules are actually listed - usually 'org.aspectj:installer' is the last one in the
  443. list. You can make sure by running the command without 'grep' first, then you see if there are any compile
  444. problems which 'grep' would filter out.
  445. -->
  446. <plugin>
  447. <groupId>org.apache.maven.plugins</groupId>
  448. <artifactId>maven-dependency-plugin</artifactId>
  449. <configuration>
  450. <ignoredUnusedDeclaredDependencies>
  451. <!-- Declared in parent POM for convenience, but not used in every module -->
  452. <ignoredUnusedDeclaredDependency>junit:junit:jar</ignoredUnusedDeclaredDependency>
  453. <ignoredUnusedDeclaredDependency>org.aspectj:lib:jar</ignoredUnusedDeclaredDependency>
  454. </ignoredUnusedDeclaredDependencies>
  455. </configuration>
  456. </plugin>
  457. </plugins>
  458. </build>
  459. <dependencyManagement>
  460. <dependencies>
  461. <dependency>
  462. <groupId>org.junit</groupId>
  463. <artifactId>junit-bom</artifactId>
  464. <version>5.7.1</version>
  465. <type>pom</type>
  466. <scope>import</scope>
  467. </dependency>
  468. <dependency>
  469. <groupId>junit</groupId>
  470. <artifactId>junit</artifactId>
  471. <version>4.13.2</version>
  472. <scope>test</scope>
  473. </dependency>
  474. <dependency>
  475. <groupId>org.aspectj</groupId>
  476. <artifactId>org.eclipse.jdt.core</artifactId>
  477. <version>${jdt.core.version}</version>
  478. </dependency>
  479. <dependency>
  480. <!-- Because commons-digester:commons-digester:1.3 refers to version 1.4-dev -->
  481. <groupId>commons-beanutils</groupId>
  482. <artifactId>commons-beanutils</artifactId>
  483. <version>${lib.commons.beanutils.version}</version>
  484. </dependency>
  485. <dependency>
  486. <groupId>org.ow2.asm</groupId>
  487. <artifactId>asm</artifactId>
  488. <version>${asm.version}</version>
  489. </dependency>
  490. <dependency>
  491. <!-- All modules referencing files inside 'lib' need this dependency -->
  492. <groupId>org.aspectj</groupId>
  493. <artifactId>lib</artifactId>
  494. <version>${project.version}</version>
  495. </dependency>
  496. </dependencies>
  497. </dependencyManagement>
  498. <dependencies>
  499. <!--
  500. Actually, it would be cleaner to only define JUnit only it modules which actually use it. But since this comprises
  501. the majority, we can afford to be a little bit unclean here with regard to dependency management.
  502. -->
  503. <dependency>
  504. <groupId>junit</groupId>
  505. <artifactId>junit</artifactId>
  506. <scope>test</scope>
  507. </dependency>
  508. </dependencies>
  509. </project>