You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Ralph Goers <Ra...@dslextreme.com> on 2006/02/28 08:44:08 UTC
dependencyManagement
We have been using Maven 1 for all our projects. We have a master
build.properties file that contains the version of every dependency we
use throughout all of our projects.
I am now attempting to build a project using maven 2 and was having some
success. I then came across
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
This looked great until I happened upon
http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2
<http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2>.
Unfortunately, this is exactly the wrong behavior for anyone moving from
version 1 to version 2. Furthermore, unless the repository at ibiblio
is going to be modified to remove the versions from the dependencies
there then this is also the incorrect default behavior for anyone -
unless everyone is forced to disable transitive dependencies.
Without this control projects will very quickly have multiple versions
of jars.
So am I missing something? Is there another configuration item that can
be specified on a dependency in the dependencyManagement section to
cause it to override child poms?
Unfortunately, unless this is remedied we will be forced to stick with
Maven 1 as the only alternative I can think of is to have our
configuration management folks modify every pom in our local repository
(our copy of ibiblio) to remove all the dependency versions.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
Thanks. I guess I'm not the first to feel this is a major design error.
Carlos Sanchez wrote:
> You can vote for the issue http://jira.codehaus.org/browse/MNG-1577
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Carlos Sanchez <ca...@apache.org>.
You can vote for the issue http://jira.codehaus.org/browse/MNG-1577
On 2/27/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> We have been using Maven 1 for all our projects. We have a master
> build.properties file that contains the version of every dependency we
> use throughout all of our projects.
>
> I am now attempting to build a project using maven 2 and was having some
> success. I then came across
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
> This looked great until I happened upon
> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2
> <http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2>.
> Unfortunately, this is exactly the wrong behavior for anyone moving from
> version 1 to version 2. Furthermore, unless the repository at ibiblio
> is going to be modified to remove the versions from the dependencies
> there then this is also the incorrect default behavior for anyone -
> unless everyone is forced to disable transitive dependencies.
>
> Without this control projects will very quickly have multiple versions
> of jars.
>
> So am I missing something? Is there another configuration item that can
> be specified on a dependency in the dependencyManagement section to
> cause it to override child poms?
>
> Unfortunately, unless this is remedied we will be forced to stick with
> Maven 1 as the only alternative I can think of is to have our
> configuration management folks modify every pom in our local repository
> (our copy of ibiblio) to remove all the dependency versions.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
Eric Redmond said:
> On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>>
>>
>> If this is truly the way it works than it certainly can't be claimed
>> that Maven supports transitive dependencies as they will almost always
>> have to be bypassed. For example, if project A includes myfaces 1.1.1 it
>> has dependencies on beanutils 1.7.0 and digester 1.7.0. What is
>> interesting is that digester 1.7.0 specifies a dependency of beanutils
>> 1.6.0. Now presumably, myfaces specification will override digesters.
>> But now, what if project A also specifies digester 1.7.0 as a
>> dependency? You will end up with both beanutils 1.6.0 and beanutils
>> 1.7.0 in your build target, which is completely unacceptable. The
>> solution is for us to scour the pom's we are using and then look at
>> their dependencies, etc.? I don't thnik so. Instead, everyone will be
>> forced to declare all their dependencies in the parent pom.
>
>
> If that's your problem, you're going to have that issue anyway, no matter
> what build system you are using. Maven manages builds, its not a magic
> project-hierarchy fixer. In any case, for an extention which DOES do what
> you are asking, check out pomstrap:
>
> http://pomstrap.tigris.org/
>
> Eric
>
Thanks, Eric. That project looks interesting and possibly simpler than OSGi.
Versioning is definitely one of the sore spots in Java. However, we
aren't looking for Maven to be a "magic project-hierarchy fixer". I think
that simply having the behavior of the jar override feature of Maven 1
combined with transitive dependencies in Maven 2 would be enough. It is
simply a matter of where the control lies in choosing versions. We
believe it needs to be at a global (i.e. corporate wide) scope. Changes
to versions of third party jars always start with our lowest level
framework compoents and percolate their way up.
As I said, Maven could even emit Warnings when it detects that the version
specified in dependencyManagement is less than the version in the actual
dependency. This simply provides a way for our Configuration Management
folks to know that every in-house project was built and tested with the
exact same components along the way before they were combined into the
delievered product, which is also using those versions.
Frankly, I just don't understand why there is reluctance to provide a
feature that folks were happy with in Maven 1.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Eric Redmond <er...@gmail.com>.
On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>
> Steve,
>
> What you are proposing is to basically bypass maven and "hack" the pom's
> dynamically with the versions required. It seems to me it would be
> easier to have a process to do that in one's local repository. Then you
> only have to do it once. But then you don't have a real copy of what is
> at ibiblio.
>
> If this is truly the way it works than it certainly can't be claimed
> that Maven supports transitive dependencies as they will almost always
> have to be bypassed. For example, if project A includes myfaces 1.1.1 it
> has dependencies on beanutils 1.7.0 and digester 1.7.0. What is
> interesting is that digester 1.7.0 specifies a dependency of beanutils
> 1.6.0. Now presumably, myfaces specification will override digesters.
> But now, what if project A also specifies digester 1.7.0 as a
> dependency? You will end up with both beanutils 1.6.0 and beanutils
> 1.7.0 in your build target, which is completely unacceptable. The
> solution is for us to scour the pom's we are using and then look at
> their dependencies, etc.? I don't thnik so. Instead, everyone will be
> forced to declare all their dependencies in the parent pom.
If that's your problem, you're going to have that issue anyway, no matter
what build system you are using. Maven manages builds, its not a magic
project-hierarchy fixer. In any case, for an extention which DOES do what
you are asking, check out pomstrap:
http://pomstrap.tigris.org/
Eric
I will admit that at the moment few folks are going to run into this
> problem because 1) most maven users are still on maven 1 and 2) most
> poms at ibiblio don't specify dependencies (I would imagine this is
> incorrect). But it only took me 5 minutes of searching to come up with
> the problem above.
>
> In which case, I have to wonder why I would ever want to go through the
> effort of rewrting all my maven 1 plugins since I won't be getting any
> benefit.
>
> Ralph
>
> Steve Loughran wrote:
> > Ralph Goers wrote:
> >> If I read you right, then I have to treat Maven 2 as if it is Maven 1
> >> and self-discover what all my project's runtime dependencies are
> >> going to be?
> >> Our configuration management dept requires that all our projects use
> >> the same versions of xerces, xalan, etc. This is controlled via the
> >> build.properties file. Putting it in each project's POM still leads
> >> to the possibility that other projects will use different versions.
> >>
> >> So it sounds like I have to have a dependencyManagement section in a
> >> master pom and then each project has to specify all its dependencies
> >> and this will then cause the versions specified in transitive
> >> dependencies not to be used?
> >> Ralph
> >
> > Its an interesting problem. The goal of the maven2 team is,
> > presumably, to have pom files that contain everything you need to know
> > about versions.
> >
> > Personally (and this is under Ant), I tend to create the .pom files on
> > the fly from my templates, using the <echoxml> command to generate the
> > file inline, after loading in all versions. Its kind of messy, but it
> > works. Sounds like maybe you need something similar for m2, something
> > to take a stub .pom file and expand its properties to create the pom
> > file used for that particular build, a kind of preprocessor...
> >
> > -steve
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: dependencyManagement
Posted by Jason van Zyl <ja...@maven.org>.
On 15 Sep 06, at 4:06 PM 15 Sep 06, Ralph Goers wrote:
> OK. Could someone apply the patch I provided for http://
> jira.codehaus.org/browse/MNG-1577 and verify it?
>
If you add tests I will apply it. I don't have time to check it and
verify it right now. A test would expedite the review of this patch.
> Ralph
>
>
> Carlos Sanchez wrote:
>> Is not that we don't want to see that fixed, but we're very busy. A
>> patch would help to get it solved earlier.
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Jason van Zyl
jason@maven.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
OK. Could someone apply the patch I provided for http://jira.codehaus.org/browse/MNG-1577 and verify it?
Ralph
Carlos Sanchez wrote:
> Is not that we don't want to see that fixed, but we're very busy. A
> patch would help to get it solved earlier.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Carlos Sanchez <ca...@apache.org>.
Is not that we don't want to see that fixed, but we're very busy. A
patch would help to get it solved earlier.
On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> OK. Thanks for the info. But until
> http://jira.codehaus.org/browse/MNG-1577 is fixed I'm afraid I will have
> to stick with Maven 1.0.2. FWIW, the vote count on that issue has gone
> from 3 to 8 since I started this thread yesterday. I guarantee it will
> go much higher.
>
> Carlos Sanchez wrote:
> > You don't have guarantee of wich one will be chosen, althoug it will
> > be always the same.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
OK. Thanks for the info. But until
http://jira.codehaus.org/browse/MNG-1577 is fixed I'm afraid I will have
to stick with Maven 1.0.2. FWIW, the vote count on that issue has gone
from 3 to 8 since I started this thread yesterday. I guarantee it will
go much higher.
Carlos Sanchez wrote:
> You don't have guarantee of wich one will be chosen, althoug it will
> be always the same.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Carlos Sanchez <ca...@apache.org>.
You don't have guarantee of wich one will be chosen, althoug it will
be always the same.
On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> And if A -> B -> D1.0 and
> -> C -> D2.0
> who wins?
>
>
> Carlos Sanchez said:
> > No, closest in the dependency graph means that the deepest dep is
> > overriden
> >
> > If A -> B -> C1.0 and A -> C2.0
> > then C2.0 wins because id closer to your project (A)
> >
> > On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> >> Carlos Sanchez said:
> >> > To be clear:
> >> > You never have two artifacts in the classpath with same
> >> > groupId:artifactId, maven uses the "nearer" version always, which is
> >> > the one closest to your project in the transitive dependency graph,
> >> > not the most recent version.
> >>
> >> Is that the same as saying it uses the first one it happens to run
> >> across?
> >> If dependencies are reordered in the parent could that cause a change
> >> in
> >> which version is used?
> >>
> >> Of course, this can't guarantee that two projects built separately with
> >> maven will actually use the same dependencies, which is really where the
> >> problem stems from.
> >>
> >> Ralph
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> > -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
And if A -> B -> D1.0 and
-> C -> D2.0
who wins?
Carlos Sanchez said:
> No, closest in the dependency graph means that the deepest dep is
> overriden
>
> If A -> B -> C1.0 and A -> C2.0
> then C2.0 wins because id closer to your project (A)
>
> On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
>> Carlos Sanchez said:
>> > To be clear:
>> > You never have two artifacts in the classpath with same
>> > groupId:artifactId, maven uses the "nearer" version always, which is
>> > the one closest to your project in the transitive dependency graph,
>> > not the most recent version.
>>
>> Is that the same as saying it uses the first one it happens to run
>> across?
>> If dependencies are reordered in the parent could that cause a change
>> in
>> which version is used?
>>
>> Of course, this can't guarantee that two projects built separately with
>> maven will actually use the same dependencies, which is really where the
>> problem stems from.
>>
>> Ralph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Carlos Sanchez <ca...@apache.org>.
No, closest in the dependency graph means that the deepest dep is overriden
If A -> B -> C1.0 and A -> C2.0
then C2.0 wins because id closer to your project (A)
On 2/28/06, Ralph Goers <Ra...@dslextreme.com> wrote:
> Carlos Sanchez said:
> > To be clear:
> > You never have two artifacts in the classpath with same
> > groupId:artifactId, maven uses the "nearer" version always, which is
> > the one closest to your project in the transitive dependency graph,
> > not the most recent version.
>
> Is that the same as saying it uses the first one it happens to run across?
> If dependencies are reordered in the parent could that cause a change in
> which version is used?
>
> Of course, this can't guarantee that two projects built separately with
> maven will actually use the same dependencies, which is really where the
> problem stems from.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carlos Sanchez said:
> To be clear:
> You never have two artifacts in the classpath with same
> groupId:artifactId, maven uses the "nearer" version always, which is
> the one closest to your project in the transitive dependency graph,
> not the most recent version.
Is that the same as saying it uses the first one it happens to run across?
If dependencies are reordered in the parent could that cause a change in
which version is used?
Of course, this can't guarantee that two projects built separately with
maven will actually use the same dependencies, which is really where the
problem stems from.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Carlos Sanchez <ca...@apache.org>.
To be clear:
You never have two artifacts in the classpath with same
groupId:artifactId, maven uses the "nearer" version always, which is
the one closest to your project in the transitive dependency graph,
not the most recent version.
On 2/28/06, Steve Loughran <st...@apache.org> wrote:
> Ralph Goers wrote:
> > Steve,
> >
> > What you are proposing is to basically bypass maven and "hack" the pom's
> > dynamically with the versions required. It seems to me it would be
> > easier to have a process to do that in one's local repository. Then you
> > only have to do it once. But then you don't have a real copy of what is
> > at ibiblio.
>
> No. I have a properties file that lays down the dependencies for
> everything in my project, like log4j, across
> about 20 different sub projects.
>
> These have template pom files that hard code what they depend on, but
> the actual version of what they depend on is driven by my
> libraries.properties files. At build time, the templates are filled in
> to actual pom files, files that declare what they were compiled against.
> These are the pom files that are redistributed.
>
>
>
> >
> > If this is truly the way it works than it certainly can't be claimed
> > that Maven supports transitive dependencies as they will almost always
> > have to be bypassed. For example, if project A includes myfaces 1.1.1 it
> > has dependencies on beanutils 1.7.0 and digester 1.7.0. What is
> > interesting is that digester 1.7.0 specifies a dependency of beanutils
> > 1.6.0. Now presumably, myfaces specification will override digesters.
> > But now, what if project A also specifies digester 1.7.0 as a
> > dependency? You will end up with both beanutils 1.6.0 and beanutils
> > 1.7.0 in your build target, which is completely unacceptable. The
> > solution is for us to scour the pom's we are using and then look at
> > their dependencies, etc.? I don't thnik so. Instead, everyone will be
> > forced to declare all their dependencies in the parent pom.
>
> Well, I only really declare dependencies on things I care about, and let
> the rest sort it out for themselves. If I cared about everything, then
> yes, it would require things at the top to declare their versions.
>
> This example is slightly wrong though: you should end up with
> beanutils1.7.0 on the path, but not 1.6.0. M2 doesnt give you two
> versions of the same (Group,artifact), it gives you whichever is of the
> highest version and hopes they are backwards compatible. Do a build in
> -verbose to see what is going on. Certainly in my builds I see traces like
>
> [m2-libraries] Resolving dependencies...
> unspecified:unspecified:jar:0.0 (selected)
> xerces:xmlParserAPIs:jar:2.6.2 (selected)
> xom:xom:jar:1.1 (selected)
> xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
> jaxen:jaxen:jar:1.1-beta-8 (selected)
> jaxen:jaxen:jar:1.0-FCS (removed - causes a cycle in the graph)
> jdom:jdom:jar:1.0 (selected)
> xalan:xalan:jar:2.5.0 (selected)
> xerces:xmlParserAPIs:jar:2.6.2 (removed - nearer found: 2.6.2)
> xerces:xercesImpl:jar:2.6.2 (selected)
> xalan:xalan:jar:2.7.0 (selected)
>
> Actually, looking that this I see that two copies of xalan appear to be
> selected. not good. I will need to look at this more closely.
>
>
> > I will admit that at the moment few folks are going to run into this
> > problem because 1) most maven users are still on maven 1 and 2) most
> > poms at ibiblio don't specify dependencies (I would imagine this is
> > incorrect). But it only took me 5 minutes of searching to come up with
> > the problem above.
>
> Its part of a broader problem of versioning, which, IMO, is one of the
> big hard problems of computer science (nothing gets it right; at least
> in java its easier to link against later builds)
>
> The issue here is: who declares what you run against, and how
>
> Maven1 and ant say "work it out for yourself"
>
> Maven2 says "libraries pull in what they were built against, unless you
> say otherwise"
>
> Now, I have mixed feelings about how well it works --the primary problem
> I have is not version conflict but unwanted dependencies; you ask for
> one thing and before you know it you have three XML parsers and a copy
> of junit3.7 on your classpath. You are left with pom overrides that
> declare what you don't want.
>
> But is this actually worse than what went before? Different, yes, but
> worse, I'd argue not.
>
> In smartfrog (http://smartfrog.org/) we have components that will pull
> stuff into the repository. But I completely skipped the transient stuff,
> partly because it was complex, and partly because I felt that at
> deployment time you should be explicit, and all your dependencies can
> live under SCM. Also, for security, you get to declare the sha1 or md5
> checksum, though there is a problem there once you start signing JAR
> files (it changes the checksum, see)
>
> The result is you do have to list what you want, but you can use the
> inheritance model of .sf descriptors to stop retyping things. This, for
> example, is the descriptor to run axis tcpmonitor.
>
> sfConfig extends Compound {
>
> library extends Maven2Library {
> }
>
> commons-logging extends JarArtifact {
> library LAZY PARENT:library;
> project "commons-logging";
> version "1.0.4";
> sha1 "f029a2aefe2b3e1517573c580f948caac31b1056";
> }
>
> axis extends JarArtifact {
> library LAZY PARENT:library;
> project "axis";
> artifact "axis";
> version "1.1";
> sha1 "edd84c96eac48d4167bca4f45e7d36dcf36cf871";
> }
>
>
> tcpmonitor extends Java {
> classname "org.apache.axis.utils.tcpmon";
> classpath [
> LAZY axis:absolutePath,
> LAZY commons-logging:absolutePath];
> }
>
> }
>
> -Steve
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
Steve Loughran wrote:
> No. I have a properties file that lays down the dependencies for
> everything in my project, like log4j, across
> about 20 different sub projects.
>
> These have template pom files that hard code what they depend on, but
> the actual version of what they depend on is driven by my
> libraries.properties files. At build time, the templates are filled in
> to actual pom files, files that declare what they were compiled
> against. These are the pom files that are redistributed.
This still sounds like I have to have modified versions of poms at ibiblio.
>
>
> Actually, looking that this I see that two copies of xalan appear to
> be selected. not good. I will need to look at this more closely.
>
>
>> I will admit that at the moment few folks are going to run into this
>> problem because 1) most maven users are still on maven 1 and 2) most
>> poms at ibiblio don't specify dependencies (I would imagine this is
>> incorrect). But it only took me 5 minutes of searching to come up
>> with the problem above.
>
> Its part of a broader problem of versioning, which, IMO, is one of the
> big hard problems of computer science (nothing gets it right; at least
> in java its easier to link against later builds)
>
> The issue here is: who declares what you run against, and how
>
> Maven1 and ant say "work it out for yourself"
At least with maven 1 we can control this with maven.jar.override. This
capability has been removed in Maven 2.
>
> Maven2 says "libraries pull in what they were built against, unless
> you say otherwise"
Which is OK, if you have a rational way to say otherwise. The
"rational" way is to have a global list of the versions you want to use
wherever they appear in the build. This can actually be a good feature
as Maven could generate warnings when a transitive dependency is greater
than the one declared. It also doesn't require that you actually know
where they are used which aids in simplicity.
>
> Now, I have mixed feelings about how well it works --the primary
> problem I have is not version conflict but unwanted dependencies; you
> ask for one thing and before you know it you have three XML parsers
> and a copy of junit3.7 on your classpath. You are left with pom
> overrides that declare what you don't want.
I would suggest that if you have a POM where you can exclude something
and it still works has a problem. It is nice that Maven lets you bypass
it, but you should take that up with the author of the POM.
>
> But is this actually worse than what went before? Different, yes, but
> worse, I'd argue not.
>
> In smartfrog (http://smartfrog.org/) we have components that will pull
> stuff into the repository. But I completely skipped the transient
> stuff, partly because it was complex, and partly because I felt that
> at deployment time you should be explicit, and all your dependencies
> can live under SCM. Also, for security, you get to declare the sha1 or
> md5 checksum, though there is a problem there once you start signing
> JAR files (it changes the checksum, see)
>
> The result is you do have to list what you want, but you can use the
> inheritance model of .sf descriptors to stop retyping things. This,
> for example, is the descriptor to run axis tcpmonitor.
>
> sfConfig extends Compound {
>
> library extends Maven2Library {
> }
>
> commons-logging extends JarArtifact {
> library LAZY PARENT:library;
> project "commons-logging";
> version "1.0.4";
> sha1 "f029a2aefe2b3e1517573c580f948caac31b1056";
> }
>
> axis extends JarArtifact {
> library LAZY PARENT:library;
> project "axis";
> artifact "axis";
> version "1.1";
> sha1 "edd84c96eac48d4167bca4f45e7d36dcf36cf871";
> }
>
>
> tcpmonitor extends Java {
> classname "org.apache.axis.utils.tcpmon";
> classpath [
> LAZY axis:absolutePath,
> LAZY commons-logging:absolutePath];
> }
>
> }
>
> -Steve
Well, I suppose if it works for you... but that seems like an awful lot
of work to create a usable build system.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Steve Loughran <st...@apache.org>.
Ralph Goers wrote:
> Steve,
>
> What you are proposing is to basically bypass maven and "hack" the pom's
> dynamically with the versions required. It seems to me it would be
> easier to have a process to do that in one's local repository. Then you
> only have to do it once. But then you don't have a real copy of what is
> at ibiblio.
No. I have a properties file that lays down the dependencies for
everything in my project, like log4j, across
about 20 different sub projects.
These have template pom files that hard code what they depend on, but
the actual version of what they depend on is driven by my
libraries.properties files. At build time, the templates are filled in
to actual pom files, files that declare what they were compiled against.
These are the pom files that are redistributed.
>
> If this is truly the way it works than it certainly can't be claimed
> that Maven supports transitive dependencies as they will almost always
> have to be bypassed. For example, if project A includes myfaces 1.1.1 it
> has dependencies on beanutils 1.7.0 and digester 1.7.0. What is
> interesting is that digester 1.7.0 specifies a dependency of beanutils
> 1.6.0. Now presumably, myfaces specification will override digesters.
> But now, what if project A also specifies digester 1.7.0 as a
> dependency? You will end up with both beanutils 1.6.0 and beanutils
> 1.7.0 in your build target, which is completely unacceptable. The
> solution is for us to scour the pom's we are using and then look at
> their dependencies, etc.? I don't thnik so. Instead, everyone will be
> forced to declare all their dependencies in the parent pom.
Well, I only really declare dependencies on things I care about, and let
the rest sort it out for themselves. If I cared about everything, then
yes, it would require things at the top to declare their versions.
This example is slightly wrong though: you should end up with
beanutils1.7.0 on the path, but not 1.6.0. M2 doesnt give you two
versions of the same (Group,artifact), it gives you whichever is of the
highest version and hopes they are backwards compatible. Do a build in
-verbose to see what is going on. Certainly in my builds I see traces like
[m2-libraries] Resolving dependencies...
unspecified:unspecified:jar:0.0 (selected)
xerces:xmlParserAPIs:jar:2.6.2 (selected)
xom:xom:jar:1.1 (selected)
xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
jaxen:jaxen:jar:1.1-beta-8 (selected)
jaxen:jaxen:jar:1.0-FCS (removed - causes a cycle in the graph)
jdom:jdom:jar:1.0 (selected)
xalan:xalan:jar:2.5.0 (selected)
xerces:xmlParserAPIs:jar:2.6.2 (removed - nearer found: 2.6.2)
xerces:xercesImpl:jar:2.6.2 (selected)
xalan:xalan:jar:2.7.0 (selected)
Actually, looking that this I see that two copies of xalan appear to be
selected. not good. I will need to look at this more closely.
> I will admit that at the moment few folks are going to run into this
> problem because 1) most maven users are still on maven 1 and 2) most
> poms at ibiblio don't specify dependencies (I would imagine this is
> incorrect). But it only took me 5 minutes of searching to come up with
> the problem above.
Its part of a broader problem of versioning, which, IMO, is one of the
big hard problems of computer science (nothing gets it right; at least
in java its easier to link against later builds)
The issue here is: who declares what you run against, and how
Maven1 and ant say "work it out for yourself"
Maven2 says "libraries pull in what they were built against, unless you
say otherwise"
Now, I have mixed feelings about how well it works --the primary problem
I have is not version conflict but unwanted dependencies; you ask for
one thing and before you know it you have three XML parsers and a copy
of junit3.7 on your classpath. You are left with pom overrides that
declare what you don't want.
But is this actually worse than what went before? Different, yes, but
worse, I'd argue not.
In smartfrog (http://smartfrog.org/) we have components that will pull
stuff into the repository. But I completely skipped the transient stuff,
partly because it was complex, and partly because I felt that at
deployment time you should be explicit, and all your dependencies can
live under SCM. Also, for security, you get to declare the sha1 or md5
checksum, though there is a problem there once you start signing JAR
files (it changes the checksum, see)
The result is you do have to list what you want, but you can use the
inheritance model of .sf descriptors to stop retyping things. This, for
example, is the descriptor to run axis tcpmonitor.
sfConfig extends Compound {
library extends Maven2Library {
}
commons-logging extends JarArtifact {
library LAZY PARENT:library;
project "commons-logging";
version "1.0.4";
sha1 "f029a2aefe2b3e1517573c580f948caac31b1056";
}
axis extends JarArtifact {
library LAZY PARENT:library;
project "axis";
artifact "axis";
version "1.1";
sha1 "edd84c96eac48d4167bca4f45e7d36dcf36cf871";
}
tcpmonitor extends Java {
classname "org.apache.axis.utils.tcpmon";
classpath [
LAZY axis:absolutePath,
LAZY commons-logging:absolutePath];
}
}
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
Steve,
What you are proposing is to basically bypass maven and "hack" the pom's
dynamically with the versions required. It seems to me it would be
easier to have a process to do that in one's local repository. Then you
only have to do it once. But then you don't have a real copy of what is
at ibiblio.
If this is truly the way it works than it certainly can't be claimed
that Maven supports transitive dependencies as they will almost always
have to be bypassed. For example, if project A includes myfaces 1.1.1 it
has dependencies on beanutils 1.7.0 and digester 1.7.0. What is
interesting is that digester 1.7.0 specifies a dependency of beanutils
1.6.0. Now presumably, myfaces specification will override digesters.
But now, what if project A also specifies digester 1.7.0 as a
dependency? You will end up with both beanutils 1.6.0 and beanutils
1.7.0 in your build target, which is completely unacceptable. The
solution is for us to scour the pom's we are using and then look at
their dependencies, etc.? I don't thnik so. Instead, everyone will be
forced to declare all their dependencies in the parent pom.
I will admit that at the moment few folks are going to run into this
problem because 1) most maven users are still on maven 1 and 2) most
poms at ibiblio don't specify dependencies (I would imagine this is
incorrect). But it only took me 5 minutes of searching to come up with
the problem above.
In which case, I have to wonder why I would ever want to go through the
effort of rewrting all my maven 1 plugins since I won't be getting any
benefit.
Ralph
Steve Loughran wrote:
> Ralph Goers wrote:
>> If I read you right, then I have to treat Maven 2 as if it is Maven 1
>> and self-discover what all my project's runtime dependencies are
>> going to be?
>> Our configuration management dept requires that all our projects use
>> the same versions of xerces, xalan, etc. This is controlled via the
>> build.properties file. Putting it in each project's POM still leads
>> to the possibility that other projects will use different versions.
>>
>> So it sounds like I have to have a dependencyManagement section in a
>> master pom and then each project has to specify all its dependencies
>> and this will then cause the versions specified in transitive
>> dependencies not to be used?
>> Ralph
>
> Its an interesting problem. The goal of the maven2 team is,
> presumably, to have pom files that contain everything you need to know
> about versions.
>
> Personally (and this is under Ant), I tend to create the .pom files on
> the fly from my templates, using the <echoxml> command to generate the
> file inline, after loading in all versions. Its kind of messy, but it
> works. Sounds like maybe you need something similar for m2, something
> to take a stub .pom file and expand its properties to create the pom
> file used for that particular build, a kind of preprocessor...
>
> -steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Steve Loughran <st...@apache.org>.
Ralph Goers wrote:
> If I read you right, then I have to treat Maven 2 as if it is Maven 1
> and self-discover what all my project's runtime dependencies are going
> to be?
> Our configuration management dept requires that all our projects use the
> same versions of xerces, xalan, etc. This is controlled via the
> build.properties file. Putting it in each project's POM still leads to
> the possibility that other projects will use different versions.
>
> So it sounds like I have to have a dependencyManagement section in a
> master pom and then each project has to specify all its dependencies and
> this will then cause the versions specified in transitive dependencies
> not to be used?
> Ralph
Its an interesting problem. The goal of the maven2 team is, presumably,
to have pom files that contain everything you need to know about versions.
Personally (and this is under Ant), I tend to create the .pom files on
the fly from my templates, using the <echoxml> command to generate the
file inline, after loading in all versions. Its kind of messy, but it
works. Sounds like maybe you need something similar for m2, something to
take a stub .pom file and expand its properties to create the pom file
used for that particular build, a kind of preprocessor...
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Ralph Goers <Ra...@dslextreme.com>.
If I read you right, then I have to treat Maven 2 as if it is Maven 1
and self-discover what all my project's runtime dependencies are going
to be?
Our configuration management dept requires that all our projects use the
same versions of xerces, xalan, etc. This is controlled via the
build.properties file. Putting it in each project's POM still leads to
the possibility that other projects will use different versions.
So it sounds like I have to have a dependencyManagement section in a
master pom and then each project has to specify all its dependencies and
this will then cause the versions specified in transitive dependencies
not to be used?
Ralph
Brett Porter wrote:
> Just put the dependency in your own POM when you need to force that
> version, and the dependency management will be applied.
>
> The dependency management is not applied to transitive dependencies, but
> removing the version in the repository won't change that (they'd just
> fail instead).
>
> - Brett
>
> Ralph Goers wrote:
>
>> We have been using Maven 1 for all our projects. We have a master
>> build.properties file that contains the version of every dependency we
>> use throughout all of our projects.
>> I am now attempting to build a project using maven 2 and was having some
>> success. I then came across
>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
>> This looked great until I happened upon
>> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2
>> <http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2>.
>> Unfortunately, this is exactly the wrong behavior for anyone moving from
>> version 1 to version 2. Furthermore, unless the repository at ibiblio
>> is going to be modified to remove the versions from the dependencies
>> there then this is also the incorrect default behavior for anyone -
>> unless everyone is forced to disable transitive dependencies.
>>
>> Without this control projects will very quickly have multiple versions
>> of jars.
>>
>> So am I missing something? Is there another configuration item that can
>> be specified on a dependency in the dependencyManagement section to
>> cause it to override child poms?
>>
>> Unfortunately, unless this is remedied we will be forced to stick with
>> Maven 1 as the only alternative I can think of is to have our
>> configuration management folks modify every pom in our local repository
>> (our copy of ibiblio) to remove all the dependency versions.
>>
>> Ralph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dependencyManagement
Posted by Brett Porter <br...@apache.org>.
Just put the dependency in your own POM when you need to force that
version, and the dependency management will be applied.
The dependency management is not applied to transitive dependencies, but
removing the version in the repository won't change that (they'd just
fail instead).
- Brett
Ralph Goers wrote:
> We have been using Maven 1 for all our projects. We have a master
> build.properties file that contains the version of every dependency we
> use throughout all of our projects.
> I am now attempting to build a project using maven 2 and was having some
> success. I then came across
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html.
> This looked great until I happened upon
> http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2
> <http://marc.theaimsgroup.com/?l=turbine-maven-user&m=113656701325017&w=2>.
> Unfortunately, this is exactly the wrong behavior for anyone moving from
> version 1 to version 2. Furthermore, unless the repository at ibiblio
> is going to be modified to remove the versions from the dependencies
> there then this is also the incorrect default behavior for anyone -
> unless everyone is forced to disable transitive dependencies.
>
> Without this control projects will very quickly have multiple versions
> of jars.
>
> So am I missing something? Is there another configuration item that can
> be specified on a dependency in the dependencyManagement section to
> cause it to override child poms?
>
> Unfortunately, unless this is remedied we will be forced to stick with
> Maven 1 as the only alternative I can think of is to have our
> configuration management folks modify every pom in our local repository
> (our copy of ibiblio) to remove all the dependency versions.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org