>Quote:
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.
>
The problem with the statement that 'snapshots fit perfectly in a version
range' is that it missing the point. You are technically correct; a
snapshot is a version that precedes its version number. However that is not
the point when you are specifying the version tag of a dependency. The
problem with allowing snapshots to fill version ranges unless specified in
the version range is that it is inconsistent behavior with how non-version
ranges work. If I don't use version ranges I get precise control over
snapshots/non-snapshots. I.e. if I specify 1.2 I will never get a snapshot,
if I specify 1.3-SNAPSHOT I will always get a snapshot. I get what I
specified. Currently if I use version ranges I loose control. I expect the
same behavior. If I specify [1.0, 2.0) I do not expect snapshots because I
did not specify a snapshot. On the other hand if I specify
[1.0,1.5-SNAPSHOT) I would expect the 1.5-SNAPSHOT to fulfill the
requirement.
>Quote:
So you want to prevent accidental use of snapshots when released versions
are available in the given range.
>
No, I don't want what is available to determine what is used. I want the
version range to never include a snapshot unless directed. I want the
version (range) to determine the resolved version nothing else.
>Quote:
Having a mechanism in place to explicitly state what dependencies can be
resolved
to snapshot versions, and what dependencies cannot is certainly useful
>
Yes, this would be useful.
>Quote:
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).
>
It is not good to have random results, the build should not be dependent on
order.
>Quote:
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?
>
You cannot say that snapshot version work because they fall into the
technical definition of a version range. Yes the goal of a snapshot that
did not change the major version would be for the API to not break anything
but one cannot guarentee this. Snapshots may be alpha versions where the
API was changed experimentally to see if something will work...it may not
work and will be reverted. Snapshots are potentially in a state of change
and one should not assume anything about them.
As for your case of specifying a snapshot dependency and also the same
dependency as a version range...No I don't think the build should fail. In
this case you are stating explicitly that you want to use a snapshot version
and you are willing to take the associated risks. As a practical matter the
only way this is possible if for the version range to be specified in one of
the child dependencies which is at least one level lower then where you
specified the snapshot dependency. This case is not much different than
what would maven do if the other dependency version was a
fixed-non-version-range version.
>Quote:
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.
>
Currently B is not possible. I have no way today of disallowing snapshots
when I use version ranges to state I want the latest released version. I.e.
[1.0,2.0). This is why we are forced to use our own build of maven today.
I really want to use public releases of maven!
>Quote:
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 ;))
>
Yes, this is a good idea. It allows finer control over the meaning of the
range. I.e. I would still allow snapshots if explicitly stated in the
version range as per the docs.
One more thought on this issue. I think it would be useful to have a way to
over-ride the version range behavior with a command line switch. There is
one use case where it would be useful for version ranges to always pull in
snapshots. Let me backup for a moment to explain. Our build server deploys
snapshots upon every code commit, i.e. clean deploy goal. (We don't want
all other builds to get these snapshots during their normal processes hence
this version range issue.) It would be somewhat helpful to be able to run
something like -AllowSnapshots=true clean verify on other dependent projects
just to ascertain if the snapshot did break anything. In this mode it does
bring in the next snapshot and if our automated server ran this on all
dependent projects we could find out sooner if a proposed change to an
artifact is going to break something. Note I would rate this feature as
minor compared to the resolution of how to limit version ranges to not
include snapshots by default.
-Dave
Kenney Westerhof-3 wrote:
>
>
>
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13174214
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
