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
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.
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.
[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.
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.
Jason.
- Jörg
---------------------------------------------------------------------
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]
