On 16/10/09 11:45 AM, Stephen Connolly wrote:
2009/10/16 Peter Janes<[email protected]>
On 15/10/09 05:45 AM, Stephen Connolly wrote:
These are very dangerous versions to suggest use of.
...but there *are* use cases for them.
When your use case results in a completely unpredictable build... no thank
you.
For dependencies, use version ranges.
For plugins, you should always lock down the version.
That is best practice, and that is what we should support.
OK, I guess what I really need is something like HIGHEST-RELEASE and
HIGHEST-SNAPSHOT. I don't think version ranges will support this case, as
the version in use could be anything in the range; RELEASE/LATEST would work
locally (since we generally perform incremental releases rather than
patches) but not in the general case.
What I want to use this for is to drive continuous/automated higher-level
testing, e.g. integration tests, system tests, upgrade tests, etc., as part
of a wider lab deployment scenario. This wouldn't produce artifacts per se,
it would just install the products and run tests against them. So instead
of using the latest versions of foo-api and bar-api, I want to verify that
the latest versions of Foo and Bar work together, i.e. the integration-test
project would depend on Foo:HIGHEST-RELEASE and Bar:HIGHEST-RELEASE.
If you have a CI system deploying snapshots as you go, and following each of
the dev streams, then LATEST is essentially completely _RANDOM_ as far as a
developer is concerned, since the version you get purely depends on the last
version deployed by the CI system.
If you can present a usecase where this is _exactly_ what you want, then
fine, but I have yet to see such ;-)
You're right, they're completely wrong for the purpose and I don't see how
they'd ever be useful as implemented today.
These are deprecated and are only "special" versions when considering
plugins... and they do not behave as you think they behave.
For what it's worth, the Sonatype Maven book says that "When you depend on
a plugin *or a dependency*, you can use the version value of LATEST or
RELEASE."[1]
We need to fix the sonatype book then
;-)
Agreed. Especially since they're not supported consistently, and (as you
mentioned) they don't behave the way their names suggest. Since Sonatype
are so heavily involved in developing Maven I kind of took the book as the
expected behaviour, since there's very little documentation on those
pseudo-versions elsewhere.
--
Sometimes the Universe needs a change of perspective.
--J. Michael Straczynski
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
