ir. ing. Jan Dockx wrote:
On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:
What tool uses those invariant annotations? Looks useful for
application validation.
;-) Let's discuss that off-line.
cool, [EMAIL PROTECTED]://irc.codehaus.org/#maven
[snip]
<dependency>
<groupId>...</groupId>
<artifactId>...<artifactId>
<version>[versionString]</version>
<useBestCompatible>true</useBestCompatible>
<scope>...</scope>
</dependency>
What would be in the version string? Usually the first N digits denote
incompatible
versions, later ones denote compatibility updates, for instance for
all X: 1.2.X
is compatible.
Well, Maven wouldn't say. That's the point. The version scheme
implementation deals with the [versionString], so Maven itself doesn't
have to. Of course, most used version scheme's would be found
implemented at central, and Maven would have a default (convention over
configuration) which will probably be Apaches versioning practice.
Maven doesn't have to say. It should provide sensible default version comparing,
which is present. Next, version ranges should enable users to specify if they
want
compatible versions or just the latest release or whatever. It's up to the
person writing the <dependency> tag to get acquainted with the version scheme
used on
that project, and decide what kind of version(s) he'd want.
Your solution works too, but it requires a pom change, and IMHO version ranges
already
support this.
In the case where it's impossible to specify a version range for some particular set of
versions because the version scheme used by the dependency doesn't allow it, then that's
'not our problem'. May be harsh, but I opt for a generic version scheme
implementation that
supports so many version schemes, that you have to try really hard to come up
with one
that's so obscure that maven can't handle it.
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
