maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Garrison <>
Subject RE: Complex dependency-override scenario
Date Fri, 28 Jun 2013 21:57:56 GMT
> -----Original Message-----
> From: [] On Behalf Of
> Baptiste MATHUS
> Sent: Friday, June 28, 2013 12:45 PM
> To: Maven Users List
> Subject: Re: Complex dependency-override scenario
> Hi,
> IIRC, you didn't tell us why in the first place you want to remove those classes
> from batik. That would understand your need to help you.
> Btw, if you just want some special batik jar, why do you really bother doing it
> each time during packaging? Do it once manually, upload the jar (with a
> thorough description of its role and why the modification embedded
> somewhere in the jar) and then just depend on that custom dependency.

Thanks for your reply. I have come to the same conclusion and am now setting up the modified
artifact in our local repository.

The reason for my earlier approach is as follows.  The Batik jar file contains ancient versions
of and .CopyUtils embedded within it.  The creators of this
jar decided, for whatever reason, to include the classes themselves instead of specifying
an external dependency, and also kept the package name the same.  This might not have been
a problem except they also signed the jar.  In an environment that uses other commons-io classes,
this leads to SecurityException when the classloader finds some classes signed and others
without signatures.

Since this is a transitive dependency that our code does not use, I thought it would be more
robust to just do the patch every time our code gets built, so that future changes to the
Batik jar would not require re-generating our custom copy.

Given the difficulty of accomplishing that I have reverted to deploying a custom patched version
of the Batik dependency.
View raw message