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

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
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
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
2 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
2 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
2 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
Use dependencies instead of copies under 'lib' for assemblies 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>
3 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434
  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. <parent>
  6. <groupId>org.aspectj</groupId>
  7. <artifactId>aspectj-parent</artifactId>
  8. <version>1.9.20-SNAPSHOT</version>
  9. </parent>
  10. <artifactId>aspectjtools</artifactId>
  11. <name>AspectJ Tools (Compiler)</name>
  12. <description>
  13. AspectJ tools most notably contains the AspectJ compiler (AJC). AJC applies aspects to Java classes during
  14. compilation, fully replacing Javac for plain Java classes and also compiling native AspectJ or annotation-based
  15. @AspectJ syntax. Furthermore, AJC can weave aspects into existing class files in a post-compile binary weaving step.
  16. This library is a superset of AspectJ weaver and hence also of AspectJ runtime.
  17. </description>
  18. <url>https://www.eclipse.org/aspectj/</url>
  19. <licenses>
  20. <license>
  21. <name>Eclipse Public License - v 2.0</name>
  22. <url>https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt</url>
  23. <distribution>repo</distribution>
  24. </license>
  25. </licenses>
  26. <developers>
  27. <developer>
  28. <id>aclement</id>
  29. <name>Andy Clement</name>
  30. <email>aclement@vmware.com</email>
  31. </developer>
  32. <developer>
  33. <id>kriegaex</id>
  34. <name>Alexander Kriegisch</name>
  35. <email>kriegaex@aspectj.dev</email>
  36. </developer>
  37. </developers>
  38. <scm>
  39. <url>https://github.com/eclipse/org.aspectj</url>
  40. <connection>scm:git:https://github.com/eclipse/org.aspectj.git</connection>
  41. <developerConnection>scm:git:ssh://git@github.com:eclipse/org.aspectj.git</developerConnection>
  42. </scm>
  43. <properties>
  44. <!-- By default, do not deploy artifacts - but deploy this public one -->
  45. <maven.deploy.skip>false</maven.deploy.skip>
  46. <!-- By default, do not sign artifacts - but sign this public one -->
  47. <maven.gpg.skip>false</maven.gpg.skip>
  48. </properties>
  49. <build>
  50. <plugins>
  51. <!-- Skip creation of main + test JARs -->
  52. <plugin>
  53. <groupId>org.apache.maven.plugins</groupId>
  54. <artifactId>maven-jar-plugin</artifactId>
  55. <executions>
  56. <execution>
  57. <id>default-jar</id>
  58. <phase>none</phase>
  59. </execution>
  60. <execution>
  61. <id>test-jar</id>
  62. <phase>none</phase>
  63. </execution>
  64. </executions>
  65. </plugin>
  66. <plugin>
  67. <groupId>org.apache.maven.plugins</groupId>
  68. <artifactId>maven-dependency-plugin</artifactId>
  69. <executions>
  70. <execution>
  71. <id>unzip-dependency-sources</id>
  72. <goals>
  73. <goal>unpack-dependencies</goal>
  74. </goals>
  75. <phase>prepare-package</phase>
  76. <configuration>
  77. <classifier>sources</classifier>
  78. <!--<failOnMissingClassifierArtifact>false</failOnMissingClassifierArtifact>-->
  79. <includeGroupIds>org.aspectj,org.ow2.asm</includeGroupIds>
  80. <includeArtifactIds>org.eclipse.jdt.core,asm</includeArtifactIds>
  81. <outputDirectory>${project.build.directory}/unzipped-sources</outputDirectory>
  82. <!-- Avoid accidentally shading test-scoped dependencies like JUnit -->
  83. <includeScope>runtime</includeScope>
  84. </configuration>
  85. </execution>
  86. </executions>
  87. </plugin>
  88. <plugin>
  89. <groupId>org.apache.maven.plugins</groupId>
  90. <artifactId>maven-assembly-plugin</artifactId>
  91. <executions>
  92. <execution>
  93. <id>aspectjtools-assembly</id>
  94. <phase>package</phase>
  95. <goals>
  96. <goal>single</goal>
  97. </goals>
  98. <configuration>
  99. <finalName>aspectjtools-${project.version}</finalName>
  100. <appendAssemblyId>false</appendAssemblyId>
  101. <archive>
  102. <manifestEntries>
  103. <Automatic-Module-Name>org.aspectj.tools</Automatic-Module-Name>
  104. </manifestEntries>
  105. <manifestSections>
  106. <manifestSection>
  107. <name>org/aspectj/tools/</name>
  108. <manifestEntries>
  109. <Specification-Title>AspectJ Tools Classes</Specification-Title>
  110. <Specification-Version>${project.version}</Specification-Version>
  111. <Specification-Vendor>https://www.eclipse.org/aspectj/</Specification-Vendor>
  112. <Implementation-Title>org.aspectj.tools</Implementation-Title>
  113. <Implementation-Version>${project.version}</Implementation-Version>
  114. <Implementation-Vendor>https://www.eclipse.org/aspectj/</Implementation-Vendor>
  115. <Bundle-Name>AspectJ Tools</Bundle-Name>
  116. <Bundle-Version>${project.version}</Bundle-Version>
  117. <!--
  118. WARNING: Please avoid line breaks in manifest values! They are passed on like this:
  119. Assembly Plugin -> Plexus Archiver -> JRE java.util.jar.Manifest.write(OutputStream).
  120. The JRE Manifest class inserts hard line breaks always after 72 characters, no matter if those
  121. 72 characters contain line feeds, tabs or spaces. Hence, it can happen that unwanted blank lines
  122. end up in the middle of a manifest section, making the manifest invalid. Calls like e.g.
  123. 'java -cp aspectjtools.jar org.aspectj.tools.ajc.Main' can then fail with the absolutely
  124. unexpected error 'Could not find or load main class org.aspectj.tools.ajc.Main'.
  125. Alexander Kriegisch created this bug ticket:
  126. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8263924
  127. In IntelliJ IDEA you can deactivate wrapping text inside XML tags like this:
  128. File | Settings | Editor | Code Style | XML | Wrap text -> deactivate
  129. -->
  130. <Bundle-Copyright>(C) Copyright 1999-2001 Xerox Corporation, 2002 Palo Alto Research Center, Incorporated (PARC), 2003-2020 Contributors. All Rights Reserved</Bundle-Copyright>
  131. </manifestEntries>
  132. </manifestSection>
  133. </manifestSections>
  134. </archive>
  135. <descriptors>
  136. <descriptor>aspectjtools-assembly.xml</descriptor>
  137. </descriptors>
  138. </configuration>
  139. </execution>
  140. <execution>
  141. <id>aspectjtools-sources-assembly</id>
  142. <phase>package</phase>
  143. <goals>
  144. <goal>single</goal>
  145. </goals>
  146. <configuration>
  147. <!-- The assembly ID 'sources' becomes the artifact classifier, exactly what we want -->
  148. <appendAssemblyId>true</appendAssemblyId>
  149. <skipAssembly>${maven.source.skip}</skipAssembly>
  150. <archive>
  151. </archive>
  152. <descriptors>
  153. <descriptor>aspectjtools-sources-assembly.xml</descriptor>
  154. </descriptors>
  155. </configuration>
  156. </execution>
  157. </executions>
  158. </plugin>
  159. <!--
  160. Relocate ASM from 'org.objectweb.asm' to 'aj.org.objectweb.asm'
  161. TODO: Using Maven Shade after Maven Assembly instead of creating uber JAR and relocating package names at the
  162. same time is suboptimal and maybe slower than doing both at the same time. Migrating from Assembly to Shade
  163. requires all dependencies to produce source JARs, though, which currently is not the case. Because we also
  164. want to create a complete source JAR, for now we keep Assembly around, because it manually copies project
  165. sources from their respective directories before zipping them up.
  166. -->
  167. <plugin>
  168. <groupId>org.apache.maven.plugins</groupId>
  169. <artifactId>maven-shade-plugin</artifactId>
  170. <configuration>
  171. <createSourcesJar>true</createSourcesJar>
  172. <createDependencyReducedPom>false</createDependencyReducedPom>
  173. <shadedArtifactAttached>false</shadedArtifactAttached>
  174. </configuration>
  175. <executions>
  176. <execution>
  177. <id>asm-relocate</id>
  178. <phase>package</phase>
  179. <goals>
  180. <goal>shade</goal>
  181. </goals>
  182. <configuration>
  183. <minimizeJar>false</minimizeJar>
  184. <shadeSourcesContent>true</shadeSourcesContent>
  185. <artifactSet>
  186. <includes>
  187. <include>${project.groupId}:${project.artifactId}</include>
  188. </includes>
  189. </artifactSet>
  190. <relocations>
  191. <relocation>
  192. <pattern>org.objectweb.asm</pattern>
  193. <shadedPattern>aj.org.objectweb.asm</shadedPattern>
  194. </relocation>
  195. </relocations>
  196. </configuration>
  197. </execution>
  198. </executions>
  199. </plugin>
  200. <plugin>
  201. <groupId>org.codehaus.mojo</groupId>
  202. <artifactId>truezip-maven-plugin</artifactId>
  203. <executions>
  204. <execution>
  205. <id>unzip-relocated-sources</id>
  206. <phase>package</phase>
  207. <goals>
  208. <goal>copy</goal>
  209. </goals>
  210. <configuration>
  211. <!--
  212. Skip, if javadoc generation is also meant to be skipped, which is the default unless the 'release'
  213. profile is active or the property is overridden manually to be false. See property definitions in parent
  214. POM for default case and release profile.
  215. -->
  216. <skip>${maven.javadoc.skip}</skip>
  217. <verbose>true</verbose>
  218. <filesets>
  219. <fileset>
  220. <directory>${project.build.directory}/${project.build.finalName}-sources.jar/org/aspectj</directory>
  221. <outputDirectory>${project.build.directory}/unpacked-sources/org/aspectj</outputDirectory>
  222. </fileset>
  223. <fileset>
  224. <directory>${project.build.directory}/${project.build.finalName}-sources.jar/aj</directory>
  225. <outputDirectory>${project.build.directory}/unpacked-sources/aj</outputDirectory>
  226. </fileset>
  227. </filesets>
  228. </configuration>
  229. </execution>
  230. </executions>
  231. </plugin>
  232. <plugin>
  233. <groupId>org.apache.maven.plugins</groupId>
  234. <artifactId>maven-javadoc-plugin</artifactId>
  235. <executions>
  236. <execution>
  237. <id>javadoc-jar</id>
  238. <phase>package</phase>
  239. <goals>
  240. <goal>jar</goal>
  241. </goals>
  242. <!--
  243. FIXME: This configuration works with JDK 16, but throws errors on other JDK versions, e.g. 14. It looks as
  244. if the Maven Javadoc plugin does not do a particularly good job applying the plugin settings in a way
  245. making it work with different JDK javadoc tool versions. I am saying that, because when using the tool
  246. directly on the console, it works with basic settings and the correct classpath.
  247. -->
  248. <configuration>
  249. <sourcepath>${project.build.directory}/unpacked-sources</sourcepath>
  250. <!-- TODO: Include 'aj' package for ASM-renamed contained in aspectjtools? -->
  251. <subpackages>org.aspectj</subpackages>
  252. <!-- Deactivate doclint checks in order to suppress errors -->
  253. <doclint>none</doclint>
  254. <!-- Generate class use xref, making javadocs considerably bigger, but also more informative -->
  255. <use>true</use>
  256. <!-- FIXME: Why does it fail without this parameter? -->
  257. <javadocVersion>8</javadocVersion>
  258. </configuration>
  259. </execution>
  260. </executions>
  261. </plugin>
  262. <!-- Caveat: Attaching the flattened POM needs packaging=jar, so do not use packaging=pom for this module -->
  263. <plugin>
  264. <groupId>org.codehaus.mojo</groupId>
  265. <artifactId>flatten-maven-plugin</artifactId>
  266. <executions>
  267. <!-- Remove dependencies declared in this POM (if any) from uber JAR and strip down POM -->
  268. <execution>
  269. <id>flatten</id>
  270. <phase>process-resources</phase>
  271. <goals>
  272. <goal>flatten</goal>
  273. </goals>
  274. <configuration>
  275. <flattenMode>oss</flattenMode>
  276. <pomElements>
  277. <dependencies>remove</dependencies>
  278. <repositories>remove</repositories>
  279. </pomElements>
  280. <outputDirectory>${project.build.directory}</outputDirectory>
  281. <flattenedPomFilename>flattened-pom.xml</flattenedPomFilename>
  282. </configuration>
  283. </execution>
  284. </executions>
  285. </plugin>
  286. <!-- Deploy this module to Nexus (Sonatype OSSRH, releases promotable to Maven Central) -->
  287. <plugin>
  288. <groupId>org.sonatype.plugins</groupId>
  289. <artifactId>nexus-staging-maven-plugin</artifactId>
  290. </plugin>
  291. </plugins>
  292. <pluginManagement>
  293. <plugins>
  294. <!--This plugin's configuration is used to store Eclipse m2e settings only. It has no influence on the Maven build itself.-->
  295. <plugin>
  296. <groupId>org.eclipse.m2e</groupId>
  297. <artifactId>lifecycle-mapping</artifactId>
  298. <version>1.0.0</version>
  299. <configuration>
  300. <lifecycleMappingMetadata>
  301. <pluginExecutions>
  302. <pluginExecution>
  303. <pluginExecutionFilter>
  304. <groupId>
  305. org.codehaus.mojo
  306. </groupId>
  307. <artifactId>
  308. flatten-maven-plugin
  309. </artifactId>
  310. <versionRange>
  311. [1.2.2,)
  312. </versionRange>
  313. <goals>
  314. <goal>flatten</goal>
  315. </goals>
  316. </pluginExecutionFilter>
  317. <action>
  318. <ignore></ignore>
  319. </action>
  320. </pluginExecution>
  321. </pluginExecutions>
  322. </lifecycleMappingMetadata>
  323. </configuration>
  324. </plugin>
  325. </plugins>
  326. </pluginManagement>
  327. </build>
  328. <dependencies>
  329. <dependency>
  330. <groupId>org.aspectj</groupId>
  331. <artifactId>org.eclipse.jdt.core</artifactId>
  332. </dependency>
  333. <dependency>
  334. <groupId>org.ow2.asm</groupId>
  335. <artifactId>asm</artifactId>
  336. </dependency>
  337. <dependency>
  338. <groupId>org.aspectj</groupId>
  339. <artifactId>runtime</artifactId>
  340. <version>${project.version}</version>
  341. </dependency>
  342. <dependency>
  343. <groupId>org.aspectj</groupId>
  344. <artifactId>weaver</artifactId>
  345. <version>${project.version}</version>
  346. </dependency>
  347. <dependency>
  348. <groupId>org.aspectj</groupId>
  349. <artifactId>util</artifactId>
  350. <version>${project.version}</version>
  351. </dependency>
  352. <dependency>
  353. <groupId>org.aspectj</groupId>
  354. <artifactId>bridge</artifactId>
  355. <version>${project.version}</version>
  356. </dependency>
  357. <dependency>
  358. <groupId>org.aspectj</groupId>
  359. <artifactId>asm</artifactId>
  360. <version>${project.version}</version>
  361. </dependency>
  362. <dependency>
  363. <groupId>org.aspectj</groupId>
  364. <artifactId>org.aspectj.matcher</artifactId>
  365. <version>${project.version}</version>
  366. </dependency>
  367. <dependency>
  368. <groupId>org.aspectj</groupId>
  369. <artifactId>bcel-builder</artifactId>
  370. <version>${project.version}</version>
  371. </dependency>
  372. <dependency>
  373. <groupId>org.aspectj</groupId>
  374. <artifactId>loadtime</artifactId>
  375. <version>${project.version}</version>
  376. </dependency>
  377. <dependency>
  378. <groupId>org.aspectj</groupId>
  379. <artifactId>ajde</artifactId>
  380. <version>${project.version}</version>
  381. </dependency>
  382. <dependency>
  383. <groupId>org.aspectj</groupId>
  384. <artifactId>ajde.core</artifactId>
  385. <version>${project.version}</version>
  386. </dependency>
  387. <dependency>
  388. <groupId>org.aspectj</groupId>
  389. <artifactId>ajdoc</artifactId>
  390. <version>${project.version}</version>
  391. </dependency>
  392. <dependency>
  393. <groupId>org.aspectj</groupId>
  394. <artifactId>org.aspectj.ajdt.core</artifactId>
  395. <version>${project.version}</version>
  396. </dependency>
  397. <dependency>
  398. <groupId>org.aspectj</groupId>
  399. <artifactId>taskdefs</artifactId>
  400. <version>${project.version}</version>
  401. </dependency>
  402. </dependencies>
  403. </project>