On Jun 14, 2014, at 12:13 PM, Hervé BOUTEMY <[email protected]> wrote:
> 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. > I will argue that insofar as range resolution is concerned we should deal purely with the numeric computation and avoid all special consideration for our qualifiers such as SNAPSHOT. I will even go so far as to say that you should never put a special qualifier in a range definition and that it needs to remain numeric. So if you have a dependency which specifies a range of [1.0,2.0) and you have a build of this where 1.1-SNAPSHOT is being deployed, then ultimately the SNAPSHOT gets expanded to 1.1-yyyymm.ddhhss-# and if that artifact is visible, that it's purely considered on the numerical representation and the resolver will select it. We partition the deployment of non-release artifacts from release artifacts, yet we don't employ this partitioning during resolution and I believe users have taken to the habit of using group repositories which makes everything available and I think makes this issue harder to deal with. So to me there is no special context based on magic qualifiers, there is only the numeric range calculation. > >> 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? > Trying to encode these in such a way where you effectively have a property graph is hard. Aether has some preliminary support for this but not really. In practice to date it's really constrain the version or constrain what you are resolving against. Either explicit with your version as a concrete version if you want to resolve against the wild. Or you use ranges and the constraint is encoded as the list of repositories you are going to resolve against. I would love arbitrary property graph based resolution, but even if we had it (which is by no means trivial) I probably still wouldn't want to encode special magic for SNAPSHOTs. >> >> 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) Given that we have a de facto formalism through our code, specifically in Aether, that I would gravitate toward using a formalized resolution model like what OSGi. I'm certainly not a huge proponent of OSGi, but they have a completely formalized and specified resolution algorithm. At any rate you have the two mode of ensuring reproducibility which is to use concrete versions against an arbitrary set of repositories, or range versions against a constrained set of a repositories. In both cases you'll have reproducibility problems if your repositories are not managed correctly. But I think trying to come up with a property graph based resolution mechanism to deal with context is not going to happen any time soon and most likely never so I don't really think pursuing that is an option. > >> >>> 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] > 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
