Wayne you're right about the <dependencyManagement>, and we've
actually recently implemented that: it works with regard to
eliminating the duplicates. Which means I didn't think long enough
about how to express the problem I'm actually experiencing.
We've got a webapp that provides some basic functionality, and we've
also got jars that (if present in WEB-INF/lib) contribute additional
pages, menu items, etc. But these are optional. So:
Webabb (W)
Personality (A) is a jar that (optionally) goes into WEB-INF/lib
Personality (B) is a jar that (optionally) goes into WEB-INF/lib
W(A+B) is also allowed and meaningful. W by itself works but is not
terribly useful.
Now, it so happens that the (dependencies of A) and (dependencies of
B) overlap somewhat. Also, (dependencies of W) overlap somewhat with
(dependencies of A) and (dependencies of B).
Here's the relevance to the Subject: line:
I have to produce standalone installers for the baseline app (W) as
well as each optional personality that might be added to it (A and B
and ...). These installers have to add everything that is needed for
the additional functionality of the indicated personality. Another way
to say this is, whenever I install the A personality, it needs to come
with all of its (transitive) dependencies. Likewise B. But when Maven
sometimes names artifacts as foo-1.0.0-SNAPSHOT.jar and sometimes
names the identical artifact as foo-1.0.0-20070404.175630-185.jar, it
interferes with this kind of factoring. Because,
foo-1.0.0-SNAPSHOT.jar coming from a W (base webapp) installer will be
overwritten by foo-1.0.0-SNAPSHOT.jar coming from A (additional
personality) and there's no problem at all. But when the artifact as
delivered with W was called foo-1.0.0-20070404.175630-185.jar, you end
up with two copies of the same library on the classpath. A file only
overwrites another file if they both are named the same.
I hope the explanation of my problem has not been so confusing as to
lose audience, I really hope someone out there has experience to see
through my problem and explain to me the solution!
Thanks,
--
Tommy
On 4/6/07, Wayne Fay <[EMAIL PROTECTED]> wrote:
Try extracting all your dependencies (with versions) and move them
into a <dependencyManagement/> section in a shared parent pom. Then
remove the <version/> nodes specified in the dependencies in all the
children poms.
Wayne
On 4/6/07, Tommy Knowlton <[EMAIL PROTECTED]> wrote:
> Hello,
>
> My project team has got on the order of 30 projects that contribute to
> a single webapp. Most of the projects produce
> <packaging>jar</packaging> artifacts, that go into the webapp's
> WEB-INF/lib.
>
> The problem I'm having is inconsistency with how Maven resolves (and
> names) versioned artifacts... Within WEB-INF/lib, I see things like:
>
> project-a-1.0.0-20070406.175320-144.jar
> project-b-1.0.0-SNAPSHOT.jar
>
> Mind you, both projects A and B are at
> <version>1.0.0-SNAPSHOT</version> both within their own POMs as well
> as in the <dependencies/> of dependent projects' POMs.
>
> It seems like the difference in naming has to do with how directly the
> webapp depends on the given artifact: direct dependencies appear to
> get the "-SNAPSHOT" naming style, while transitive dependencies appear
> to get the "-${DATE}.${TIME}-${BUILDNUM}" style.
>
> The real problem appears when a (direct) dependency is also a
> transitive dependency. I've seen numerous instances where two copies
> (differing only by name) of the same jar end up in WEB-INF/lib.
>
> Has anybody else seen anything like this? Can somebody help me figure
> out what I'm doing wrong? I don't yet have a "minimal" example to
> demonstrate the problem, and I'm willing to believe that it's the
> large complex nature of my project that is contributing, but I don't
> yet know where to start looking for the cause.
>
> Thanks,
> --
> Tommy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
