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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Scott Ryan
CTO Soaring Eagle L.L.C.
Denver, Co. 80129
www.soaringeagleco.com
www.theryansplace.com
(303) 263-3044
[EMAIL PROTECTED]