On 1 May 07, at 5:37 PM 1 May 07, Clark, Gil W. wrote:
I know I'm getting into iffy territory here and my thoughts on this
were kind of rejected on the users list but I think that if the
version selection algorithm were to include some sort of quality
identifier it would solve some of these problems.
The idea here is that some folks are going to want "latest"
regardless of the quality of the latest while others are going to
want the latest, highest quality release of a plug-in or
component. This can be used in conjunction with a version range.
So I could say <version>[1.0-STABLE, 2.0-STABLE)</version> and I'd
only get stable releases. Or I could say <version>[1.0-WORKING,
2.0-STABLE)</version> and I'd get defaulted to STABLE as long as
there is a stable version within the numeric range or if none
exists I'd get WORKING if a version at that quality level falls in
the range. Or I could say <version>WORKING</version> if I only
want the absolute latest working version of a component - kind of
like SNAPSHOT.
This allows a POM to be targeted at a particular level of quality
while still leaving it open to select from a range of versions.
For final releases of a project good practice dictates the version
numbers be locked down for all dependencies. That does mean
modifying the POM but that seems unavoidable.
Of course, there may be multiple levels of quality like WORKING,
TESTED, FOO, RELEASE, etc. This is the way Ivy works.
Maven has the notion of pluggable version transformations. This is
the mechanism which looks at the token "SNAPSHOT" and performs the
necessary logic to examine the metadata and retrieve the last built
version. It's technically not hard to look at an arbitrary token and
perform some logic to change the version that is slotted in.
The problem here is not a technical one of allowing any token, the
problem is that what these things mean to people and the process they
go through to arrive to determine the meaning will be arbitrary.
I think what people really want here is "something that has some
functional improvements but are binary compatible with what I'm using".
What "WORKING", or "RELEASE" means vary. Especially in the case of a
release as people currently have different processes.
We have already standard testing patterns and surefire, and we are
starting to see standard release procedures so what we want to move
toward is the use of ranges which would be good but coupled with some
criteria for quality. So you would simply say I want [1.0,) which is
anything 1.0 or above that 1) is binary compatible with what I used
last time (we go and find the last release and see what version was
resolved), and 2) has the same or better coverage. This is the only
way you can deterministically be safe of picking something further
down in a range.
Who's going to assign these arbitrary labels to releases? I mean who
is doing this for Ivy? This stuff cannot be tacked on by the third
party it simply is not scalable. Maven has the social capital (the
necessary mass of users doing the same thing) to pull off these
coverage and binary compatibility standards to make this transparent.
That being said I still think people would benefit more from a daily
report produced from a build server that pulled in new versions of
dependencies that purport to work and actually run your tests. If
successful then you click a button and your POMs are upgrade. The
computer should do the crap work. We are really not that far away
from something like this.
The hardest part in all this is standardizing on these quality
levels - t
Bingo. This can only happen in a community like Maven where we have
striven for standard everything from day one because this is the only
way these types of things are possible. This will never be possible
using Ant with Ivy, it was never the goal of Ant. They might say they
can but that will require the addition of everything we already have.
Then it will be converging toward what Maven actually is. The key
difference is that Maven from day one was designed to have a complete
and holistic approach to solving problems like this.
For example right now for releases, using the profile we have
created, we require PGP signatures, javadocs, sources, and the
licenses and notice files are inserted automatically (with the
available overriding for cases where the metadata is insufficient).
As our profile spreads into common use we can then also mixin Clirr
to produce a small file indicating the level of binary compatibility,
and a file indicating coverage. Even if this was not done in the
original build we can inject those plugins for the release. How?
Because all our builds are the same. Intervention on our part, but
entirely scalable because of the common structure of our projects. I
don't think many people using Maven, let alone detractors understand
the power and utility of our model. We let the computer do what it's
good at and keep track of these bits. We will just say we want it to
work :-)
Jason.
hey can be dynamic - specified in the settings file or top level
POM...
-----Original Message-----
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 01, 2007 1:36 PM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
Le mardi 1 mai 2007, Tomasz Pik a écrit :
On 5/1/07, Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
Le mardi 1 mai 2007, Jerome Lacoste a écrit :
Maybe there could be an easy way to let users use the latest ?
maybe something like
mvn -L ... ( L for latest)
that would ignore all specified versions, without requiring a POM
change ? Maybe too radical.
such a LATEST option would be very usefull, not only for plugins but
for every dependencies, to do regression testing against latest
development version of everything. It would be like if Gump was
integrated into
Maven:
http://gump.apache.org/
I think we would need to differentiate plugin latest from
dependencies latest.
This LATEST thing is already in jira:
http://jira.codehaus.org/browse/MNG-2431 And I think it would be very
useful, both for plugins and for 'normal dependencies'.
not exactly:
- LATEST STABLE is not LATEST : LATEST doesn't try to differentiate
STABLE or not, just get any change to check ASAP if it breaks
something
- "mvn -L" is on the command line, not in the pom : the pom refers
to chosen versions, for normal builds, but "mvn -L" is for
continuous builds, overriding chosen versions of the pom, to check
if a dependency has an evolution that will break something. The
artifact built with "mvn -L" is not intended for use, but only as a
pro-active test against dependencies evolution
Regards,
Tomek
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
