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.

aspectjtools-assembly.xml 3.2KB

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 anni fa
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 anni fa
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 anni fa
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 anni fa
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 anni fa
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 anni fa
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 anni fa
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 anni fa
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124
  1. <assembly xmlns="http://maven.apache.org/ASSEMBLY/2.1.0"
  2. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  3. xsi:schemaLocation="http://maven.apache.org/ASSEMBLY/2.1.0 http://maven.apache.org/xsd/assembly-2.1.0.xsd">
  4. <id>aspectjtools</id>
  5. <formats>
  6. <format>jar</format>
  7. </formats>
  8. <includeBaseDirectory>false</includeBaseDirectory>
  9. <dependencySets>
  10. <dependencySet>
  11. <unpack>true</unpack>
  12. <!-- Avoid warning when trying to add non-existing main artifact JAR -->
  13. <useProjectArtifact>false</useProjectArtifact>
  14. <includes>
  15. <include>org.aspectj:org.eclipse.jdt.core</include>
  16. <include>org.ow2.asm:asm</include>
  17. </includes>
  18. </dependencySet>
  19. </dependencySets>
  20. <fileSets>
  21. <!-- runtime -->
  22. <fileSet>
  23. <directory>../runtime/target/classes</directory>
  24. <outputDirectory>.</outputDirectory>
  25. <excludes>
  26. <exclude>META-INF/maven/**</exclude>
  27. </excludes>
  28. </fileSet>
  29. <!-- weaver -->
  30. <fileSet>
  31. <directory>../weaver/target/classes</directory>
  32. <outputDirectory>.</outputDirectory>
  33. <excludes>
  34. <exclude>META-INF/maven/**</exclude>
  35. </excludes>
  36. </fileSet>
  37. <fileSet>
  38. <directory>../util/target/classes</directory>
  39. <outputDirectory>.</outputDirectory>
  40. <excludes>
  41. <exclude>META-INF/maven/**</exclude>
  42. </excludes>
  43. </fileSet>
  44. <fileSet>
  45. <directory>../bridge/target/classes</directory>
  46. <outputDirectory>.</outputDirectory>
  47. <excludes>
  48. <exclude>META-INF/maven/**</exclude>
  49. </excludes>
  50. </fileSet>
  51. <fileSet>
  52. <directory>../asm/target/classes</directory>
  53. <outputDirectory>.</outputDirectory>
  54. <excludes>
  55. <exclude>META-INF/maven/**</exclude>
  56. </excludes>
  57. </fileSet>
  58. <fileSet>
  59. <directory>../org.aspectj.matcher/target/classes</directory>
  60. <outputDirectory>.</outputDirectory>
  61. <excludes>
  62. <exclude>META-INF/maven/**</exclude>
  63. </excludes>
  64. </fileSet>
  65. <fileSet>
  66. <directory>../bcel-builder/target/classes</directory>
  67. <outputDirectory>.</outputDirectory>
  68. <excludes>
  69. <exclude>META-INF/maven/**</exclude>
  70. </excludes>
  71. </fileSet>
  72. <fileSet>
  73. <directory>../loadtime/target/classes</directory>
  74. <outputDirectory>.</outputDirectory>
  75. <excludes>
  76. <exclude>META-INF/maven/**</exclude>
  77. </excludes>
  78. </fileSet>
  79. <!-- tools -->
  80. <fileSet>
  81. <directory>../ajde/target/classes</directory>
  82. <outputDirectory>.</outputDirectory>
  83. <excludes>
  84. <exclude>META-INF/maven/**</exclude>
  85. </excludes>
  86. </fileSet>
  87. <fileSet>
  88. <directory>../ajde.core/target/classes</directory>
  89. <outputDirectory>.</outputDirectory>
  90. <excludes>
  91. <exclude>META-INF/maven/**</exclude>
  92. </excludes>
  93. </fileSet>
  94. <fileSet>
  95. <directory>../ajdoc/target/classes</directory>
  96. <outputDirectory>.</outputDirectory>
  97. <excludes>
  98. <exclude>META-INF/maven/**</exclude>
  99. </excludes>
  100. </fileSet>
  101. <fileSet>
  102. <directory>../org.aspectj.ajdt.core/target/classes</directory>
  103. <outputDirectory>.</outputDirectory>
  104. <excludes>
  105. <exclude>META-INF/maven/**</exclude>
  106. </excludes>
  107. </fileSet>
  108. <fileSet>
  109. <directory>../taskdefs/target/classes</directory>
  110. <outputDirectory>.</outputDirectory>
  111. <excludes>
  112. <exclude>META-INF/maven/**</exclude>
  113. </excludes>
  114. </fileSet>
  115. </fileSets>
  116. </assembly>