You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "John J. Franey" <jj...@verizon.net> on 2007/03/02 16:36:52 UTC

Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)


Wayne Fay wrote:
> 
> Did you use the [...] notation in your versions?
> 

The question I asked myself was "Why is the '[...]' notation important?". 
So I went to Better Builds with Maven (pdf) and found this in section 3.6:



> When a version is declared as 1.1, as shown above for plexus-utils, this
> indicates that the
> preferred version of the dependency is 1.1, but that other versions may be
> acceptable. 
> 

Combiningg Wayne's helpful contribution with the above, I understand why. 
Without the [...] notation, maven is free to choose whatever version.  With
the [...] notation, maven is bound to that version (or versions, if the
[...] specifies a range).

Thanks,
John


-- 
View this message in context: http://www.nabble.com/Transitive-Dependency-resolution-is-degrading-the-versions-of-my-dependencies-%28i.e.-commons-collections-3.2-down-to-2.1%29-tf3331410s177.html#a9271647
Sent from the Maven - Users mailing list archive at Nabble.com.


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


Deploy exported-pom.xml with deploy plugin

Posted by Niels Gylling <ng...@it-practice.dk>.
I would like to release my pom info with resolved version info etc to 
our shared repository.


When I install an artifact, the exported-pom.xml file is generated - 
possibly if updateReleaseInfo is set to true.

Now if I perform a deploy also with the same parameter set, the pom 
deployed to the shared repository is not released, ie. contains varibles 
and reference to parent pom etc.

I would like this to happen as we have several parallel versions of the 
same artifact, and version number of dependencies are fetched from a 
parent pom - and I would hate to change the parent pom between the 
parallel versions.


Now I could override the deploy plugin to suit me, but still..

Lookin at deploy-plugin source, it looks like an issue with the deploy 
component.

(Still running maven 2.0.4)

/Niels

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


Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by Rémy Sanlaville <re...@gmail.com>.
2007/3/2, Trevor Torrez <ja...@gmail.com>:
>
> > [snip]
> > Before reading that what did you think something like:
> >
> > <version>1.0</version>
> >
> > meant?
> >
> > I'm actually interested in what general user opinion is here.
> >
> > Jason.
>
>
>
> I thought it meant "1.0" (period).


So do I  !
Isn't what the Better Build with Maven book explain ?

Rémy

Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by Trevor Torrez <ja...@gmail.com>.
> [snip]
> Before reading that what did you think something like:
>
> <version>1.0</version>
>
> meant?
>
> I'm actually interested in what general user opinion is here.
>
> Jason.



I thought it meant "1.0" (period).

Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by Jason van Zyl <ja...@maven.org>.
On 3 Mar 07, at 10:29 AM 3 Mar 07, Wendy Smoak wrote:

> On 3/2/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> Before reading that what did you think something like:
>> <version>1.0</version>
>> meant?
>> I'm actually interested in what general user opinion is here.
>
> I suppose I've never reconciled how I thought it ought to work, with
> the actual behavior of "nearest" in the directed graph

It's not a graph unfortunately which is a fundamental mistake in the  
current artifact mechanism. It needs to changed to have the graph be  
a first class citizens. No reliable transformation can occur without  
a graph.

> (which I like)
> coupled with the unpredictable things that would happen with
> dependencyManagement + transitivity.  (Fixed in 2.0.5?)

MNG-1577 is not fixed. For 2.0.6.

>
> But how does this change things?  If I declare a dependency on 1.0 and
> something two levels out declares [2.0], what do I get in my webapp?

Try it but according to what's documented it would cause a problem.  
Because the only version that could be used is [2.0], if many  
dependencies used hard versions then you are fundamentally screwed.  
This is why the soft versions are the default and it wiggles around.

> Does [...] syntax allow transitive dependencies to override my
> choices?  If everyone switches to [...] then are we back where we
> started with "nearest" ?

Well, anything down stream that uses hard versions will require  
everything else to include that hard version in the range or it will  
fail according to the rules.

The actual calculations to find suitable ranges requires a graph,  
walking down branches and sometimes back tracking and throwing  
results away. I've been looking at how Gentoo/RPM/OSGi calculate  
ranges and we need something similar. We need to seriously rethink  
what we have for artifact resolution.

>
> -- 
> Wendy
>
> ---------------------------------------------------------------------
> 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: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by Scott Ryan <sc...@theryansplace.com>.
I actually thought that

<version>1.0</version>
meant that I was getting 1.0 of the artifact but if something else  
needed a newer version then I would get that.

The problem with nearness is that you have to understand every  
dependency tree for every dependency you use.  It could be as in our  
case that 7 layers deep into the tree far far from our code there is  
an issue that is causing this downgrading.  The issue we have is that  
we are using Jasper Reports as well as an open source persistence  
frameworks and somewhere down in the guts of those dependencies they  
are walking on each other.  The fix is for me to go into all those  
projects and figure out what is going on and fix them in my pom.xml.   
This is "ok" however I don't see the problem until run time when I  
access those frameworks and they die.  We ran for several days until  
someone actually produced a chart and the system died.

