Le samedi 14 juin 2014 10:15:40 Jason van Zyl a écrit :
> On Jun 14, 2014, at 2:39 AM, Hervé BOUTEMY <[email protected]> wrote:
> > this is one of the problems when using version ranges, tied to
> > reproducibility and definition of the algorithm for Maven to choose one
> > version in the range adapted to the actual context.
> >
> > This is sometimes incorrectly (IMHO) told as "maven ranges with
> > non-SNAPSHOT bounds should not contain SNAPSHOTs"
> >
> > in fact, ranges do contain SNAPSHOTs: it's mathematical
>
> How is this mathematical? A SNAPSHOT is simply a representation of concrete
> version number which may fall within the constraints of the range. It has a
> special meaning to us to mean a pre-release version and we may arbitrarily
> do one thing or another with a SNAPSHOT when we see one.
+1
> I don't see how this is mathematical.
if my frenglish doesn't cause any unexpected result, mathematic definition of a
range is a lower bound, an upper bound + a comparison algorithm: anything that
is between the bounds given the comparison algorithm is in the range
so 1.1-SNAPSHOT is in [1,2] range
and yes, 1.1-anything is in the [1,2] range too
so the question is not if 1.1-SNAPSHOT is in the range: it is
the question is: do we want to let the range resolver choose such a 1.1-
SNAPSHOT at the time we're working?
and the answer depends on the context, not on the range definition.
> What we have done to include/exclude them we have
> arbitrarily changed a couple times now.
yes, I know, that why I'd like we all can discuss and be sure we understand
ourselves
> > but the question is: how to avoid non-SNAPSHOT resolution/choice when
> > doing a release, while resolving SNAPSHOTs when not doing a release?
>
> The only way to do this is to constrain what you resolve against to not
> contain snapshots. In the case of my current setup we simply disallow
> SNAPSHOTs entirely.
it's a way to do that, yes: I wouldn't say that it's the only one
another way is to change the algorithm that selects the effective version from
the list of everything that is available in the range in the repo: IIUC, the
actual algorithm is "take the max" (I couldn't find where it is coded).
It could be changed to "take the max that has other constraints": in the
context of a release (ie passing from SNAPSHOT to non-SNAPSHOT), don't accept
SHAPSHOTs
>
> Traditionally there are two ways to attain consistency and that is having
> concrete versions where you can resolve arbitrary content in your
> repositories. Or you use ranges and resolve against constrained content in
> your repositories.
yes, but how is the constraint expressed and coded?
>
> That said Christian's patch is working fine as not too affect any existing
> behaviour and in the release we can mark the use of ranges in parents as
> provisional. Though to me it seems more consistent to allow it in the
> parent if you're going to allow it in a dependency.
+1 this patch improves features consistency: parent is a dependency like
another
> I will admit to being
> biased here as I'm working with a project that has hundreds of projects and
> we would effectively use this as a way to version the entire set of
> projects consistently. Which is very convenient.
>
> Maybe this is something we can also discuss in the hangout next week.
yes, I think this would be useful
I still don't understand how version ranges can be used without
reproducibility issues, how version is selected in the range, if the algorithm
is parametrized or completely hardcoded (I suppose as "max" function), if some
other algorithms could be useful in other contexts ("min", for example)
>
> > How to affect the algorithm that magically choose on version in the range?
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 14 juin 2014 07:27:06 Christian Schulte a écrit :
> >> Am 06/14/14 04:50, schrieb talios:
> >>> Github user talios commented on the pull request:
> >>> https://github.com/apache/maven/pull/21#issuecomment-46076519
> >>>
> >>> Interesting about the version range changes in aether there - whilst
> >>> the [2.2.*] range is nice, that doesn't offer SNAPSHOT exclusion -
> >>> unless the `VersionFilter` is being exposed somehow to maven - I
> >>> don't see maven directly supporting that. Tho this discussion should
> >>> be taken off-issue I guess.
> >>
> >> I did not follow any discussion about SNAPSHOT handling in version
> >> ranges. From a version specification grammar point of view, '-SNAPSHOT'
> >> is just another qualifier without special meaning. The special meaning
> >> comes from Maven changing behaviour when detecting that qualifier.
> >> Dealing with this could be as simple as changing version range behaviour
> >> based on that qualifier as well. So when a POM defines that qualifier,
> >> Maven includes versions carrying that qualifier, and if a POM does not
> >> define that qualifier, Maven excludes that qualifier. Actually, it's a
> >> flag indicating a project to be work in progress. If 'true', that
> >> project is allowed to depend on other projects flagged work in progress,
> >> if 'false', it's not. Just an idea, however.
> >>
> >> Regards,
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> The modern conservative is engaged in one of man's oldest exercises in moral
> philosophy; that is, the search for a superior moral justification for
> selfishness.
>
> -- John Kenneth Galbraith
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
