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. I don't see how this is mathematical. What we have done to include/exclude them we have arbitrarily changed a couple times now. > 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. 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. 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. 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. > 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
