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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans Bump download-maven-plugin 1.6.1 -> 1.6.3
In the previous GitHub build, there were warnings in the log because of
failed downloads. Actually, the default is to fail the build, but that
did not happen. Let us try a more recent version, maybe it fixes an old
bug, even though in the diff between the versions I did not see anything
obvious here.
Anyway, I created an issue ticket:
https://github.com/maven-download-plugin/maven-download-plugin/issues/185
BTW, our build only failed later during the Maven Enforcer sanity check,
because several files from the check list were missing after a seemingly
successful provisioning. Actually, I am glad I added this "redundant"
double-checking step to the build, otherwise the build would not have
failed in the 'lib' module but much later in a hard to detect spot.
Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans 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>
il y a 3 ans |
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750 |
- <?xml version="1.0" encoding="UTF-8"?>
- <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
- <modelVersion>4.0.0</modelVersion>
-
- <!-- The AspectJ root POM is the parent, but this module is not a submodule -->
- <parent>
- <groupId>org.aspectj</groupId>
- <artifactId>aspectj-parent</artifactId>
- <version>1.9.7.BUILD-SNAPSHOT</version>
- </parent>
-
- <artifactId>lib</artifactId>
-
- <description>
- This module downloads + installs libraries used by many tests, especially those running as Ant jobs. You should not
- build this module during every build because it is somewhat slow, downloading stuff from 3rd-party websites,
- unzipping some libraries (e.g. a full Ant distribution) and creating new ZIP files (e.g. source JARs, compound JARs
- containing multiple libraries).
-
- So just run 'mvn compile' once after cloning the AspectJ repository and you should be all set to subsequently build
- AspectJ itself. If you forget this step, a Maven Enforcer rule in the AspectJ root POM will fail the build and
- remind you to build this module.
-
- Normally you never have to call 'mvn clean' here, but if for some reason the installed libraries are in an
- inconsistent state (e.g. after an incomplete download), you can do so and then run 'mvn compile' again.
-
- BTW, running 'mvn compile' multiple times will not repeat any download via Maven Dependency or Download Maven
- plugins, but repeat all zip/unzip steps in TrueZIP Maven plugin. So try not to call it unnecessarily.
- </description>
-
- <!-- TODO: Add lib (for now, then finally lib) to .gitignore -->
-
- <properties>
- <lib.provisioned.marker>provisioned.marker</lib.provisioned.marker>
- <lib.ant.name>apache-ant</lib.ant.name>
- <lib.ant.artifact>${lib.ant.name}-${lib.ant.version}</lib.ant.artifact>
- </properties>
-
- <profiles>
-
- <!-- Profile for provisioning - i.e. downloading and (un)zipping - libraries needed during the build -->
- <profile>
- <id>provision-libs</id>
-
- <!-- If marker file is missing, activate profile and provision all libraries -->
- <activation>
- <file>
- <missing>${lib.provisioned.marker}</missing>
- </file>
- </activation>
-
- <build>
- <plugins>
-
- <!-- Download libraries + source code which are unavailable in Maven repositories like Maven Central -->
- <plugin>
- <groupId>com.googlecode.maven-download-plugin</groupId>
- <artifactId>download-maven-plugin</artifactId>
- <version>1.6.3</version>
- <executions>
- <execution>
- <id>download-ant-binaries</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://archive.apache.org/dist/ant/binaries/${lib.ant.artifact}-bin.zip</url>
- <outputDirectory>ant</outputDirectory>
- <sha1>3fa9f816a0c4c63249efad8e6225f2e83794f0c0</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-ant-sources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://archive.apache.org/dist/ant/source/${lib.ant.artifact}-src.zip</url>
- <outputDirectory>ant</outputDirectory>
- <sha1>b9f3c8c31bb6c9069ad5b655059a17769af12f20</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-beanutils-sources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://github.com/apache/commons-beanutils/archive/refs/tags/${lib.commons.beanutils.tag}.zip</url>
- <outputDirectory>commons</outputDirectory>
- <outputFileName>commons-beanutils-${lib.commons.beanutils.version}-sources.jar</outputFileName>
- <sha1>b2c02afe7e6475cd7c811932b8415d171a8afa00</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-collections-sources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://github.com/apache/commons-collections/archive/refs/tags/${lib.commons.collections.tag}.zip</url>
- <outputDirectory>commons</outputDirectory>
- <outputFileName>commons-collections-${lib.commons.collections.version}-sources.jar</outputFileName>
- <sha1>824cacd0aafe21a94fb142388fd62f28a12df5ef</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-digester-sources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://github.com/apache/commons-digester/archive/refs/tags/${lib.commons.digester.tag}.zip</url>
- <outputDirectory>commons</outputDirectory>
- <outputFileName>commons-digester-${lib.commons.digester.version}-sources.jar</outputFileName>
- <sha1>49f653c7ea726301c564f9662b72c051fee9390a</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-logging-sources</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://github.com/apache/commons-logging/archive/refs/tags/${lib.commons.logging.tag}.zip</url>
- <outputDirectory>commons</outputDirectory>
- <outputFileName>commons-logging-${lib.commons.logging.version}-sources.jar</outputFileName>
- <sha1>c61a373f6d50ff8fcfba900934f7254d44f9735b</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-docbook-dtd</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://www.oasis-open.org/docbook/xml/4.1.2/docbkx412.zip</url>
- <outputDirectory>docbook</outputDirectory>
- <outputFileName>docbkx412.zip</outputFileName>
- <sha1>b9ae7a41056bfaf885581812d60651b7b5531519</sha1>
- </configuration>
- </execution>
- <execution>
- <id>download-docbook-xsl</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://sourceforge.net/projects/docbook/files/OldFiles/docbook-xsl-1.44.zip/download</url>
- <outputDirectory>docbook</outputDirectory>
- <outputFileName>docbook-xsl-1.44.zip</outputFileName>
- <sha1>626e7bee806ea14812f6f95cc2d187ab6ba9114a</sha1>
- </configuration>
- </execution>
- <!--
- Obsolete because we uploaded both binary and source JARs to GitHub Packages, so we can use JDiff as a
- normal dependency. Keep this for reference, so we can remember where we found it.
- -->
- <!--
- <execution>
- <id>download-jdiff</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>wget</goal>
- </goals>
- <configuration>
- <url>https://downloads.sourceforge.net/project/jedit-plugins/JDiffPlugin/1.3/JDiffPlugin-1.3.zip</url>
- <outputDirectory>jdiff</outputDirectory>
- <outputFileName>JDiffPlugin-1.3.zip</outputFileName>
- <sha1>eba63fd845203c6b245fbcb81c0de8e2c83d16c7</sha1>
- </configuration>
- </execution>
- -->
- </executions>
- </plugin>
-
- <!-- Download libraries + source code which are available in Maven repositories like Maven Central -->
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-dependency-plugin</artifactId>
- <version>3.1.2</version>
- <executions>
- <execution>
- <id>copy</id>
- <phase>generate-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <artifactItems>
-
- <artifactItem>
- <!-- Available from GitHub Packages (needs special repository declaration) -->
- <groupId>org.aspectj</groupId>
- <artifactId>org.eclipse.jdt.core</artifactId>
- <version>${jdt.core.version}</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>jdtcore-aj</outputDirectory>
- <destFileName>jdtcore-for-aspectj.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Available from GitHub Packages (needs special repository declaration) -->
- <groupId>org.aspectj</groupId>
- <artifactId>org.eclipse.jdt.core</artifactId>
- <version>${jdt.core.version}</version>
- <type>java-source</type>
- <classifier>sources</classifier>
- <overWrite>false</overWrite>
- <outputDirectory>jdtcore-aj</outputDirectory>
- <destFileName>jdtcore-for-aspectj-src.zip</destFileName>
- </artifactItem>
-
- <artifactItem>
- <!-- Binary is identical to committed version in branch 'jdtcore-new' -->
- <groupId>com.googlecode.jarjar</groupId>
- <artifactId>jarjar</artifactId>
- <version>1.3</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>jarjar</outputDirectory>
- <destFileName>jarjar-1.3.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <groupId>junit</groupId>
- <artifactId>junit</artifactId>
- <version>3.8.1</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>junit</outputDirectory>
- <destFileName>junit.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <!-- TODO: Is this redundant JUnit JAR in ant/lib really necessary? If so, why? -->
- <groupId>junit</groupId>
- <artifactId>junit</artifactId>
- <version>3.8.1</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>ant/lib</outputDirectory>
- <destFileName>junit.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <groupId>junit</groupId>
- <artifactId>junit</artifactId>
- <version>3.8.1</version>
- <type>jar</type>
- <classifier>sources</classifier>
- <overWrite>false</overWrite>
- <outputDirectory>junit</outputDirectory>
- <destFileName>junit-src.zip</destFileName>
- </artifactItem>
-
- <!-- Jython does not seem to be used anywhere in AspectJ -->
-
- <artifactItem>
- <!-- Binary is a bit newer than committed version, but produces identical results in 'docs' -->
- <groupId>saxon</groupId>
- <artifactId>saxon</artifactId>
- <version>6.5.3</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>saxon</outputDirectory>
- <destFileName>saxon.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <groupId>regexp</groupId>
- <artifactId>regexp</artifactId>
- <version>${lib.regexp.version}</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>regexp</outputDirectory>
- <destFileName>jakarta-regexp-1.2.jar</destFileName>
- </artifactItem>
-
- <!--
- About commons.jar + commons-src.zip:
- - Beanutils Binaries are commons-beanutils:commons-beanutils:1.4 (no sources on Maven Central, but
- https://github.com/apache/commons-beanutils/archive/refs/tags/BEANUTILS_1_4.zip)
- - Collections: Binaries are commons-collections:commons-collections:2.0 (no sources on Maven Central, but
- https://github.com/apache/commons-collections/archive/refs/tags/collections-2.0.zip)
- - Digester: Binaries are commons-digester:commons-digester:1.3 (no sources on Maven Central, but
- https://github.com/apache/commons-digester/archive/refs/tags/DIGESTER_1_3.zip)
- - Logging: Binaries are commons-logging:commons-logging:1.0.1 (no sources on Maven Central, but
- https://github.com/apache/commons-logging/archive/refs/tags/LOGGING_1_0_1.zip)
- -->
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <!-- TODO: not used anywhere -> remove -->
- <groupId>commons-beanutils</groupId>
- <artifactId>commons-beanutils</artifactId>
- <version>${lib.commons.beanutils.version}</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>commons</outputDirectory>
- <destFileName>commons-beanutils-${lib.commons.beanutils.version}.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <!-- TODO: not used anywhere -> remove -->
- <groupId>commons-collections</groupId>
- <artifactId>commons-collections</artifactId>
- <version>2.0</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>commons</outputDirectory>
- <destFileName>commons-collections-2.0.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <!-- TODO: used in module 'testing' -->
- <groupId>commons-digester</groupId>
- <artifactId>commons-digester</artifactId>
- <version>${lib.commons.digester.version}</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>commons</outputDirectory>
- <destFileName>commons-digester-${lib.commons.digester.version}.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <!-- TODO: used in modules 'org.aspectj.matcher' -->
- <groupId>commons-logging</groupId>
- <artifactId>commons-logging</artifactId>
- <version>${lib.commons.logging.version}</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>commons</outputDirectory>
- <destFileName>commons-logging-${lib.commons.logging.version}.jar</destFileName>
- </artifactItem>
-
- <!-- Libraries used to create HTML docs from XML DocBook files -->
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <groupId>fop</groupId>
- <artifactId>fop</artifactId>
- <version>0.20.5</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>docbook</outputDirectory>
- <destFileName>fop.jar</destFileName>
- </artifactItem>
- <artifactItem>
- <!-- Binary is identical to committed version -->
- <groupId>batik</groupId>
- <artifactId>batik-1.5-fop</artifactId>
- <version>0.20-5</version>
- <type>jar</type>
- <overWrite>false</overWrite>
- <outputDirectory>docbook</outputDirectory>
- <destFileName>batik.jar</destFileName>
- </artifactItem>
-
- </artifactItems>
- </configuration>
- </execution>
- </executions>
- </plugin>
-
- <!-- (Un)zip downloaded libraries the way our build needs them -->
- <plugin>
- <groupId>org.codehaus.mojo</groupId>
- <artifactId>truezip-maven-plugin</artifactId>
- <version>1.2</version>
- <!--
- The TrueZIP plugin can seamlessly copy out of or into (nested) ZIP files as if they were normal file system
- paths. No additional moves and deletes with Antrun are necessary.
- -->
- <executions>
- <execution>
- <id>unzip-ant-binaries</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>ant/${lib.ant.artifact}-bin.zip/${lib.ant.artifact}</directory>
- <outputDirectory>ant</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-ant-sources</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>ant/${lib.ant.artifact}-src.zip/${lib.ant.artifact}/src/main</directory>
- <outputDirectory>ant/ant-src.zip</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-beanutils-binaries</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-beanutils-${lib.commons.beanutils.version}.jar</directory>
- <outputDirectory>commons/commons.jar</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-collections-binaries</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-collections-${lib.commons.collections.version}.jar</directory>
- <outputDirectory>commons/commons.jar</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-digester-binaries</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-digester-${lib.commons.digester.version}.jar</directory>
- <outputDirectory>commons/commons.jar</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-logging-binaries</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-logging-${lib.commons.logging.version}.jar</directory>
- <outputDirectory>commons/commons.jar</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-beanutils-sources</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-beanutils-${lib.commons.beanutils.version}-sources.jar/commons-beanutils-${lib.commons.beanutils.tag}/src/java</directory>
- <outputDirectory>commons/commons-src.zip</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-collections-sources</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-collections-${lib.commons.collections.version}-sources.jar/commons-collections-${lib.commons.collections.tag}/src/java</directory>
- <outputDirectory>commons/commons-src.zip</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-digester-sources</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-digester-${lib.commons.digester.version}-sources.jar/commons-digester-${lib.commons.digester.tag}/src/java</directory>
- <outputDirectory>commons/commons-src.zip</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-logging-sources</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>commons/commons-logging-${lib.commons.logging.version}-sources.jar/commons-logging-${lib.commons.logging.tag}/src/java</directory>
- <outputDirectory>commons/commons-src.zip</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>unzip-docbook-dtd</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>docbook/docbkx412.zip</directory>
- <outputDirectory>docbook/docbook-dtd</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>unzip-docbook-xsl</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>docbook/docbook-xsl-1.44.zip/docbook-xsl-1.44</directory>
- <outputDirectory>docbook/docbook-xsl</outputDirectory>
- </fileset>
- </configuration>
- </execution>
- <!--
- Obsolete because we uploaded both binary and source JARs to GitHub Packages, so we can use JDiff as a normal
- dependency. Keep this for reference, so we can remember how we built it. After download + zip the deployment
- was made right from the lib/jdiff directory, using the following commands (without the line breaks):
-
- mvn -Dfile=jdiff.jar -DrepositoryId=github -Durl=https://maven.pkg.github.com/kriegaex/aspectj-packages
- -DgroupId=jdiff -DartifactId=jdiff -Dpackaging=jar -Dversion=1.3
- deploy:deploy-file
-
- mvn -Dfile=jdiff-src.zip -DrepositoryId=github -Durl=https://maven.pkg.github.com/kriegaex/aspectj-packages
- -DgroupId=jdiff -DartifactId=jdiff -Dpackaging=jar -Dversion=1.3
- -Dtypes=java-source -Dclassifier=sources
- deploy:deploy-file
-
- The second command yields an error, trying to re-upload a POM, but that is no problem because the POM would
- be identical to the one already uploaded with the first command.
- -->
- <!--
- <execution>
- <id>zip-jdiff-binaries</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>jdiff/JDiffPlugin-1.3.zip/JDiffPlugin.jar</directory>
- <outputDirectory>jdiff/jdiff.jar</outputDirectory>
- <includes>
- <include>**/*.class</include>
- </includes>
- <excludes>
- <exclude>jdiff/options/**</exclude>
- <exclude>jdiff/*.class</exclude>
- </excludes>
- </fileset>
- </configuration>
- </execution>
- <execution>
- <id>zip-jdiff-sources</id>
- <phase>process-resources</phase>
- <goals>
- <goal>copy</goal>
- </goals>
- <configuration>
- <verbose>true</verbose>
- <fileset>
- <directory>jdiff/JDiffPlugin-1.3.zip/JDiffPlugin</directory>
- <outputDirectory>jdiff/jdiff-src.zip</outputDirectory>
- <includes>
- <include>**/*.java</include>
- </includes>
- <excludes>
- <exclude>jdiff/options/**</exclude>
- <exclude>jdiff/*.java</exclude>
- </excludes>
- </fileset>
- </configuration>
- </execution>
- -->
- </executions>
- </plugin>
-
- <!--
- After all libraries have been provisioned successfully, create a marker file in order to avoid provisioning
- them again during the next build
- -->
- <plugin>
- <groupId>org.codehaus.mojo</groupId>
- <artifactId>build-helper-maven-plugin</artifactId>
- <executions>
- <execution>
- <id>create-marker-file</id>
- <phase>process-resources</phase>
- <goals>
- <goal>bsh-property</goal>
- </goals>
- <configuration>
- <source><![CDATA[
- myFile = new File(project.getBasedir(), "${lib.provisioned.marker}");
- print("Finished provisioning libraries, creating marker file " + myFile.getCanonicalPath());
- myFile.createNewFile();
- ]]></source>
- </configuration>
- </execution>
- </executions>
- </plugin>
-
- </plugins>
- </build>
-
- <dependencies>
- <dependency>
- <groupId>org.aspectj</groupId>
- <artifactId>org.eclipse.jdt.core</artifactId>
- </dependency>
- </dependencies>
-
- </profile>
-
- <!-- Profile for including provisioned libraries when running 'mvn clean'; inactive by default, activate manually -->
- <profile>
- <id>clean-libs</id>
-
- <build>
- <plugins>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-clean-plugin</artifactId>
- <executions>
- <execution>
- <id>clean-up-libs</id>
- <phase>clean</phase>
- <goals>
- <goal>clean</goal>
- </goals>
- <configuration>
- <filesets>
- <fileset>
- <directory>.</directory>
- <includes>
- <include>${lib.provisioned.marker}</include>
- <include>ant/**</include>
- <include>commons/**</include>
- <include>docbook/**</include>
- <include>jarjar/**</include>
- <!-- Obsolete because JDiff is on GitHub Packages now. Keep for reference. -->
- <!--<include>jdiff/**</include>-->
- <include>jdtcore-aj/**</include>
- <include>junit/**</include>
- <include>regexp/**</include>
- <include>saxon/**</include>
- </includes>
- <followSymlinks>false</followSymlinks>
- </fileset>
- </filesets>
- </configuration>
- </execution>
- </executions>
- </plugin>
- </plugins>
- </build>
-
- </profile>
-
- </profiles>
-
- <build>
- <plugins>
- <!--
- Heuristic consistency check for existence of provisioned library files. Do not just rely on
- ${lib.provisioned.marker} file.
- -->
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-enforcer-plugin</artifactId>
- <executions>
- <execution>
- <id>enforce-libraries-exist</id>
- <phase>compile</phase>
- <goals>
- <goal>enforce</goal>
- </goals>
- <configuration>
- <rules>
- <requireFilesExist>
- <!--
- Do NOT insert any line breaks + indentation inside the message, keep it on a single line.
- Maven Enforcer does not strip any whitespace or unindent, which looks quite ugly on the console.
- -->
- <message>
- 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.
- </message>
- <files>
- <file>${lib.provisioned.marker}</file>
- <file>ant/bin/ant.bat</file>
- <file>ant/lib/junit.jar</file>
- <file>commons/commons.jar</file>
- <file>docbook/docbook-dtd/docbookx.dtd</file>
- <file>docbook/docbook-xsl/html/chunk.xsl</file>
- <file>docbook/fop.jar</file>
- <file>docbook/batik.jar</file>
- <file>jarjar/jarjar-1.3.jar</file>
- <file>jdtcore-aj/jdtcore-for-aspectj.jar</file>
- <file>junit/junit.jar</file>
- <file>regexp/jakarta-regexp-1.2.jar</file>
- <file>saxon/saxon.jar</file>
- </files>
- </requireFilesExist>
- </rules>
- <fail>true</fail>
- </configuration>
- </execution>
- </executions>
- </plugin>
- </plugins>
- </build>
-
- </project>
|