You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jim Garrison <ji...@nwea.org> on 2013/06/28 19:32:16 UTC
Complex dependency-override scenario
I have inherited the following dependency hierarchy, with A, B, C and D being four related source projects.
A (packaging:EAR) depends on B, C and D
B (packaging:WAR) depends on D
C (packaging:EJB) depends on D
D (packaging:JAR) depends on the BIRT runtime, which has a transitive dependency on org.apache.batik.pdf
/--->B
/ \
A---->C \
\ \ |
\ \ |
\----->D--> birt.runtime --> batik-pdf
What I need to accomplish:
Remove some classes from org.apache.batik.pdf's jar artifact
I think I can accomplish this in two steps:
1) the unpack goal of maven-dependency-plugin bound to its default process-sources phase,
specifying class exclusions
2) the jar goal of maven-jar-plugin with a classifier to create an attached jar
What I don't know:
1) where in the target directory should I do the unpack and re-jar
2) how to substitute the modified jar for the batik dependency so
my jar gets used for building and is included in module A's .ear, while
ensuring that the batik jar is excluded
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Complex dependency-override scenario
Posted by Jim Garrison <ji...@nwea.org>.
> -----Original Message-----
> From: bmathus@gmail.com [mailto:bmathus@gmail.com] 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.
Re: Complex dependency-override scenario
Posted by Baptiste MATHUS <ml...@batmat.net>.
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.
Cheers
Le 28 juin 2013 19:33, "Jim Garrison" <ji...@nwea.org> a écrit :
> I have inherited the following dependency hierarchy, with A, B, C and D
> being four related source projects.
>
> A (packaging:EAR) depends on B, C and D
> B (packaging:WAR) depends on D
> C (packaging:EJB) depends on D
> D (packaging:JAR) depends on the BIRT runtime, which has a transitive
> dependency on org.apache.batik.pdf
>
> /--->B
> / \
> A---->C \
> \ \ |
> \ \ |
> \----->D--> birt.runtime --> batik-pdf
>
> What I need to accomplish:
>
> Remove some classes from org.apache.batik.pdf's jar artifact
>
> I think I can accomplish this in two steps:
>
> 1) the unpack goal of maven-dependency-plugin bound to its default
> process-sources phase,
> specifying class exclusions
> 2) the jar goal of maven-jar-plugin with a classifier to create an
> attached jar
>
> What I don't know:
>
> 1) where in the target directory should I do the unpack and re-jar
> 2) how to substitute the modified jar for the batik dependency so
> my jar gets used for building and is included in module A's .ear,
> while
> ensuring that the batik jar is excluded
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Complex dependency-override scenario
Posted by Wayne Fay <wa...@gmail.com>.
> What I need to accomplish:
>
> Remove some classes from org.apache.batik.pdf's jar artifact
>
> I think I can accomplish this in two steps:
>
> 1) the unpack goal of maven-dependency-plugin bound to its default process-sources phase,
> specifying class exclusions
> 2) the jar goal of maven-jar-plugin with a classifier to create an attached jar
Is this a one-time or infrequent thing, or must it be accomplished
each time your project(s) are built?
I have trouble imaging a scenario where it must be done each time.
So, I assume one-time/infrequent. In this case, I would create your
own batik jar and deploy it under your own GAV in your MRM.
> 2) how to substitute the modified jar for the batik dependency so
> my jar gets used for building and is included in module A's .ear, while
> ensuring that the batik jar is excluded
I would use an <exclusion> in D and get rid of the real batik, then
replace with your private/internal batik. Then the other projects will
pull in the right one automatically.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org