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 11KB

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
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
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
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <project xmlns="http://maven.apache.org/POM/4.0.0"
  3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4. xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  5. <modelVersion>4.0.0</modelVersion>
  6. <groupId>org.aspectj</groupId>
  7. <artifactId>aspectj-parent</artifactId>
  8. <packaging>pom</packaging>
  9. <version>1.9.7.BUILD-SNAPSHOT</version>
  10. <name>AspectJ Parent Project</name>
  11. <properties>
  12. <revision>1.9.7.BUILD-SNAPSHOT</revision>
  13. <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  14. <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
  15. <jdt.core.version>3.25.0-SNAPSHOT</jdt.core.version>
  16. <lib.ant.version>1.6.3</lib.ant.version>
  17. <lib.ant.xerces.version>2.6.2</lib.ant.xerces.version>
  18. <lib.regexp.version>1.2</lib.regexp.version>
  19. <lib.commons.beanutils.version>1.4</lib.commons.beanutils.version>
  20. <lib.commons.beanutils.tag>BEANUTILS_1_4</lib.commons.beanutils.tag>
  21. <lib.commons.collections.version>2.0</lib.commons.collections.version>
  22. <lib.commons.collections.tag>collections-2.0</lib.commons.collections.tag>
  23. <lib.commons.digester.version>1.3</lib.commons.digester.version>
  24. <lib.commons.digester.tag>DIGESTER_1_3</lib.commons.digester.tag>
  25. <lib.commons.logging.version>1.0.1</lib.commons.logging.version>
  26. <lib.commons.logging.tag>LOGGING_1_0_1</lib.commons.logging.tag>
  27. <asm.version>9.1</asm.version>
  28. </properties>
  29. <repositories>
  30. <!--
  31. Separately built dependencies unavailable on Maven Central, e.g.:
  32. - org.aspectj:asm-renamed
  33. - org.aspectj:org.eclipse.jdt.core
  34. -->
  35. <repository>
  36. <id>github</id>
  37. <name>GitHub Packages</name>
  38. <url>https://maven.pkg.github.com/kriegaex/aspectj-packages</url>
  39. <snapshots>
  40. <enabled>true</enabled>
  41. </snapshots>
  42. </repository>
  43. </repositories>
  44. <modules>
  45. <module>lib</module>
  46. <module>util</module>
  47. <module>bridge</module>
  48. <module>testing-util</module>
  49. <module>org.aspectj.matcher</module>
  50. <module>asm</module>
  51. <module>testing-client</module>
  52. <module>ajbrowser</module>
  53. <module>runtime</module>
  54. <module>bcel-builder</module>
  55. <module>weaver</module>
  56. <module>loadtime</module>
  57. <module>org.aspectj.ajdt.core</module>
  58. <module>ajde.core</module>
  59. <module>ajde</module>
  60. <module>ajdoc</module>
  61. <module>taskdefs</module>
  62. <module>testing</module>
  63. <module>testing-drivers</module>
  64. <module>tests</module>
  65. <module>build</module>
  66. <module>run-all-junit-tests</module>
  67. <module>docs</module>
  68. <!-- FYI: These are NOT meant to be sub-modules but a stand-alone projects built and deployed independently. -->
  69. <!--
  70. <module>asm-renamed</module>
  71. -->
  72. <!-- create the important artifacts we care about -->
  73. <module>aspectjrt</module>
  74. <module>aspectjweaver</module>
  75. <module>aspectjtools</module>
  76. <module>aspectjmatcher</module>
  77. <!-- build the java -jar'able installer -->
  78. <module>installer</module>
  79. </modules>
  80. <!--
  81. Caveat: Automatic, JDK-based profile activation can *not* be inherited by child POMs defining
  82. the same profiles. Thus, we have to repeat activation conditions there.
  83. Note: We can check if automatic profile activation works via mvn help:active-profiles.
  84. -->
  85. <profiles>
  86. <profile>
  87. <id>jdk-8-to-15</id>
  88. <activation>
  89. <jdk>[1.8,16)</jdk>
  90. </activation>
  91. <properties>
  92. <jvm.arg.addOpens/>
  93. </properties>
  94. </profile>
  95. <profile>
  96. <id>jdk-16-to-xx</id>
  97. <activation>
  98. <jdk>[16,)</jdk>
  99. </activation>
  100. <properties>
  101. <jvm.arg.addOpens>--add-opens java.base/java.lang=ALL-UNNAMED</jvm.arg.addOpens>
  102. </properties>
  103. </profile>
  104. </profiles>
  105. <build>
  106. <pluginManagement>
  107. <plugins>
  108. <plugin>
  109. <groupId>org.apache.maven.plugins</groupId>
  110. <artifactId>maven-compiler-plugin</artifactId>
  111. <version>3.8.1</version>
  112. <configuration>
  113. <source>1.8</source>
  114. <target>1.8</target>
  115. </configuration>
  116. </plugin>
  117. <plugin>
  118. <groupId>org.apache.maven.plugins</groupId>
  119. <artifactId>maven-surefire-plugin</artifactId>
  120. <version>2.22.2</version>
  121. <configuration>
  122. <!--<testFailureIgnore>true</testFailureIgnore>-->
  123. <argLine>${jvm.arg.addOpens}</argLine>
  124. <excludes>
  125. <exclude>**/*ModuleTests.java</exclude>
  126. </excludes>
  127. </configuration>
  128. </plugin>
  129. <plugin>
  130. <groupId>org.apache.maven.plugins</groupId>
  131. <artifactId>maven-help-plugin</artifactId>
  132. <version>3.2.0</version>
  133. </plugin>
  134. <plugin>
  135. <groupId>org.apache.maven.plugins</groupId>
  136. <artifactId>maven-source-plugin</artifactId>
  137. <version>3.2.0</version>
  138. <executions>
  139. <execution>
  140. <id>attach-sources</id>
  141. <phase>package</phase>
  142. <goals>
  143. <goal>jar-no-fork</goal>
  144. </goals>
  145. </execution>
  146. </executions>
  147. </plugin>
  148. <plugin>
  149. <groupId>org.apache.maven.plugins</groupId>
  150. <artifactId>maven-jar-plugin</artifactId>
  151. <version>3.2.0</version>
  152. <configuration>
  153. <archive>
  154. <addMavenDescriptor>false</addMavenDescriptor>
  155. </archive>
  156. </configuration>
  157. <executions>
  158. <execution>
  159. <id>test-jar</id>
  160. <goals>
  161. <goal>test-jar</goal>
  162. </goals>
  163. </execution>
  164. </executions>
  165. </plugin>
  166. <plugin>
  167. <groupId>org.apache.maven.plugins</groupId>
  168. <artifactId>maven-shade-plugin</artifactId>
  169. <!-- TODO: upgrade after https://issues.apache.org/jira/browse/MSHADE-366 is fixed -->
  170. <version>3.2.4</version>
  171. <configuration>
  172. <createSourcesJar>true</createSourcesJar>
  173. <createDependencyReducedPom>false</createDependencyReducedPom>
  174. <shadedArtifactAttached>false</shadedArtifactAttached>
  175. </configuration>
  176. </plugin>
  177. <plugin>
  178. <groupId>org.apache.maven.plugins</groupId>
  179. <artifactId>maven-install-plugin</artifactId>
  180. <version>2.5.2</version>
  181. </plugin>
  182. <plugin>
  183. <groupId>org.apache.maven.plugins</groupId>
  184. <artifactId>maven-enforcer-plugin</artifactId>
  185. <version>3.0.0-M3</version>
  186. </plugin>
  187. <plugin>
  188. <groupId>org.codehaus.mojo</groupId>
  189. <artifactId>build-helper-maven-plugin</artifactId>
  190. <version>3.2.0</version>
  191. </plugin>
  192. <plugin>
  193. <groupId>org.apache.maven.plugins</groupId>
  194. <artifactId>maven-clean-plugin</artifactId>
  195. <version>3.1.0</version>
  196. </plugin>
  197. <plugin>
  198. <groupId>org.apache.maven.plugins</groupId>
  199. <artifactId>maven-dependency-plugin</artifactId>
  200. <version>3.1.2</version>
  201. </plugin>
  202. <plugin>
  203. <groupId>org.apache.maven.plugins</groupId>
  204. <artifactId>maven-assembly-plugin</artifactId>
  205. <version>3.1.1</version>
  206. </plugin>
  207. <plugin>
  208. <groupId>org.codehaus.mojo</groupId>
  209. <artifactId>flatten-maven-plugin</artifactId>
  210. <version>1.2.2</version>
  211. </plugin>
  212. </plugins>
  213. </pluginManagement>
  214. <plugins>
  215. <plugin>
  216. <groupId>org.apache.maven.plugins</groupId>
  217. <artifactId>maven-jar-plugin</artifactId>
  218. </plugin>
  219. <plugin>
  220. <artifactId>maven-clean-plugin</artifactId>
  221. <configuration>
  222. <filesets>
  223. <fileset>
  224. <directory>.</directory>
  225. <includes>
  226. <!-- AspectJ core dumps -->
  227. <include>**/ajcore.*.txt</include>
  228. <!-- Test temp-dirs in 'weaver' module, see AsynchronousFileCacheBackingTestSupport.getCacheDir -->
  229. <include>**/dir-0.*/**</include>
  230. </includes>
  231. <followSymlinks>false</followSymlinks>
  232. </fileset>
  233. <fileset>
  234. <directory>aj-build</directory>
  235. <followSymlinks>false</followSymlinks>
  236. </fileset>
  237. </filesets>
  238. </configuration>
  239. </plugin>
  240. <!--
  241. This plugin is nice to have in the POM, because then it is easy to double-click a goal such as 'effective-pom',
  242. 'active-profiles', 'effective-settings' or 'evaluate' from a modern IDE in order to get quick information about
  243. the current build configuration for any given module.
  244. -->
  245. <plugin>
  246. <groupId>org.apache.maven.plugins</groupId>
  247. <artifactId>maven-help-plugin</artifactId>
  248. </plugin>
  249. <!--
  250. This plugin is nice to have in the POM, because then it is easy to double-click a goal such as 'analyze' or
  251. 'tree' from a modern IDE in order to inspect dependency management in the project.
  252. Tip: If you want a quick overview, run this from the project from the project root directory:
  253. mvn -P \!create-docs dependency:analyze | grep -E '\[(WARNING|INFO\] -+< .+:.+ >-+)' > dependency-analyze.txt
  254. But be careful that all modules are actually listed - usually 'org.aspectj:installer' is the last one in the
  255. list. You can make sure by running the command without 'grep' first, then you see if there are any compile
  256. problems which 'grep' would filter out.
  257. -->
  258. <plugin>
  259. <groupId>org.apache.maven.plugins</groupId>
  260. <artifactId>maven-dependency-plugin</artifactId>
  261. <configuration>
  262. <ignoredUnusedDeclaredDependencies>
  263. <!-- Declared in parent POM for convenience, but not used in every module -->
  264. <ignoredUnusedDeclaredDependency>junit:junit:jar</ignoredUnusedDeclaredDependency>
  265. <ignoredUnusedDeclaredDependency>org.aspectj:lib:jar</ignoredUnusedDeclaredDependency>
  266. </ignoredUnusedDeclaredDependencies>
  267. </configuration>
  268. </plugin>
  269. </plugins>
  270. </build>
  271. <dependencyManagement>
  272. <dependencies>
  273. <dependency>
  274. <groupId>org.junit</groupId>
  275. <artifactId>junit-bom</artifactId>
  276. <version>5.7.1</version>
  277. <type>pom</type>
  278. <scope>import</scope>
  279. </dependency>
  280. <dependency>
  281. <groupId>junit</groupId>
  282. <artifactId>junit</artifactId>
  283. <version>4.13.2</version>
  284. <scope>test</scope>
  285. </dependency>
  286. <dependency>
  287. <groupId>org.aspectj</groupId>
  288. <artifactId>org.eclipse.jdt.core</artifactId>
  289. <version>${jdt.core.version}</version>
  290. </dependency>
  291. <dependency>
  292. <!-- Because commons-digester:commons-digester:1.3 refers to version 1.4-dev -->
  293. <groupId>commons-beanutils</groupId>
  294. <artifactId>commons-beanutils</artifactId>
  295. <version>${lib.commons.beanutils.version}</version>
  296. </dependency>
  297. <dependency>
  298. <groupId>org.ow2.asm</groupId>
  299. <artifactId>asm</artifactId>
  300. <version>${asm.version}</version>
  301. </dependency>
  302. <dependency>
  303. <groupId>org.aspectj</groupId>
  304. <artifactId>asm-renamed</artifactId>
  305. <version>${asm.version}</version>
  306. </dependency>
  307. <dependency>
  308. <!-- All modules referencing files inside 'lib' need this dependency -->
  309. <groupId>org.aspectj</groupId>
  310. <artifactId>lib</artifactId>
  311. <version>${project.version}</version>
  312. </dependency>
  313. </dependencies>
  314. </dependencyManagement>
  315. <dependencies>
  316. <!--
  317. Actually, it would be cleaner to only define JUnit only it modules which actually use it. But since this comprises
  318. the majority, we can afford to be a little bit unclean here with regard to dependency management.
  319. -->
  320. <dependency>
  321. <groupId>junit</groupId>
  322. <artifactId>junit</artifactId>
  323. <scope>test</scope>
  324. </dependency>
  325. </dependencies>
  326. </project>