Understanding SNAPSHOT dependencies

[Tommy Knowlton <To...@KE4KUG.net>]

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Understanding SNAPSHOT dependencies

[Wayne Fay <wa...@gmail.com>]

I understand your problem, and I've seen it myself (infrequently) but
don't really know how to deal with it other than telling you to stop
using SNAPSHOTs and instead specify explicit versions in your builds
etc.

This might be posted in JIRA, go check...

Wayne

On 4/6/07, Tommy Knowlton <To...@ke4kug.net> wrote:
> 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 <wa...@gmail.com> 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 <To...@ke4kug.net> 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: users-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Understanding SNAPSHOT dependencies

[Tommy Knowlton <To...@KE4KUG.net>]

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 <wa...@gmail.com> 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 <To...@ke4kug.net> 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Understanding SNAPSHOT dependencies

[Wayne Fay <wa...@gmail.com>]

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 <To...@ke4kug.net> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org