All,
On 10/12/26 12:43 PM, Christopher Schultz wrote:
All,
Tomcat ships with a package-renamed version of the Apache commons-pool2
and commons-dbcp2 projects, minus a few classes that we don't need (I
think).
I don't see a reason for the Tomcat team to maintain a separate copy of
the source tree, manage patches from upstream, etc.
My proposal is to drop the source from our repository and instead
maintain the desired version number and hashes as we do for other
dependencies (e.g. commons-daemon), and automatically shade the commons-
* release JARs as part of the Tomcat release process.
I'm sure I'll be able to get download and shading working, but I may
need some help with the OSGi stuff. My plan would be to use Jar Jar
Links[1] (yes, that's the name of the project) for the actual shading:
it already has an ant task which extends <jar> which means it should
support our reproducible-build timestamps. It should be able to handle
merging pool2 and dbcp2 together and re-writing the dependencies correctly.
NOTE: While this will require a network connection to download these
artifacts during the build, it does not represent an *additional*
network connection: we already require a network connection if other
artifacts are not present locally. Performing a "download-compile"
should be sufficient to gather the required dependencies before
disconnecting from a network. The release can then be built without a
working network connection.
-chris
[1] https://github.com/shevek/jarjar
Okay, jarjar is old and uses its own (old) version of ASM which means it
(silently!) does not work with newer Java class file versions. :(
There are still other options, of course. It might even be possible to
add an ad-hoc profile to the Migration Tool which can do this for us.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
