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

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