Max Bowsher wrote:
Kenney Westerhof wrote:
Patrick Schneider wrote:
For now, I'm a fan of disallowing snapshots when they are not
explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an
all-or-nothing
proposition. Any released artifacts with version ranges will also
start to
pull in snapshots. There wouldn't be enough control, IMO.
You can always exclude snapshots explicitly:
[1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
Personally I'm +1 for updating the docs, and let the presence of
snapshot repo's
and valid snapshot artifacts there determine wheter snapshots are used
or not.
Not only is the syntax above very cumbersome, but what about the
possibility of 1.0.1-SNAPSHOT, etc?
Ah. Yes indeed. That'll be really cumbersome.
Controlling this through snapshot repo presence/absence would be rather
suboptimal, because you couldn't pull in a snapshot for one particular
artifact without possibly getting unwanted snapshots for other
dependency artifacts published in the same repo.
True, though the proposed change will only affect version ranges, not versions.
I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.
So you want to prevent accidental use of snapshots when released versions
are available in the given range.
Having a mechanism in place to explicitly state what dependencies can be
resolved
to snapshot versions, and what dependencies cannot is certainly useful
So what we're dealing here is a way to do that. This has nothing to do with
version
ranges but with being able to say that you don't want snapshots for a certain
artifact. Specifying a normal version (without SNAPSHOT) is not going to be resolved to a snapshot,
unless there's another declaration that does mention it, and with version ranges that could happen.
The current resolution mechanism uses the first match, so it's pretty random
(the order of the searched repositories is important here).
If someone specifies a version range, he doesn't care about the version except
that it must
be in that range because he knows those versions work. SNAPSHOTs that fall into
that range
are compatible, so why can't they be used?
What about other dependencies that _are_ declared as a snapshot and bring in a
SNAPSHOT version
also declared somewhere else with a SNAPSHOT-excluding range? Should the build
fail then?
Most importantly, making this change prevents snapshots from being used in
version ranges.
Sure, you can explicitly mention them in the range, but you'd have the same
problem
as the other way around: specifying 1.0.1-SNAPSHOT, 1.0.2-SNAPSHOT etc..
It seems we want more fine grained control on this matter.
We could change the order of resolution to first check for non-snapshots,
then for snapshots, so a non-snapshot will be used when it's possible. That
would solve the problem,
except for people who want to use snapshots.
Another solution would be to somehow mark wheter a dependency or version range
should
include or exclude snapshots, or add information to repositories specifying the
groupid/artifactids
they provide or must not provide. That way you can declare the same repo twice,
once with snapshots enabled
and once without, listing the dependencies.
Not sure if this is worth the trouble though..
Anyway, we could just 'assume' that when people specify version ranges they
don't want
snapshots and apply this change. I'm just worried about the side effects, since
A (using snapshots
in ranges) is possible now and B (excluding snapshots in ranges) is cumbersome,
but when we apply this, B is possible but A is even more cumbersome.
Ow, just thought of something - have 'processing instructions' or similar in
the version ranges,
like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
