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

Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Recreate lib/commons from Apache Commons downloads Project archeology, binary and source code comparisons of contents in lib/commons/commons.jar and lib/commons/commons-src.zip yielded the following results: - All binaries are available on Maven Central in 4 different legacy Apache Commons dependencies: * commons-beanutils:commons-beanutils:1.4 * commons-collections:commons-collections:2.0 * commons-digester:commons-digester:1.3 * commons-logging:commons-logging:1.0.1 - Those Maven Central binaries are not accompanied by source JARs, i.e. in order to recreate lib/commons/commons-src.zip we have to download source archives from the corresponding Git tags. All projects are available on GitHub, so it is possible to download them using Maven Download Plugin. - Both the compound binaries and compound sources archives currently checked in in AspectJ can be recreated using TrueZIP Maven Plugin. This is rather tedious and involves additional Maven profiles in order not to generate the compound archives during every build, but fully implemented now. Unfortunately, all of the above does not make the system-scoped dependency on commons.jar obsolete. In order to achieve that, we either have to publish the compound files on Maven Central or GitHub Packages, or we find out which AspectJ modules use classes from which of the 4 individual Apache Commons packages and replace the compound system dependency by the relevant single dependencies. Probably I am going to try that in a next step. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602
  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. <!-- The AspectJ root POM is the parent, but this module is not a submodule -->
  6. <parent>
  7. <groupId>org.aspectj</groupId>
  8. <artifactId>aspectj-parent</artifactId>
  9. <version>1.9.7.BUILD-SNAPSHOT</version>
  10. </parent>
  11. <artifactId>libx</artifactId>
  12. <name>AspectJ Test Libraries</name>
  13. <description>
  14. This module downloads + installs libraries used by many tests, especially those running as Ant jobs. You should not
  15. build this module during every build because it is somewhat slow, downloading stuff from 3rd-party websites,
  16. unzipping some libraries (e.g. a full Ant distribution) and creating new ZIP files (e.g. source JARs, compound JARs
  17. containing multiple libraries).
  18. So just run 'mvn compile' once after cloning the AspectJ repository and you should be all set to subsequently build
  19. AspectJ itself. If you forget this step, a Maven Enforcer rule in the AspectJ root POM will fail the build and
  20. remind you to build this module.
  21. Normally you never have to call 'mvn clean' here, but if for some reason the installed libraries are in an
  22. inconsistent state (e.g. after an incomplete download), you can do so and then run 'mvn compile' again.
  23. BTW, running 'mvn compile' multiple times will not repeat any download via Maven Dependency or Download Maven
  24. plugins, but repeat all zip/unzip steps in TrueZIP Maven plugin. So try not to call it unnecessarily.
  25. </description>
  26. <!-- TODO: Add libx (for now, then finally lib) to .gitignore -->
  27. <properties>
  28. <lib.ant.name>apache-ant</lib.ant.name>
  29. <lib.ant.artifact>${lib.ant.name}-${lib.ant.version}</lib.ant.artifact>
  30. </properties>
  31. <build>
  32. <plugins>
  33. <plugin>
  34. <groupId>org.apache.maven.plugins</groupId>
  35. <artifactId>maven-enforcer-plugin</artifactId>
  36. <executions>
  37. <execution>
  38. <!--
  39. Deactivate this execution from the parent, because here it would be counter-productive, given the fact
  40. that this module must be built before the enforcer rule can even pass elsewhere.
  41. -->
  42. <id>enforce-libraries-exist</id>
  43. <phase>none</phase>
  44. </execution>
  45. </executions>
  46. </plugin>
  47. <plugin>
  48. <groupId>com.googlecode.maven-download-plugin</groupId>
  49. <artifactId>download-maven-plugin</artifactId>
  50. <version>1.6.1</version>
  51. <executions>
  52. <execution>
  53. <id>download-ant-binaries</id>
  54. <phase>generate-resources</phase>
  55. <goals>
  56. <goal>wget</goal>
  57. </goals>
  58. <configuration>
  59. <url>https://archive.apache.org/dist/ant/binaries/${lib.ant.artifact}-bin.zip</url>
  60. <outputDirectory>ant</outputDirectory>
  61. <sha1>3fa9f816a0c4c63249efad8e6225f2e83794f0c0</sha1>
  62. </configuration>
  63. </execution>
  64. <execution>
  65. <id>download-ant-sources</id>
  66. <phase>generate-resources</phase>
  67. <goals>
  68. <goal>wget</goal>
  69. </goals>
  70. <configuration>
  71. <url>https://archive.apache.org/dist/ant/source/${lib.ant.artifact}-src.zip</url>
  72. <outputDirectory>ant</outputDirectory>
  73. <sha1>b9f3c8c31bb6c9069ad5b655059a17769af12f20</sha1>
  74. </configuration>
  75. </execution>
  76. <execution>
  77. <id>download-beanutils-sources</id>
  78. <phase>generate-resources</phase>
  79. <goals>
  80. <goal>wget</goal>
  81. </goals>
  82. <configuration>
  83. <url>https://github.com/apache/commons-beanutils/archive/refs/tags/${lib.commons.beanutils.tag}.zip</url>
  84. <outputDirectory>commons</outputDirectory>
  85. <outputFileName>commons-beanutils-${lib.commons.beanutils.version}-sources.jar</outputFileName>
  86. <sha1>b2c02afe7e6475cd7c811932b8415d171a8afa00</sha1>
  87. </configuration>
  88. </execution>
  89. <execution>
  90. <id>download-collections-sources</id>
  91. <phase>generate-resources</phase>
  92. <goals>
  93. <goal>wget</goal>
  94. </goals>
  95. <configuration>
  96. <url>https://github.com/apache/commons-collections/archive/refs/tags/${lib.commons.collections.tag}.zip</url>
  97. <outputDirectory>commons</outputDirectory>
  98. <outputFileName>commons-collections-${lib.commons.collections.version}-sources.jar</outputFileName>
  99. <sha1>824cacd0aafe21a94fb142388fd62f28a12df5ef</sha1>
  100. </configuration>
  101. </execution>
  102. <execution>
  103. <id>download-digester-sources</id>
  104. <phase>generate-resources</phase>
  105. <goals>
  106. <goal>wget</goal>
  107. </goals>
  108. <configuration>
  109. <url>https://github.com/apache/commons-digester/archive/refs/tags/${lib.commons.digester.tag}.zip</url>
  110. <outputDirectory>commons</outputDirectory>
  111. <outputFileName>commons-digester-${lib.commons.digester.version}-sources.jar</outputFileName>
  112. <sha1>49f653c7ea726301c564f9662b72c051fee9390a</sha1>
  113. </configuration>
  114. </execution>
  115. <execution>
  116. <id>download-logging-sources</id>
  117. <phase>generate-resources</phase>
  118. <goals>
  119. <goal>wget</goal>
  120. </goals>
  121. <configuration>
  122. <url>https://github.com/apache/commons-logging/archive/refs/tags/${lib.commons.logging.tag}.zip</url>
  123. <outputDirectory>commons</outputDirectory>
  124. <outputFileName>commons-logging-${lib.commons.logging.version}-sources.jar</outputFileName>
  125. <sha1>c61a373f6d50ff8fcfba900934f7254d44f9735b</sha1>
  126. </configuration>
  127. </execution>
  128. </executions>
  129. </plugin>
  130. <plugin>
  131. <groupId>org.apache.maven.plugins</groupId>
  132. <artifactId>maven-dependency-plugin</artifactId>
  133. <version>3.1.2</version>
  134. <executions>
  135. <execution>
  136. <id>copy</id>
  137. <phase>generate-resources</phase>
  138. <goals>
  139. <goal>copy</goal>
  140. </goals>
  141. <configuration>
  142. <artifactItems>
  143. <artifactItem>
  144. <!-- Available from GitHub Packages (needs special repository declaration) -->
  145. <groupId>org.aspectj</groupId>
  146. <artifactId>org.eclipse.jdt.core</artifactId>
  147. <version>${jdt.core.version}</version>
  148. <type>jar</type>
  149. <overWrite>false</overWrite>
  150. <outputDirectory>jdtcore-aj</outputDirectory>
  151. <destFileName>jdtcore-for-aspectj.jar</destFileName>
  152. </artifactItem>
  153. <artifactItem>
  154. <!-- Available from GitHub Packages (needs special repository declaration) -->
  155. <groupId>org.aspectj</groupId>
  156. <artifactId>org.eclipse.jdt.core</artifactId>
  157. <version>${jdt.core.version}</version>
  158. <type>java-source</type>
  159. <classifier>sources</classifier>
  160. <overWrite>false</overWrite>
  161. <outputDirectory>jdtcore-aj</outputDirectory>
  162. <destFileName>jdtcore-for-aspectj-src.zip</destFileName>
  163. </artifactItem>
  164. <artifactItem>
  165. <!-- Available from GitHub Packages (needs special repository declaration) -->
  166. <groupId>org.aspectj</groupId>
  167. <artifactId>asm-renamed</artifactId>
  168. <version>${asm.version}</version>
  169. <type>jar</type>
  170. <overWrite>false</overWrite>
  171. <outputDirectory>asm</outputDirectory>
  172. <destFileName>asm-${asm.version}.renamed.jar</destFileName>
  173. </artifactItem>
  174. <artifactItem>
  175. <!-- Available from GitHub Packages (needs special repository declaration) -->
  176. <groupId>org.aspectj</groupId>
  177. <artifactId>asm-renamed</artifactId>
  178. <version>${asm.version}</version>
  179. <type>java-source</type>
  180. <classifier>sources</classifier>
  181. <overWrite>false</overWrite>
  182. <outputDirectory>asm</outputDirectory>
  183. <destFileName>asm-${asm.version}.renamed-src.zip</destFileName>
  184. </artifactItem>
  185. <!--
  186. How relevant is JRockit in 2021?
  187. https://en.wikipedia.org/wiki/JRockit
  188. https://www.oracle.com/java/jrockit.html
  189. There are only org.aspectj.weaver.loadtime.JRockitAgent + tests. If we would get rid of that class,
  190. all the rest and jrockit.jar could also go away.
  191. -->
  192. <artifactItem>
  193. <!-- Binary is identical to committed version in branch 'jdtcore-new' -->
  194. <groupId>com.googlecode.jarjar</groupId>
  195. <artifactId>jarjar</artifactId>
  196. <version>1.3</version>
  197. <type>jar</type>
  198. <overWrite>false</overWrite>
  199. <outputDirectory>jarjar</outputDirectory>
  200. <destFileName>jarjar-1.3.jar</destFileName>
  201. </artifactItem>
  202. <artifactItem>
  203. <!--
  204. Binary jdiff:jdiff:1.0.9 is available on Maven Central, but different from committed version.
  205. There are API changes, some classes referenced in org.aspectj.testing.util.TestUtil are unavailable.
  206. Therefore, we would have to try and port the existing functionality, making sure the tests still
  207. run.
  208. Downloading snapshot from
  209. https://sourceforge.net/p/jedit/svn/24818/tree/plugins/JDiffPlugin/tags/jdiffplugin-1_2_2/jdiff/
  210. produces exactly identical source files as in the committed JAR. But there is no corresponding Maven
  211. artifact or even binary download package. We would have to compile the code within AspectJ and
  212. deploy it locally or Sonatype (Maven Central) or maven.springframework.org.
  213. Downloading source or binary packages from
  214. https://sourceforge.net/projects/jedit-plugins/files/JDiffPlugin/1.3/
  215. also has identical source files (except for tiny copyright changes), but contains more classes
  216. (a superset of the committed ones). Again, there is no Maven artifact for it.
  217. Another option would be to include the only 4 Java classes into the 'testing-util' source tree. They
  218. are only used from there and could easily be compiled together with the module, package names
  219. relocated or not.
  220. -->
  221. <groupId>jdiff</groupId>
  222. <artifactId>jdiff</artifactId>
  223. <version>1.0.9</version>
  224. <type>jar</type>
  225. <overWrite>false</overWrite>
  226. <outputDirectory>jdiff</outputDirectory>
  227. <destFileName>jdiff.jar</destFileName>
  228. </artifactItem>
  229. <artifactItem>
  230. <!-- Binary is identical to committed version -->
  231. <groupId>junit</groupId>
  232. <artifactId>junit</artifactId>
  233. <version>3.8.1</version>
  234. <type>jar</type>
  235. <overWrite>false</overWrite>
  236. <outputDirectory>junit</outputDirectory>
  237. <destFileName>junit.jar</destFileName>
  238. </artifactItem>
  239. <artifactItem>
  240. <!-- Binary is identical to committed version -->
  241. <!-- TODO: Is this redundant JUnit JAR in ant/lib really necessary? If so, why? -->
  242. <groupId>junit</groupId>
  243. <artifactId>junit</artifactId>
  244. <version>3.8.1</version>
  245. <type>jar</type>
  246. <overWrite>false</overWrite>
  247. <outputDirectory>ant/lib</outputDirectory>
  248. <destFileName>junit.jar</destFileName>
  249. </artifactItem>
  250. <artifactItem>
  251. <!-- Binary is identical to committed version -->
  252. <groupId>junit</groupId>
  253. <artifactId>junit</artifactId>
  254. <version>3.8.1</version>
  255. <type>jar</type>
  256. <classifier>sources</classifier>
  257. <overWrite>false</overWrite>
  258. <outputDirectory>junit</outputDirectory>
  259. <destFileName>junit-src.zip</destFileName>
  260. </artifactItem>
  261. <!-- Jython does not seem to be used anywhere in AspectJ -->
  262. <artifactItem>
  263. <!-- Binary is a bit newer than committed version, but produces identical results in 'docs' -->
  264. <groupId>saxon</groupId>
  265. <artifactId>saxon</artifactId>
  266. <version>6.5.3</version>
  267. <type>jar</type>
  268. <overWrite>false</overWrite>
  269. <outputDirectory>saxon</outputDirectory>
  270. <destFileName>saxon.jar</destFileName>
  271. </artifactItem>
  272. <artifactItem>
  273. <!-- Binary is identical to committed version -->
  274. <groupId>regexp</groupId>
  275. <artifactId>regexp</artifactId>
  276. <version>${lib.regexp.version}</version>
  277. <type>jar</type>
  278. <overWrite>false</overWrite>
  279. <outputDirectory>regexp</outputDirectory>
  280. <destFileName>jakarta-regexp-1.2.jar</destFileName>
  281. </artifactItem>
  282. <!--
  283. About commons.jar + commons-src.zip:
  284. - Beanutils Binaries are commons-beanutils:commons-beanutils:1.4 (no sources on Maven Central, but
  285. https://github.com/apache/commons-beanutils/archive/refs/tags/BEANUTILS_1_4.zip)
  286. - Collections: Binaries are commons-collections:commons-collections:2.0 (no sources on Maven Central, but
  287. https://github.com/apache/commons-collections/archive/refs/tags/collections-2.0.zip)
  288. - Digester: Binaries are commons-digester:commons-digester:1.3 (no sources on Maven Central, but
  289. https://github.com/apache/commons-digester/archive/refs/tags/DIGESTER_1_3.zip)
  290. - Logging: Binaries are commons-logging:commons-logging:1.0.1 (no sources on Maven Central, but
  291. https://github.com/apache/commons-logging/archive/refs/tags/LOGGING_1_0_1.zip)
  292. -->
  293. <artifactItem>
  294. <!-- Binary is identical to committed version -->
  295. <!-- TODO: not used anywhere -> remove -->
  296. <groupId>commons-beanutils</groupId>
  297. <artifactId>commons-beanutils</artifactId>
  298. <version>${lib.commons.beanutils.version}</version>
  299. <type>jar</type>
  300. <overWrite>false</overWrite>
  301. <outputDirectory>commons</outputDirectory>
  302. <destFileName>commons-beanutils-${lib.commons.beanutils.version}.jar</destFileName>
  303. </artifactItem>
  304. <artifactItem>
  305. <!-- Binary is identical to committed version -->
  306. <!-- TODO: not used anywhere -> remove -->
  307. <groupId>commons-collections</groupId>
  308. <artifactId>commons-collections</artifactId>
  309. <version>2.0</version>
  310. <type>jar</type>
  311. <overWrite>false</overWrite>
  312. <outputDirectory>commons</outputDirectory>
  313. <destFileName>commons-collections-2.0.jar</destFileName>
  314. </artifactItem>
  315. <artifactItem>
  316. <!-- Binary is identical to committed version -->
  317. <!-- TODO: used in module 'testing' -->
  318. <groupId>commons-digester</groupId>
  319. <artifactId>commons-digester</artifactId>
  320. <version>${lib.commons.digester.version}</version>
  321. <type>jar</type>
  322. <overWrite>false</overWrite>
  323. <outputDirectory>commons</outputDirectory>
  324. <destFileName>commons-digester-${lib.commons.digester.version}.jar</destFileName>
  325. </artifactItem>
  326. <artifactItem>
  327. <!-- Binary is identical to committed version -->
  328. <!-- TODO: used in modules 'org.aspectj.matcher' -->
  329. <groupId>commons-logging</groupId>
  330. <artifactId>commons-logging</artifactId>
  331. <version>${lib.commons.logging.version}</version>
  332. <type>jar</type>
  333. <overWrite>false</overWrite>
  334. <outputDirectory>commons</outputDirectory>
  335. <destFileName>commons-logging-${lib.commons.logging.version}.jar</destFileName>
  336. </artifactItem>
  337. </artifactItems>
  338. </configuration>
  339. </execution>
  340. </executions>
  341. </plugin>
  342. <plugin>
  343. <groupId>org.codehaus.mojo</groupId>
  344. <artifactId>truezip-maven-plugin</artifactId>
  345. <version>1.2</version>
  346. <executions>
  347. <execution>
  348. <id>unzip-ant-binaries</id>
  349. <phase>process-resources</phase>
  350. <goals>
  351. <goal>copy</goal>
  352. </goals>
  353. <configuration>
  354. <verbose>true</verbose>
  355. <fileset>
  356. <!--
  357. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  358. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  359. -->
  360. <directory>ant/${lib.ant.artifact}-bin.zip/${lib.ant.artifact}</directory>
  361. <outputDirectory>ant</outputDirectory>
  362. </fileset>
  363. </configuration>
  364. </execution>
  365. <execution>
  366. <id>zip-ant-sources</id>
  367. <phase>process-resources</phase>
  368. <goals>
  369. <goal>copy</goal>
  370. </goals>
  371. <configuration>
  372. <verbose>true</verbose>
  373. <fileset>
  374. <!--
  375. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  376. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  377. -->
  378. <directory>ant/${lib.ant.artifact}-src.zip/${lib.ant.artifact}/src/main</directory>
  379. <outputDirectory>ant/ant-src.zip</outputDirectory>
  380. </fileset>
  381. </configuration>
  382. </execution>
  383. <execution>
  384. <id>zip-beanutils-binaries</id>
  385. <phase>process-resources</phase>
  386. <goals>
  387. <goal>copy</goal>
  388. </goals>
  389. <configuration>
  390. <verbose>true</verbose>
  391. <fileset>
  392. <!--
  393. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  394. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  395. -->
  396. <directory>commons/commons-beanutils-${lib.commons.beanutils.version}.jar</directory>
  397. <outputDirectory>commons/commons.jar</outputDirectory>
  398. </fileset>
  399. </configuration>
  400. </execution>
  401. <execution>
  402. <id>zip-collections-binaries</id>
  403. <phase>process-resources</phase>
  404. <goals>
  405. <goal>copy</goal>
  406. </goals>
  407. <configuration>
  408. <verbose>true</verbose>
  409. <fileset>
  410. <!--
  411. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  412. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  413. -->
  414. <directory>commons/commons-collections-${lib.commons.collections.version}.jar</directory>
  415. <outputDirectory>commons/commons.jar</outputDirectory>
  416. </fileset>
  417. </configuration>
  418. </execution>
  419. <execution>
  420. <id>zip-digester-binaries</id>
  421. <phase>process-resources</phase>
  422. <goals>
  423. <goal>copy</goal>
  424. </goals>
  425. <configuration>
  426. <verbose>true</verbose>
  427. <fileset>
  428. <!--
  429. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  430. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  431. -->
  432. <directory>commons/commons-digester-${lib.commons.digester.version}.jar</directory>
  433. <outputDirectory>commons/commons.jar</outputDirectory>
  434. </fileset>
  435. </configuration>
  436. </execution>
  437. <execution>
  438. <id>zip-logging-binaries</id>
  439. <phase>process-resources</phase>
  440. <goals>
  441. <goal>copy</goal>
  442. </goals>
  443. <configuration>
  444. <verbose>true</verbose>
  445. <fileset>
  446. <!--
  447. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  448. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  449. -->
  450. <directory>commons/commons-logging-${lib.commons.logging.version}.jar</directory>
  451. <outputDirectory>commons/commons.jar</outputDirectory>
  452. </fileset>
  453. </configuration>
  454. </execution>
  455. <execution>
  456. <id>zip-beanutils-sources</id>
  457. <phase>process-resources</phase>
  458. <goals>
  459. <goal>copy</goal>
  460. </goals>
  461. <configuration>
  462. <verbose>true</verbose>
  463. <fileset>
  464. <!--
  465. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  466. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  467. -->
  468. <directory>commons/commons-beanutils-${lib.commons.beanutils.version}-sources.jar/commons-beanutils-${lib.commons.beanutils.tag}/src/java</directory>
  469. <outputDirectory>commons/commons-src.zip</outputDirectory>
  470. </fileset>
  471. </configuration>
  472. </execution>
  473. <execution>
  474. <id>zip-collections-sources</id>
  475. <phase>process-resources</phase>
  476. <goals>
  477. <goal>copy</goal>
  478. </goals>
  479. <configuration>
  480. <verbose>true</verbose>
  481. <fileset>
  482. <!--
  483. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  484. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  485. -->
  486. <directory>commons/commons-collections-${lib.commons.collections.version}-sources.jar/commons-collections-${lib.commons.collections.tag}/src/java</directory>
  487. <outputDirectory>commons/commons-src.zip</outputDirectory>
  488. </fileset>
  489. </configuration>
  490. </execution>
  491. <execution>
  492. <id>zip-digester-sources</id>
  493. <phase>process-resources</phase>
  494. <goals>
  495. <goal>copy</goal>
  496. </goals>
  497. <configuration>
  498. <verbose>true</verbose>
  499. <fileset>
  500. <!--
  501. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  502. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  503. -->
  504. <directory>commons/commons-digester-${lib.commons.digester.version}-sources.jar/commons-digester-${lib.commons.digester.tag}/src/java</directory>
  505. <outputDirectory>commons/commons-src.zip</outputDirectory>
  506. </fileset>
  507. </configuration>
  508. </execution>
  509. <execution>
  510. <id>zip-logging-sources</id>
  511. <phase>process-resources</phase>
  512. <goals>
  513. <goal>copy</goal>
  514. </goals>
  515. <configuration>
  516. <verbose>true</verbose>
  517. <fileset>
  518. <!--
  519. This is why we use the TrueZIP plugin: It can seamlessly copy out of or into ZIP files as if they
  520. were normal file system paths. No additional moves and deletes with Antrun are necessary.
  521. -->
  522. <directory>commons/commons-logging-${lib.commons.logging.version}-sources.jar/commons-logging-${lib.commons.logging.tag}/src/java</directory>
  523. <outputDirectory>commons/commons-src.zip</outputDirectory>
  524. </fileset>
  525. </configuration>
  526. </execution>
  527. </executions>
  528. </plugin>
  529. <plugin>
  530. <groupId>org.apache.maven.plugins</groupId>
  531. <artifactId>maven-clean-plugin</artifactId>
  532. <executions>
  533. <execution>
  534. <id>clean-up-libs</id>
  535. <phase>clean</phase>
  536. <goals>
  537. <goal>clean</goal>
  538. </goals>
  539. <configuration>
  540. <filesets>
  541. <fileset>
  542. <directory>.</directory>
  543. <includes>
  544. <include>ant/**</include>
  545. <include>asm/**</include>
  546. <include>commons/**</include>
  547. <include>jarjar/**</include>
  548. <include>jdiff/**</include>
  549. <include>jdtcore-aj/**</include>
  550. <include>junit/**</include>
  551. <include>regexp/**</include>
  552. <include>saxon/**</include>
  553. </includes>
  554. <followSymlinks>false</followSymlinks>
  555. </fileset>
  556. </filesets>
  557. </configuration>
  558. </execution>
  559. </executions>
  560. </plugin>
  561. </plugins>
  562. </build>
  563. <dependencies>
  564. <dependency>
  565. <groupId>org.aspectj</groupId>
  566. <artifactId>asm-renamed</artifactId>
  567. </dependency>
  568. <dependency>
  569. <groupId>org.aspectj</groupId>
  570. <artifactId>org.eclipse.jdt.core</artifactId>
  571. </dependency>
  572. </dependencies>
  573. </project>