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 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? [snip] >> If your project cannot define the deps directly, the module >> approach does not work. See the JCL example. > > Yes, it works if they are separate modules. But as I said > above it is > not a technical problem to allow multiple versions of JMock for > example. At first blush I just see this causing more problems then > viable solutions. Well, therefore I refered Gentoo in my first post. They already have been there and found a solution. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
