First, it's not clear to me that depMgmt is used from a POM that is loaded out of the repository...I'll take another look, though. In any case, whatever B does to specify its own dependencies, you'll have to override in one form or another in A, correct? If B specifies a dependency on D == 2.0directly (to override C's dep on D == 1.0, maybe), then A will also have to depend directly on D == whatever to get its desired behavior. How does transitive dependencyManagement change that?
Second, are you really saying that we need to support three active branches of Maven at once? Or, are you saying that you're fine shutting down the 2.0.x branch and moving that stuff (the lower-risk refactorings, etc.) on to 2.1, with trunk becoming 2.2? -john On 3/16/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
On 3/16/07, John Casey <[EMAIL PROTECTED]> wrote: > If the solution to this situation has been to define the dependency locally > with the version you want, how can having a dependencyManagement section > that works transitively possibly be relevant to those builds? Carlos, how > can this possibly break those builds? not in that case, but this one A -> B -> C -> D 1.0 B inherits dependencyManagement from somewhere with D 2.0 but doesn't depend on D explicitly A gets D 1.0 in 2.0.5 A gets D 2.0 in 2.0.6 > > I think this issue is way too important to leave out of the 2.0.x line. It's > nowhere near big enough as far as the feature itself to force an > entire 2.1release (or even an alpha of > 2.1, IMO), BUT it is hampering Maven adoption now. To me that means that our > application doesn't do a good enough job of explaining what you should do in > these cases, and more importantly, WHY you should do it. Solving > counter-intuitive configuration with web documentation is certainly one way > to address it, but it will not pass the five-minute adoption test. I guess I have lower expectations for 2.1 than other people here, thinking that it doesn't need so many new stuff. I would like to avoid getting to the same point where 1.1 is. I'd guess that most of the people that want the issue to be fixed in 2.0.6 don't care if it's 2.1 as long as its sooner than later. > > -john > > On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > > > > > On 16 Mar 07, at 2:46 PM 16 Mar 07, Carlos Sanchez wrote: > > > > > it's not unpredictable at all, it is pretty clear that to force a > > > version in a project you need to add it in your pom and > > > dependencyManagement doesn't affect transitive dependencies, it's in > > > the documentation, and even in the jira issue Brett says that it was > > > done on purpose. > > > > It's not clear because it's bites people all the time because it's > > not intuitive at all. > > > > > > > > http://maven.apache.org/guides/introduction/introduction-to- > > > dependency-mechanism.html > > > > > > > You think anyone reads that first? It's simply not what's expected. > > > > > now poms in the repo that have dependencyManagement sections will > > > start to change the behavior of current builds and people with 2.0.5 > > > will get very different results than people with 2.0.6 which i don't > > > think it's acceptable for 2.0.x > > > > No they won't. If you have overridden a dependency in a child that > > definition wins. Again as expected. As you expect if you override the > > version. What people can start doing to improve their situation is > > remove that version, manage it from depMan and still get the correct > > version, the one they selected, put into the graph. This behavior > > would not change how child project define dependencies i.e. the > > definition in the child will win. The patch allows real management > > from the depMan of the versions used and that's really what it boils > > down to. > > > > > > > > I'm not against the fix, and I wouldn't really care if this is shipped > > > next week as 2.1 and current 2.1 is moved to 2.2, or even better get > > > 2.1 alpha now with this fix (+100!) > > > > It's not a feature change, it's a fundamental defect. > > > > Jason. > > > > > > > > > > > On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote: > > >> > > >> On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote: > > >> > > >> > I agree with Brett, this is a 2.1 change, not a 2.0.x > > >> > > > >> > > >> Do you fully understand what the current behavior is and what this > > >> patch fixes? You are essentially condemning users to complete > > >> unpredictability. I really think that a build should be staged and > > >> explain to users what the change is and let people build with it. If > > >> we don't get enough feedback or there is a consensus that they think > > >> it's not good then we don't put it in. But we already have many users > > >> who are suffering and asking for this to be the default behavior. > > >> > > >> Jason. > > >> > > >> > Now as Jochen says, nothing prevents pushing stuff from 2.1 to > > >> 2.2 and > > >> > get an earlier 2.1, i though we were going to do it anyway. > > >> > > > >> > > > >> > On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote: > > >> >> On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote: > > >> >> > > >> >> > Our users must be able to trust point releases are safe > > >> upgrades. > > >> >> > Let's start moving on putting out 2.1 milestone releases > > >> instead. > > >> >> > > >> >> Agreed. On the other hand, most others seem to consider this > > >> >> change important. > > >> >> > > >> >> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should > > >> >> satisfy all. > > >> >> > > >> >> Jochen > > >> >> > > >> >> -- > > >> >> Emacs 22 will support MacOS and CygWin. It is not yet decided, > > >> >> whether > > >> >> these will be used to run Emacs or the other way round. > > >> >> > > >> >> > > >> --------------------------------------------------------------------- > > >> >> To unsubscribe, e-mail: [EMAIL PROTECTED] > > >> >> For additional commands, e-mail: [EMAIL PROTECTED] > > >> >> > > >> >> > > >> > > > >> > > > >> > -- > > >> > I could give you my word as a Spaniard. > > >> > No good. I've known too many Spaniards. > > >> > -- The Princess Bride > > >> > > > >> > > > >> --------------------------------------------------------------------- > > >> > 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] > > >> > > >> > > > > > > > > > -- > > > I could give you my word as a Spaniard. > > > No good. I've known too many Spaniards. > > > -- The Princess Bride > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
