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

Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
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
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
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
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
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
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
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
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
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
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
Provision libraries in 'lib' automatically Upon special request by Andy Clement, I included 'lib' as a child module in the parent POM again, making several modules which refer to downloaded library files dependent the 'lib' module. I am not sure I caught all of them, but I hope so. Now after cloning the project and configuring the token for reading from GitHub Packages (sorry!), you can just run a Maven build for the main project and no longer need to fail the first build, read the Maven Enforcer message and run 'cd lib && mvn compile' as a first step. This convenience comes at the price of a more complex POM and two new profiles: - Profile 'provision-libs' is auto-activated by the absence of a marker file, kicking off the library provisioning process and creating same marker file at the end, if successful. Therefore, during subsequent builds libraries will not be re-provisioned, because the marker file exists and Maven skips all download and (un)zip steps, which saves build time and bandwidth. Otherwise offline builds would not work either. - Profile 'clean-libs' needs to be activated manually, because by default 'mvn clean' will not erase provisioned libraries. In most cases, even after a clean a developer does not want to re-provision all libraries if they have not changed (e.g. new JDT Core build). But if you do wish too erase the libraries and the marker file, just call 'cd lib && mvn -P clean-libs clean'. Please note: The Maven Enforcer build step, which additionally checks for existence of other files, still exists and was moved from the parent POM to 'libs'. No matter if provisioning was just done or skipped because the main marker file exists, a quick heuristic check for that list of files is done during each build, failing the build with a comprehensive message if an inconsistency was found. The error message says which files are missing and tells the user: "There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be." This should cover the topic. Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
3 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751
  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>lib</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 lib (for now, then finally lib) to .gitignore -->
  27. <properties>
  28. <lib.provisioned.marker>provisioned.marker</lib.provisioned.marker>
  29. <lib.ant.name>apache-ant</lib.ant.name>
  30. <lib.ant.artifact>${lib.ant.name}-${lib.ant.version}</lib.ant.artifact>
  31. </properties>
  32. <profiles>
  33. <!-- Profile for provisioning - i.e. downloading and (un)zipping - libraries needed during the build -->
  34. <profile>
  35. <id>provision-libs</id>
  36. <!-- If marker file is missing, activate profile and provision all libraries -->
  37. <activation>
  38. <file>
  39. <missing>${lib.provisioned.marker}</missing>
  40. </file>
  41. </activation>
  42. <build>
  43. <plugins>
  44. <!-- Download libraries + source code which are unavailable in Maven repositories like Maven Central -->
  45. <plugin>
  46. <groupId>com.googlecode.maven-download-plugin</groupId>
  47. <artifactId>download-maven-plugin</artifactId>
  48. <version>1.6.1</version>
  49. <executions>
  50. <execution>
  51. <id>download-ant-binaries</id>
  52. <phase>generate-resources</phase>
  53. <goals>
  54. <goal>wget</goal>
  55. </goals>
  56. <configuration>
  57. <url>https://archive.apache.org/dist/ant/binaries/${lib.ant.artifact}-bin.zip</url>
  58. <outputDirectory>ant</outputDirectory>
  59. <sha1>3fa9f816a0c4c63249efad8e6225f2e83794f0c0</sha1>
  60. </configuration>
  61. </execution>
  62. <execution>
  63. <id>download-ant-sources</id>
  64. <phase>generate-resources</phase>
  65. <goals>
  66. <goal>wget</goal>
  67. </goals>
  68. <configuration>
  69. <url>https://archive.apache.org/dist/ant/source/${lib.ant.artifact}-src.zip</url>
  70. <outputDirectory>ant</outputDirectory>
  71. <sha1>b9f3c8c31bb6c9069ad5b655059a17769af12f20</sha1>
  72. </configuration>
  73. </execution>
  74. <execution>
  75. <id>download-beanutils-sources</id>
  76. <phase>generate-resources</phase>
  77. <goals>
  78. <goal>wget</goal>
  79. </goals>
  80. <configuration>
  81. <url>https://github.com/apache/commons-beanutils/archive/refs/tags/${lib.commons.beanutils.tag}.zip</url>
  82. <outputDirectory>commons</outputDirectory>
  83. <outputFileName>commons-beanutils-${lib.commons.beanutils.version}-sources.jar</outputFileName>
  84. <sha1>b2c02afe7e6475cd7c811932b8415d171a8afa00</sha1>
  85. </configuration>
  86. </execution>
  87. <execution>
  88. <id>download-collections-sources</id>
  89. <phase>generate-resources</phase>
  90. <goals>
  91. <goal>wget</goal>
  92. </goals>
  93. <configuration>
  94. <url>https://github.com/apache/commons-collections/archive/refs/tags/${lib.commons.collections.tag}.zip</url>
  95. <outputDirectory>commons</outputDirectory>
  96. <outputFileName>commons-collections-${lib.commons.collections.version}-sources.jar</outputFileName>
  97. <sha1>824cacd0aafe21a94fb142388fd62f28a12df5ef</sha1>
  98. </configuration>
  99. </execution>
  100. <execution>
  101. <id>download-digester-sources</id>
  102. <phase>generate-resources</phase>
  103. <goals>
  104. <goal>wget</goal>
  105. </goals>
  106. <configuration>
  107. <url>https://github.com/apache/commons-digester/archive/refs/tags/${lib.commons.digester.tag}.zip</url>
  108. <outputDirectory>commons</outputDirectory>
  109. <outputFileName>commons-digester-${lib.commons.digester.version}-sources.jar</outputFileName>
  110. <sha1>49f653c7ea726301c564f9662b72c051fee9390a</sha1>
  111. </configuration>
  112. </execution>
  113. <execution>
  114. <id>download-logging-sources</id>
  115. <phase>generate-resources</phase>
  116. <goals>
  117. <goal>wget</goal>
  118. </goals>
  119. <configuration>
  120. <url>https://github.com/apache/commons-logging/archive/refs/tags/${lib.commons.logging.tag}.zip</url>
  121. <outputDirectory>commons</outputDirectory>
  122. <outputFileName>commons-logging-${lib.commons.logging.version}-sources.jar</outputFileName>
  123. <sha1>c61a373f6d50ff8fcfba900934f7254d44f9735b</sha1>
  124. </configuration>
  125. </execution>
  126. <execution>
  127. <id>download-docbook-dtd</id>
  128. <phase>generate-resources</phase>
  129. <goals>
  130. <goal>wget</goal>
  131. </goals>
  132. <configuration>
  133. <url>https://www.oasis-open.org/docbook/xml/4.1.2/docbkx412.zip</url>
  134. <outputDirectory>docbook</outputDirectory>
  135. <outputFileName>docbkx412.zip</outputFileName>
  136. <sha1>b9ae7a41056bfaf885581812d60651b7b5531519</sha1>
  137. </configuration>
  138. </execution>
  139. <execution>
  140. <id>download-docbook-xsl</id>
  141. <phase>generate-resources</phase>
  142. <goals>
  143. <goal>wget</goal>
  144. </goals>
  145. <configuration>
  146. <url>https://sourceforge.net/projects/docbook/files/OldFiles/docbook-xsl-1.44.zip/download</url>
  147. <outputDirectory>docbook</outputDirectory>
  148. <outputFileName>docbook-xsl-1.44.zip</outputFileName>
  149. <sha1>626e7bee806ea14812f6f95cc2d187ab6ba9114a</sha1>
  150. </configuration>
  151. </execution>
  152. <!--
  153. Obsolete because we uploaded both binary and source JARs to GitHub Packages, so we can use JDiff as a
  154. normal dependency. Keep this for reference, so we can remember where we found it.
  155. -->
  156. <!--
  157. <execution>
  158. <id>download-jdiff</id>
  159. <phase>generate-resources</phase>
  160. <goals>
  161. <goal>wget</goal>
  162. </goals>
  163. <configuration>
  164. <url>https://downloads.sourceforge.net/project/jedit-plugins/JDiffPlugin/1.3/JDiffPlugin-1.3.zip</url>
  165. <outputDirectory>jdiff</outputDirectory>
  166. <outputFileName>JDiffPlugin-1.3.zip</outputFileName>
  167. <sha1>eba63fd845203c6b245fbcb81c0de8e2c83d16c7</sha1>
  168. </configuration>
  169. </execution>
  170. -->
  171. </executions>
  172. </plugin>
  173. <!-- Download libraries + source code which are available in Maven repositories like Maven Central -->
  174. <plugin>
  175. <groupId>org.apache.maven.plugins</groupId>
  176. <artifactId>maven-dependency-plugin</artifactId>
  177. <version>3.1.2</version>
  178. <executions>
  179. <execution>
  180. <id>copy</id>
  181. <phase>generate-resources</phase>
  182. <goals>
  183. <goal>copy</goal>
  184. </goals>
  185. <configuration>
  186. <artifactItems>
  187. <artifactItem>
  188. <!-- Available from GitHub Packages (needs special repository declaration) -->
  189. <groupId>org.aspectj</groupId>
  190. <artifactId>org.eclipse.jdt.core</artifactId>
  191. <version>${jdt.core.version}</version>
  192. <type>jar</type>
  193. <overWrite>false</overWrite>
  194. <outputDirectory>jdtcore-aj</outputDirectory>
  195. <destFileName>jdtcore-for-aspectj.jar</destFileName>
  196. </artifactItem>
  197. <artifactItem>
  198. <!-- Available from GitHub Packages (needs special repository declaration) -->
  199. <groupId>org.aspectj</groupId>
  200. <artifactId>org.eclipse.jdt.core</artifactId>
  201. <version>${jdt.core.version}</version>
  202. <type>java-source</type>
  203. <classifier>sources</classifier>
  204. <overWrite>false</overWrite>
  205. <outputDirectory>jdtcore-aj</outputDirectory>
  206. <destFileName>jdtcore-for-aspectj-src.zip</destFileName>
  207. </artifactItem>
  208. <artifactItem>
  209. <!-- Binary is identical to committed version in branch 'jdtcore-new' -->
  210. <groupId>com.googlecode.jarjar</groupId>
  211. <artifactId>jarjar</artifactId>
  212. <version>1.3</version>
  213. <type>jar</type>
  214. <overWrite>false</overWrite>
  215. <outputDirectory>jarjar</outputDirectory>
  216. <destFileName>jarjar-1.3.jar</destFileName>
  217. </artifactItem>
  218. <artifactItem>
  219. <!-- Binary is identical to committed version -->
  220. <groupId>junit</groupId>
  221. <artifactId>junit</artifactId>
  222. <version>3.8.1</version>
  223. <type>jar</type>
  224. <overWrite>false</overWrite>
  225. <outputDirectory>junit</outputDirectory>
  226. <destFileName>junit.jar</destFileName>
  227. </artifactItem>
  228. <artifactItem>
  229. <!-- Binary is identical to committed version -->
  230. <!-- TODO: Is this redundant JUnit JAR in ant/lib really necessary? If so, why? -->
  231. <groupId>junit</groupId>
  232. <artifactId>junit</artifactId>
  233. <version>3.8.1</version>
  234. <type>jar</type>
  235. <overWrite>false</overWrite>
  236. <outputDirectory>ant/lib</outputDirectory>
  237. <destFileName>junit.jar</destFileName>
  238. </artifactItem>
  239. <artifactItem>
  240. <!-- Binary is identical to committed version -->
  241. <groupId>junit</groupId>
  242. <artifactId>junit</artifactId>
  243. <version>3.8.1</version>
  244. <type>jar</type>
  245. <classifier>sources</classifier>
  246. <overWrite>false</overWrite>
  247. <outputDirectory>junit</outputDirectory>
  248. <destFileName>junit-src.zip</destFileName>
  249. </artifactItem>
  250. <!-- Jython does not seem to be used anywhere in AspectJ -->
  251. <artifactItem>
  252. <!-- Binary is a bit newer than committed version, but produces identical results in 'docs' -->
  253. <groupId>saxon</groupId>
  254. <artifactId>saxon</artifactId>
  255. <version>6.5.3</version>
  256. <type>jar</type>
  257. <overWrite>false</overWrite>
  258. <outputDirectory>saxon</outputDirectory>
  259. <destFileName>saxon.jar</destFileName>
  260. </artifactItem>
  261. <artifactItem>
  262. <!-- Binary is identical to committed version -->
  263. <groupId>regexp</groupId>
  264. <artifactId>regexp</artifactId>
  265. <version>${lib.regexp.version}</version>
  266. <type>jar</type>
  267. <overWrite>false</overWrite>
  268. <outputDirectory>regexp</outputDirectory>
  269. <destFileName>jakarta-regexp-1.2.jar</destFileName>
  270. </artifactItem>
  271. <!--
  272. About commons.jar + commons-src.zip:
  273. - Beanutils Binaries are commons-beanutils:commons-beanutils:1.4 (no sources on Maven Central, but
  274. https://github.com/apache/commons-beanutils/archive/refs/tags/BEANUTILS_1_4.zip)
  275. - Collections: Binaries are commons-collections:commons-collections:2.0 (no sources on Maven Central, but
  276. https://github.com/apache/commons-collections/archive/refs/tags/collections-2.0.zip)
  277. - Digester: Binaries are commons-digester:commons-digester:1.3 (no sources on Maven Central, but
  278. https://github.com/apache/commons-digester/archive/refs/tags/DIGESTER_1_3.zip)
  279. - Logging: Binaries are commons-logging:commons-logging:1.0.1 (no sources on Maven Central, but
  280. https://github.com/apache/commons-logging/archive/refs/tags/LOGGING_1_0_1.zip)
  281. -->
  282. <artifactItem>
  283. <!-- Binary is identical to committed version -->
  284. <!-- TODO: not used anywhere -> remove -->
  285. <groupId>commons-beanutils</groupId>
  286. <artifactId>commons-beanutils</artifactId>
  287. <version>${lib.commons.beanutils.version}</version>
  288. <type>jar</type>
  289. <overWrite>false</overWrite>
  290. <outputDirectory>commons</outputDirectory>
  291. <destFileName>commons-beanutils-${lib.commons.beanutils.version}.jar</destFileName>
  292. </artifactItem>
  293. <artifactItem>
  294. <!-- Binary is identical to committed version -->
  295. <!-- TODO: not used anywhere -> remove -->
  296. <groupId>commons-collections</groupId>
  297. <artifactId>commons-collections</artifactId>
  298. <version>2.0</version>
  299. <type>jar</type>
  300. <overWrite>false</overWrite>
  301. <outputDirectory>commons</outputDirectory>
  302. <destFileName>commons-collections-2.0.jar</destFileName>
  303. </artifactItem>
  304. <artifactItem>
  305. <!-- Binary is identical to committed version -->
  306. <!-- TODO: used in module 'testing' -->
  307. <groupId>commons-digester</groupId>
  308. <artifactId>commons-digester</artifactId>
  309. <version>${lib.commons.digester.version}</version>
  310. <type>jar</type>
  311. <overWrite>false</overWrite>
  312. <outputDirectory>commons</outputDirectory>
  313. <destFileName>commons-digester-${lib.commons.digester.version}.jar</destFileName>
  314. </artifactItem>
  315. <artifactItem>
  316. <!-- Binary is identical to committed version -->
  317. <!-- TODO: used in modules 'org.aspectj.matcher' -->
  318. <groupId>commons-logging</groupId>
  319. <artifactId>commons-logging</artifactId>
  320. <version>${lib.commons.logging.version}</version>
  321. <type>jar</type>
  322. <overWrite>false</overWrite>
  323. <outputDirectory>commons</outputDirectory>
  324. <destFileName>commons-logging-${lib.commons.logging.version}.jar</destFileName>
  325. </artifactItem>
  326. <!-- Libraries used to create HTML docs from XML DocBook files -->
  327. <artifactItem>
  328. <!-- Binary is identical to committed version -->
  329. <groupId>fop</groupId>
  330. <artifactId>fop</artifactId>
  331. <version>0.20.5</version>
  332. <type>jar</type>
  333. <overWrite>false</overWrite>
  334. <outputDirectory>docbook</outputDirectory>
  335. <destFileName>fop.jar</destFileName>
  336. </artifactItem>
  337. <artifactItem>
  338. <!-- Binary is identical to committed version -->
  339. <groupId>batik</groupId>
  340. <artifactId>batik-1.5-fop</artifactId>
  341. <version>0.20-5</version>
  342. <type>jar</type>
  343. <overWrite>false</overWrite>
  344. <outputDirectory>docbook</outputDirectory>
  345. <destFileName>batik.jar</destFileName>
  346. </artifactItem>
  347. </artifactItems>
  348. </configuration>
  349. </execution>
  350. </executions>
  351. </plugin>
  352. <!-- (Un)zip downloaded libraries the way our build needs them -->
  353. <plugin>
  354. <groupId>org.codehaus.mojo</groupId>
  355. <artifactId>truezip-maven-plugin</artifactId>
  356. <version>1.2</version>
  357. <!--
  358. The TrueZIP plugin can seamlessly copy out of or into (nested) ZIP files as if they were normal file system
  359. paths. No additional moves and deletes with Antrun are necessary.
  360. -->
  361. <executions>
  362. <execution>
  363. <id>unzip-ant-binaries</id>
  364. <phase>process-resources</phase>
  365. <goals>
  366. <goal>copy</goal>
  367. </goals>
  368. <configuration>
  369. <verbose>true</verbose>
  370. <fileset>
  371. <directory>ant/${lib.ant.artifact}-bin.zip/${lib.ant.artifact}</directory>
  372. <outputDirectory>ant</outputDirectory>
  373. </fileset>
  374. </configuration>
  375. </execution>
  376. <execution>
  377. <id>zip-ant-sources</id>
  378. <phase>process-resources</phase>
  379. <goals>
  380. <goal>copy</goal>
  381. </goals>
  382. <configuration>
  383. <verbose>true</verbose>
  384. <fileset>
  385. <directory>ant/${lib.ant.artifact}-src.zip/${lib.ant.artifact}/src/main</directory>
  386. <outputDirectory>ant/ant-src.zip</outputDirectory>
  387. </fileset>
  388. </configuration>
  389. </execution>
  390. <execution>
  391. <id>zip-beanutils-binaries</id>
  392. <phase>process-resources</phase>
  393. <goals>
  394. <goal>copy</goal>
  395. </goals>
  396. <configuration>
  397. <verbose>true</verbose>
  398. <fileset>
  399. <directory>commons/commons-beanutils-${lib.commons.beanutils.version}.jar</directory>
  400. <outputDirectory>commons/commons.jar</outputDirectory>
  401. </fileset>
  402. </configuration>
  403. </execution>
  404. <execution>
  405. <id>zip-collections-binaries</id>
  406. <phase>process-resources</phase>
  407. <goals>
  408. <goal>copy</goal>
  409. </goals>
  410. <configuration>
  411. <verbose>true</verbose>
  412. <fileset>
  413. <directory>commons/commons-collections-${lib.commons.collections.version}.jar</directory>
  414. <outputDirectory>commons/commons.jar</outputDirectory>
  415. </fileset>
  416. </configuration>
  417. </execution>
  418. <execution>
  419. <id>zip-digester-binaries</id>
  420. <phase>process-resources</phase>
  421. <goals>
  422. <goal>copy</goal>
  423. </goals>
  424. <configuration>
  425. <verbose>true</verbose>
  426. <fileset>
  427. <directory>commons/commons-digester-${lib.commons.digester.version}.jar</directory>
  428. <outputDirectory>commons/commons.jar</outputDirectory>
  429. </fileset>
  430. </configuration>
  431. </execution>
  432. <execution>
  433. <id>zip-logging-binaries</id>
  434. <phase>process-resources</phase>
  435. <goals>
  436. <goal>copy</goal>
  437. </goals>
  438. <configuration>
  439. <verbose>true</verbose>
  440. <fileset>
  441. <directory>commons/commons-logging-${lib.commons.logging.version}.jar</directory>
  442. <outputDirectory>commons/commons.jar</outputDirectory>
  443. </fileset>
  444. </configuration>
  445. </execution>
  446. <execution>
  447. <id>zip-beanutils-sources</id>
  448. <phase>process-resources</phase>
  449. <goals>
  450. <goal>copy</goal>
  451. </goals>
  452. <configuration>
  453. <verbose>true</verbose>
  454. <fileset>
  455. <directory>commons/commons-beanutils-${lib.commons.beanutils.version}-sources.jar/commons-beanutils-${lib.commons.beanutils.tag}/src/java</directory>
  456. <outputDirectory>commons/commons-src.zip</outputDirectory>
  457. </fileset>
  458. </configuration>
  459. </execution>
  460. <execution>
  461. <id>zip-collections-sources</id>
  462. <phase>process-resources</phase>
  463. <goals>
  464. <goal>copy</goal>
  465. </goals>
  466. <configuration>
  467. <verbose>true</verbose>
  468. <fileset>
  469. <directory>commons/commons-collections-${lib.commons.collections.version}-sources.jar/commons-collections-${lib.commons.collections.tag}/src/java</directory>
  470. <outputDirectory>commons/commons-src.zip</outputDirectory>
  471. </fileset>
  472. </configuration>
  473. </execution>
  474. <execution>
  475. <id>zip-digester-sources</id>
  476. <phase>process-resources</phase>
  477. <goals>
  478. <goal>copy</goal>
  479. </goals>
  480. <configuration>
  481. <verbose>true</verbose>
  482. <fileset>
  483. <directory>commons/commons-digester-${lib.commons.digester.version}-sources.jar/commons-digester-${lib.commons.digester.tag}/src/java</directory>
  484. <outputDirectory>commons/commons-src.zip</outputDirectory>
  485. </fileset>
  486. </configuration>
  487. </execution>
  488. <execution>
  489. <id>zip-logging-sources</id>
  490. <phase>process-resources</phase>
  491. <goals>
  492. <goal>copy</goal>
  493. </goals>
  494. <configuration>
  495. <verbose>true</verbose>
  496. <fileset>
  497. <directory>commons/commons-logging-${lib.commons.logging.version}-sources.jar/commons-logging-${lib.commons.logging.tag}/src/java</directory>
  498. <outputDirectory>commons/commons-src.zip</outputDirectory>
  499. </fileset>
  500. </configuration>
  501. </execution>
  502. <execution>
  503. <id>unzip-docbook-dtd</id>
  504. <phase>process-resources</phase>
  505. <goals>
  506. <goal>copy</goal>
  507. </goals>
  508. <configuration>
  509. <verbose>true</verbose>
  510. <fileset>
  511. <directory>docbook/docbkx412.zip</directory>
  512. <outputDirectory>docbook/docbook-dtd</outputDirectory>
  513. </fileset>
  514. </configuration>
  515. </execution>
  516. <execution>
  517. <id>unzip-docbook-xsl</id>
  518. <phase>process-resources</phase>
  519. <goals>
  520. <goal>copy</goal>
  521. </goals>
  522. <configuration>
  523. <verbose>true</verbose>
  524. <fileset>
  525. <directory>docbook/docbook-xsl-1.44.zip/docbook-xsl-1.44</directory>
  526. <outputDirectory>docbook/docbook-xsl</outputDirectory>
  527. </fileset>
  528. </configuration>
  529. </execution>
  530. <!--
  531. Obsolete because we uploaded both binary and source JARs to GitHub Packages, so we can use JDiff as a normal
  532. dependency. Keep this for reference, so we can remember how we built it. After download + zip the deployment
  533. was made right from the lib/jdiff directory, using the following commands (without the line breaks):
  534. mvn -Dfile=jdiff.jar -DrepositoryId=github -Durl=https://maven.pkg.github.com/kriegaex/aspectj-packages
  535. -DgroupId=jdiff -DartifactId=jdiff -Dpackaging=jar -Dversion=1.3
  536. deploy:deploy-file
  537. mvn -Dfile=jdiff-src.zip -DrepositoryId=github -Durl=https://maven.pkg.github.com/kriegaex/aspectj-packages
  538. -DgroupId=jdiff -DartifactId=jdiff -Dpackaging=jar -Dversion=1.3
  539. -Dtypes=java-source -Dclassifier=sources
  540. deploy:deploy-file
  541. The second command yields an error, trying to re-upload a POM, but that is no problem because the POM would
  542. be identical to the one already uploaded with the first command.
  543. -->
  544. <!--
  545. <execution>
  546. <id>zip-jdiff-binaries</id>
  547. <phase>process-resources</phase>
  548. <goals>
  549. <goal>copy</goal>
  550. </goals>
  551. <configuration>
  552. <verbose>true</verbose>
  553. <fileset>
  554. <directory>jdiff/JDiffPlugin-1.3.zip/JDiffPlugin.jar</directory>
  555. <outputDirectory>jdiff/jdiff.jar</outputDirectory>
  556. <includes>
  557. <include>**/*.class</include>
  558. </includes>
  559. <excludes>
  560. <exclude>jdiff/options/**</exclude>
  561. <exclude>jdiff/*.class</exclude>
  562. </excludes>
  563. </fileset>
  564. </configuration>
  565. </execution>
  566. <execution>
  567. <id>zip-jdiff-sources</id>
  568. <phase>process-resources</phase>
  569. <goals>
  570. <goal>copy</goal>
  571. </goals>
  572. <configuration>
  573. <verbose>true</verbose>
  574. <fileset>
  575. <directory>jdiff/JDiffPlugin-1.3.zip/JDiffPlugin</directory>
  576. <outputDirectory>jdiff/jdiff-src.zip</outputDirectory>
  577. <includes>
  578. <include>**/*.java</include>
  579. </includes>
  580. <excludes>
  581. <exclude>jdiff/options/**</exclude>
  582. <exclude>jdiff/*.java</exclude>
  583. </excludes>
  584. </fileset>
  585. </configuration>
  586. </execution>
  587. -->
  588. </executions>
  589. </plugin>
  590. <!--
  591. After all libraries have been provisioned successfully, create a marker file in order to avoid provisioning
  592. them again during the next build
  593. -->
  594. <plugin>
  595. <groupId>org.codehaus.mojo</groupId>
  596. <artifactId>build-helper-maven-plugin</artifactId>
  597. <executions>
  598. <execution>
  599. <id>create-marker-file</id>
  600. <phase>process-resources</phase>
  601. <goals>
  602. <goal>bsh-property</goal>
  603. </goals>
  604. <configuration>
  605. <source><![CDATA[
  606. myFile = new File(project.getBasedir(), "${lib.provisioned.marker}");
  607. print("Finished provisioning libraries, creating marker file " + myFile.getCanonicalPath());
  608. myFile.createNewFile();
  609. ]]></source>
  610. </configuration>
  611. </execution>
  612. </executions>
  613. </plugin>
  614. </plugins>
  615. </build>
  616. <dependencies>
  617. <dependency>
  618. <groupId>org.aspectj</groupId>
  619. <artifactId>org.eclipse.jdt.core</artifactId>
  620. </dependency>
  621. </dependencies>
  622. </profile>
  623. <!-- Profile for including provisioned libraries when running 'mvn clean'; inactive by default, activate manually -->
  624. <profile>
  625. <id>clean-libs</id>
  626. <build>
  627. <plugins>
  628. <plugin>
  629. <groupId>org.apache.maven.plugins</groupId>
  630. <artifactId>maven-clean-plugin</artifactId>
  631. <executions>
  632. <execution>
  633. <id>clean-up-libs</id>
  634. <phase>clean</phase>
  635. <goals>
  636. <goal>clean</goal>
  637. </goals>
  638. <configuration>
  639. <filesets>
  640. <fileset>
  641. <directory>.</directory>
  642. <includes>
  643. <include>${lib.provisioned.marker}</include>
  644. <include>ant/**</include>
  645. <include>commons/**</include>
  646. <include>docbook/**</include>
  647. <include>jarjar/**</include>
  648. <!-- Obsolete because JDiff is on GitHub Packages now. Keep for reference. -->
  649. <!--<include>jdiff/**</include>-->
  650. <include>jdtcore-aj/**</include>
  651. <include>junit/**</include>
  652. <include>regexp/**</include>
  653. <include>saxon/**</include>
  654. </includes>
  655. <followSymlinks>false</followSymlinks>
  656. </fileset>
  657. </filesets>
  658. </configuration>
  659. </execution>
  660. </executions>
  661. </plugin>
  662. </plugins>
  663. </build>
  664. </profile>
  665. </profiles>
  666. <build>
  667. <plugins>
  668. <!--
  669. Heuristic consistency check for existence of provisioned library files. Do not just rely on
  670. ${lib.provisioned.marker} file.
  671. -->
  672. <plugin>
  673. <groupId>org.apache.maven.plugins</groupId>
  674. <artifactId>maven-enforcer-plugin</artifactId>
  675. <executions>
  676. <execution>
  677. <id>enforce-libraries-exist</id>
  678. <phase>process-resources</phase>
  679. <goals>
  680. <goal>enforce</goal>
  681. </goals>
  682. <configuration>
  683. <rules>
  684. <requireFilesExist>
  685. <!--
  686. Do NOT insert any line breaks + indentation inside the message, keep it on a single line.
  687. Maven Enforcer does not strip any whitespace or unindent, which looks quite ugly on the console.
  688. -->
  689. <message>
  690. There is an inconsistency in module subdirectory 'lib'. Please run 'mvn --projects lib -P clean-libs clean compile'. This should take care of cleaning and freshly downloading all necessary libraries to that directory, where some tests expect them to be.
  691. </message>
  692. <files>
  693. <file>${lib.provisioned.marker}</file>
  694. <file>ant/bin/ant.bat</file>
  695. <file>ant/lib/junit.jar</file>
  696. <file>commons/commons.jar</file>
  697. <file>docbook/docbook-dtd/docbookx.dtd</file>
  698. <file>docbook/docbook-xsl/html/chunk.xsl</file>
  699. <file>docbook/fop.jar</file>
  700. <file>docbook/batik.jar</file>
  701. <file>jarjar/jarjar-1.3.jar</file>
  702. <file>jdtcore-aj/jdtcore-for-aspectj.jar</file>
  703. <file>junit/junit.jar</file>
  704. <file>regexp/jakarta-regexp-1.2.jar</file>
  705. <file>saxon/saxon.jar</file>
  706. </files>
  707. </requireFilesExist>
  708. </rules>
  709. <fail>true</fail>
  710. </configuration>
  711. </execution>
  712. </executions>
  713. </plugin>
  714. </plugins>
  715. </build>
  716. </project>