I actually think that frameworks should not be using the [ notation  
cause that is what is causing the null pointer when we include Jasper  
and there is no way to override it without mucking in their pom.

I guess bottom line is we need a best practices document for  
frameworks developers like apache  commons and users like me so that  
there is a predictable system in place with no mystery as to what we  
are getting.

Scott

On Mar 3, 2007, at 8:29 AM, Wendy Smoak wrote:

> On 3/2/07, Jason van Zyl <ja...@maven.org> wrote:
>
>> Before reading that what did you think something like:
>> <version>1.0</version>
>> meant?
>> I'm actually interested in what general user opinion is here.
>
> I suppose I've never reconciled how I thought it ought to work, with
> the actual behavior of "nearest" in the directed graph (which I like)
> coupled with the unpredictable things that would happen with
> dependencyManagement + transitivity.  (Fixed in 2.0.5?)
>
> But how does this change things?  If I declare a dependency on 1.0 and
> something two levels out declares [2.0], what do I get in my webapp?
> Does [...] syntax allow transitive dependencies to override my
> choices?  If everyone switches to [...] then are we back where we
> started with "nearest" ?
>
> -- 
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
scott@theryansplace.com



Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by Wendy Smoak <ws...@gmail.com>.
On 3/2/07, Jason van Zyl <ja...@maven.org> wrote:

> Before reading that what did you think something like:
> <version>1.0</version>
> meant?
> I'm actually interested in what general user opinion is here.

I suppose I've never reconciled how I thought it ought to work, with
the actual behavior of "nearest" in the directed graph (which I like)
coupled with the unpredictable things that would happen with
dependencyManagement + transitivity.  (Fixed in 2.0.5?)

But how does this change things?  If I declare a dependency on 1.0 and
something two levels out declares [2.0], what do I get in my webapp?
Does [...] syntax allow transitive dependencies to override my
choices?  If everyone switches to [...] then are we back where we
started with "nearest" ?

-- 
Wendy

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


Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by "John J. Franey" <jj...@verizon.net>.

Jason van Zyl-2 wrote:
> 
> 
> On 2 Mar 07, at 10:36 AM 2 Mar 07, John J. Franey wrote:
> 
> 
>>
>>
>> From Better Builds with Maven:
>>
>>> When a version is declared as 1.1, as shown above for plexus- 
>>> utils, this
>>> indicates that the
>>> preferred version of the dependency is 1.1, but that other  
>>> versions may be
>>> acceptable.
>>>
> 
> 
> Before reading that what did you think something like:
> 
> <version>1.0</version>
> 
> meant?
> 
> I'm actually interested in what general user opinion is here.
> 
> Jason.
> 
> 
> 


It didn't occur to me that it could mean anything other than what it says:
The project has a dependency on 1.0 (period).  I guess I inferred that
dependency/version would have equivalent semantic as project/dependency. 
There is no wiggle in project/version, of course; it is what it is.   And so
my unchallenged guess was that dependency/version is what it is and no
deeper.  Unchallenged until now: 3 months into converting ~9 ant projects to
maven, total of ~150k LOC.  Yikes.

John




-- 
View this message in context: http://www.nabble.com/Transitive-Dependency-resolution-is-degrading-the-versions-of-my-dependencies-%28i.e.-commons-collections-3.2-down-to-2.1%29-tf3331410s177.html#a9275180
Sent from the Maven - Users mailing list archive at Nabble.com.


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


Re: [m2] Transitive Dependency resolution is degrading the versions of my dependencies (i.e. commons-collections 3.2 down to 2.1)

Posted by Jason van Zyl <ja...@maven.org>.
On 2 Mar 07, at 10:36 AM 2 Mar 07, John J. Franey wrote:

>
>
> Wayne Fay wrote:
>>
>> Did you use the [...] notation in your versions?
>>
>
> The question I asked myself was "Why is the '[...]' notation  
> important?".
> So I went to Better Builds with Maven (pdf) and found this in  
> section 3.6:
>
>
>
>> When a version is declared as 1.1, as shown above for plexus- 
>> utils, this
>> indicates that the
>> preferred version of the dependency is 1.1, but that other  
>> versions may be
>> acceptable.
>>
>
> Combiningg Wayne's helpful contribution with the above, I  
> understand why.
> Without the [...] notation, maven is free to choose whatever  
> version.  With
> the [...] notation, maven is bound to that version (or versions, if  
> the
> [...] specifies a range).
>

Before reading that what did you think something like:

<version>1.0</version>

meant?

I'm actually interested in what general user opinion is here.

Jason.

> Thanks,
> John
>
>
> -- 
> View this message in context: http://www.nabble.com/Transitive- 
> Dependency-resolution-is-degrading-the-versions-of-my-dependencies-% 
> 28i.e.-commons-collections-3.2-down-to-2.1%29- 
> tf3331410s177.html#a9271647
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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