Jason van Zyl wrote on Thursday, April 26, 2007 4:41 PM: > On 26 Apr 07, at 10:12 AM 26 Apr 07, Jörg Schaible wrote: > >> Jason van Zyl wrote on Thursday, April 26, 2007 3:21 PM: >> >>> On 26 Apr 07, at 8:20 AM 26 Apr 07, Jörg Schaible wrote: >> >> [snip] >> >>>> Therefore the slots. The project itself can introduce them, if two >>>> major versions can be used at same time. Think about a hypothetical >>>> commons-logging 2.0 (it is discussed) that might have a different >>>> API. I am quite sure Jakarta folks will ensure that 2.x and 1.x >>>> series can be used at the same time - simply because even in the >>>> Maven repo itself ~ 2000 artifacts depend on it. Without something >>>> like the slots, you will never be able to create a new Maven-based >>>> project using JCL 2.x ... >>> >>> I don't think we need to introduce the idea of slots. Allowing >>> multiple versions would suffice. I don't see what the slot concept >>> buys anyone except another term to be familiar with. >> >> Well, so how could this work in practice? >> >> B-2.2 depends on A-1.0.1 >> C-1.3 depends on A-2.1 >> D-1.1 depends on A-1.2 >> E-1.0 depends on C-2.2 and C-1.3
should have been: E-1.0 depends on B-2.2 and C-1.3 >> F-1.0 depends on E-1.0 and A-1.0.1 >> >> What do I have to do for E? How does Maven know that A-1.x and >> A-2.x are both necessary and that it should use A-1.2 and A-2.1? Do >> I have to add both deps explicitly to E? What does this mean for F? >> How can I manage in a parent POM the two versions of A in the >> dependencyManagement? > > The first question to answer is whether we even want to allow this > and if the complexity that would arise from situations like this are > worth it versus having N modules where each module has a different > set of dependencies. What's easier, and what's necessary. Because > there exists a solution in Gentoo for doesn't mean it's necessarily > the right one for Maven. And because people have these situations in > their builds also doesn't necessarily mean it's something ideal. Not > saying it's not worth consideration, just playing the devil's > advocate. I'm quite sure, nobody sets up something like this at free will. Typically A to at least D are third party artifacts you don't controll, but you have to manage the mess on your end dealing with environments that have themselves no clue about isolated classloaders. At this point your level of tolerance for the build tool tends to zero. ;-) > In your case here above then in dependency management we would also > support multiple versions where you could specify defaults, and if > you needed to override them in the child you would. This translates > into multiple version support all the way down in the core. >From my naive PoV, it looked easier to introduce a "slot" that behaves quite >like a classifier than implementing support for multiple versions at once. >*This* would have scared me much more. However, you're the expert with best >knowledge of the internals and you can estimate the impact much better than me. [snip] > Yes, as I said this doesn't necessarily translate into an ideal for > Maven. My default position now is the distro tools take their notions > and wind them all the way down into the core of the distro which > doesn't necessarily jive well with Maven. Again I'm not dismissing > slots and multiple versions allowable in the POM. I'm quite sure, the topic will rise again. Better to be prepared about the options, especially since M2.1 is not that far away. Anyway, thanks for your time. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
