> -----Original Message----- > From: [email protected] [mailto:[email protected]] 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 org.apache.commons.io.IOUtils 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.
