If you want to "fix all things Maven" then "provides" and "requires"
needs to be added. Version checking by itself is never going to get it
right.
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>lang</artfiactId>
<required>lang-api-3.0</required>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<required>beans-2.0,aop-2.5</required>
</dependency>
Now if I specify in a dependency management somewhere that I want
spring 3.0.0.M4 and if that version only "provides" beans-2.5 and
beans-3.0 then an error will be generated during the build instead of
finding out at run time that the combinations of jars won't work
together.
Ralph
On Sep 22, 2009, at 7:34 PM, Paul Benedict wrote:
I vote for option #2. Maven 3 should fix all things Maven; and if we
need to
introduce backwards compatibility flags to help mitigate those
problems, I
would do that too.
Paul
On Tue, Sep 22, 2009 at 9:26 PM, Brett Porter <[email protected]>
wrote:
On 16/09/2009, at 8:18 PM, Benjamin Bentmann wrote:
Ignoring for the moment that neither "3.0-!" nor "3.0.0.!" are
OSGi-conformant versions, the OSGi version ordering also implies
3.0 == 3.0.0 < 3.0.0.20090915-152839-2 < 3.0.0.GA < 3.0.0.SNAPSHOT
So I'm not sure how much we can borrow from OSGi for Maven.
IIUC, The code that Hervé pointed to now has a number of
workarounds so
that OSGi works in most of its current uses, and Maven versions
work in most
of its current uses - but it doesn't conform to the spec of either.
ie,
alpha, beta, rc, cr, milestone and snapshot are all before the
release, the
rest after. I think this would have been a good idea if we'd done
it to
start with, but I'm sure there are weird versions out there that
might cause
confusion (only mediated by the fact that people don't use ranges
all that
often).
I think there are 3 options here:
- keep adding more special cases in the version comparer for things
like !
- declare a break in compat (this may result in having to make
repository
changes to preserve functionality though in a mixed environment)
- restore the Maven 2 behaviour and make each place a range is used
configurable so that OSGi can be used as an alternatives - for
example -
osgi:[x.y.z.q,) vs mvn:[x.y.z,)
Cheers,
Brett
---------------------------------------------------------------------
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]
