The composite pattern also makes exclusion very easy. On Sep 30, 2012 3:35 PM, "Michael McCallum" <[email protected]> wrote:
> I - almost - disagree completely, I've successfully used ranges on seven > separate commercial projects. A mix of sizes from corporate to startup. > > If you care at all about agility being explicit everyone is very > cumbersome, the fundamental aspect is determinism - meaning that its > obvious WHY it behaves the way it does, once you understand how maven > implements ranges its very easy to use to them to great effect. > > Having said that using ranges can be dangerous hence the composition > pattern mentioned in my previous email. > > When you say nail down your version do you use [1.7.1] or 1.7.1? > > On Fri, Sep 28, 2012 at 11:20 AM, Baptiste MATHUS <[email protected]> wrote: > > > +1. > > Version ranges are basically just a bad practice in my experience. I > mostly > > don't see any interest apart from being able to see a normally passing > > build suddenly going rogue because you somehow had a dependency update > > somewhere in the dependency tree. (I wrote something similar in that > > comment > > > > > http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577 > > ) > > > > So, please, Maven users, don't use them. It's like having scripts inside > > your pom.xml, it might seem sexy and powerful, but it's dangerous. > > Nail down a version, and upgrade explicitly when you need to and/or are > > ready to. You'll be very happy that way and your build'll stay green. > > > > Cheers > > > > 2012/9/28 Stephen Connolly <[email protected]> > > > > > Well that is a recipe for disaster. rules only make sense within the > > scope > > > of the artifacts they apply to. > > > > > > This is kind of why version ranges are next to useless from a practical > > PoV > > > anyway > > > > > > On 27 September 2012 23:05, Paul French <[email protected]> > wrote: > > > > > > > I would only want the same version rules applied to all artifacts, > not > > on > > > > a per artifact basis, that would be a nightmare! I understand that > > people > > > > who produce artifacts have their own versioning rules. However we can > > > take > > > > that into account in our version ranging. > > > > > > > > Usually for 3rd party artifacts we have a very narrow version range > > since > > > > we cannot trust the producer of that artifact not to break their > > current > > > > API in later versions unless they support semantic versioning. > > > > > > > > > > > > On 27/09/2012 22:29, Stephen Connolly wrote: > > > > > > > >> when is that class applied? > > > >> > > > >> each dependency would have its own comparator, as each dependency > has > > > its > > > >> own versioning rules. > > > >> > > > >> and then don't start on epoch's (i.e. where the versioning rules > > change > > > >> from under your feet mid sequence > > > >> > > > >> It's tempting... but dangerous... the closest I have come up with is > > the > > > >> rulesets hack from versions-maven-plugin @ mojo... but even that has > > > >> issues... hence why I haven't pushed it further. > > > >> > > > >> -Stephen > > > >> > > > >> On 27 September 2012 22:19, Paul French <[email protected]> > > wrote: > > > >> > > > >> Okay I see the problem. > > > >>> > > > >>> How about allowing a user to plugin a Version class that implements > > > >>> Comparator > > > >>> > > > >>> class MavenVersion implements Comparable<MavenVersion> > > > >>> { > > > >>> public int compareTo(MavenVersion o) > > > >>> { > > > >>> // your implementation > > > >>> } > > > >>> } > > > >>> > > > >>> Then we can all do whatever we need. > > > >>> > > > >>> > > > >>> On 27/09/2012 21:40, Hervé BOUTEMY wrote: > > > >>> > > > >>> I understand that many people get caught > > > >>>> > > > >>>> But what do you expect from [1.7,1.8]? > > > >>>> And [1.7,1.8-beta)? > > > >>>> > > > >>>> The actual semantic is pure mathematical range, including or > > excluding > > > >>>> an > > > >>>> extreme > > > >>>> > > > >>>> since 1.8-alpha<1.8-beta-<1.8-rc<1.****8-SNAPSHOT<1.8, it's pure > > math > > > >>>> > > > >>>> IMHO, anything that doesn't conform mathematical range will have > > some > > > >>>> unexpected behaviour sometime > > > >>>> > > > >>>> Yes, people need to learn that they usually want > > > >>>> [1.7,1.8-alpha-SNAPSHOT) > > > >>>> if > > > >>>> they want to be precise. Or approximations: [1.7,1.8-a), > > [1.7,1.7.999] > > > >>>> Or we need to create another notation and define its semantics > > > precisely > > > >>>> > > > >>>> Regards, > > > >>>> > > > >>>> Hervé > > > >>>> > > > >>>> Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit : > > > >>>> > > > >>>> +1 > > > >>>>> > > > >>>>> I agree with Jesse. > > > >>>>> > > > >>>>> A version range like [1.7,1.8) should exclude any artifact that > > > starts > > > >>>>> with 1.8 > > > >>>>> > > > >>>>> Then maven (or aether) would respect semantic versioning rules. > > > >>>>> > > > >>>>> We use version ranges/semantic versioning and API analysis to > > ensure > > > >>>>> our > > > >>>>> artifacts are versioned correctly. Sometimes we get caught out by > > > what > > > >>>>> Jesse outlined below. > > > >>>>> > > > >>>>> On 27/09/2012 15:51, Stephen Connolly wrote: > > > >>>>> > > > >>>>> On 27 September 2012 14:41, Jesse Long <[email protected]> > > wrote: > > > >>>>>> > > > >>>>>> Dear Maven Community, > > > >>>>>>> > > > >>>>>>> I am writing to beg you to fix the problems with the version > > ranges > > > >>>>>>> in > > > >>>>>>> Maven 3.0.5, specifically regarding the defining compatible > > version > > > >>>>>>> ranges. > > > >>>>>>> > > > >>>>>>> I am using Maven 3.0.4. I have a simple project that depends on > > > >>>>>>> org.slf4j:slf4j-api version 1.5.*. I define my compatibility > > range > > > as > > > >>>>>>> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I > > > >>>>>>> define > > > >>>>>>> the > > > >>>>>>> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api > > > version > > > >>>>>>> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then > > > >>>>>>> slf4j-api > > > >>>>>>> version 1.6.0-alpha2 is linked in. > > > >>>>>>> > > > >>>>>>> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), > > then > > > >>>>>>> the > > > >>>>>>> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 > > was > > > >>>>>>> released it would probably break again. > > > >>>>>>> > > > >>>>>>> This is all too counter-intuitive. The current version of SLF4J > > is > > > >>>>>>> 1.7.1. > > > >>>>>>> If my project was to be built against it, knowing that there > is a > > > >>>>>>> likelihood of an incompatible change being introduced in 1.8.0 > > > (SLF4J > > > >>>>>>> does > > > >>>>>>> not adhere to SemVer), I would like to define my version range > > for > > > >>>>>>> slf4j-api as [1.7.0,1.8.0). I > > > >>>>>>> > > > >>>>>>> I think you do [1.7.0,1.8.0-!) > > > >>>>>> > > > >>>>>> but that might just include 1.8.0-SNAPSHOT > > > >>>>>> > > > >>>>>> have no way of knowing before the time what type of -RC0, > > -alpha2 > > > >>>>>> > > > >>>>>>> qualified releases will be made for 1.8.0, so I can only > exclude > > > >>>>>>> 1.8.0. > > > >>>>>>> > > > >>>>>>> However, when 1.8.0-alpha2 is released with incompatible > changes, > > > my > > > >>>>>>> build > > > >>>>>>> will immediately be broken. > > > >>>>>>> > > > >>>>>>> I could depend on version 1.5.11 directly, without using a > > version > > > >>>>>>> range, > > > >>>>>>> but Maven considers this a soft version dependency and will > > ignore > > > it > > > >>>>>>> as > > > >>>>>>> needed. > > > >>>>>>> > > > >>>>>>> It is apparent that there is no reliable way to define a > > > >>>>>>> compatibility > > > >>>>>>> range in Maven. I feel that this should be a major concern to > all > > > >>>>>>> Maven > > > >>>>>>> users and developers. > > > >>>>>>> > > > >>>>>>> It would be a shame for all the effort made by the Maven > > community > > > to > > > >>>>>>> make > > > >>>>>>> software builds stable and reproducible to be undermined by > > > >>>>>>> consistent, > > > >>>>>>> predictable breakage described above. > > > >>>>>>> > > > >>>>>>> I have read in mailing list archives that the suggested way of > > > >>>>>>> excluding > > > >>>>>>> all 1.8.0 pre-release version is to define an exclusive upper > > bound > > > >>>>>>> as > > > >>>>>>> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated > > above > > > >>>>>>> with > > > >>>>>>> 1.6.0-RC0, this does not work. Also, it makes no sense at all > > for a > > > >>>>>>> user > > > >>>>>>> to > > > >>>>>>> wish to include 1.8.0-SNAPSHOT and not 1.8.0. > > > >>>>>>> > > > >>>>>>> My proposal is that the qualifier is ignored when comparing a > > > version > > > >>>>>>> to > > > >>>>>>> the version number declared in an exclusive upper bound. ie. > > > >>>>>>> 1.6.0-xyz > > > >>>>>>> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and > > therefore > > > >>>>>>> considered to fall outside of the version range. Importantly, > it > > > >>>>>>> should > > > >>>>>>> only be for the special case of comparing to the version number > > in > > > an > > > >>>>>>> exclusive upper bound. > > > >>>>>>> > > > >>>>>>> If the powers that be see fit, an exception could be made for > > > service > > > >>>>>>> pack > > > >>>>>>> qualifiers, which according to one web page on Maven version > > > >>>>>>> ordering I > > > >>>>>>> read, should be sorted after the release, although I would > prefer > > > to > > > >>>>>>> see > > > >>>>>>> Maven more closely aligned to SemVer, where all qualified > version > > > >>>>>>> numbers > > > >>>>>>> are considered pre-release versions. I consider 1.7.2 a better > > > >>>>>>> version > > > >>>>>>> number than 1.7.1-sp1. > > > >>>>>>> > > > >>>>>>> Ultimately, I would like to be able to make things as easy as > > > >>>>>>> possible > > > >>>>>>> for > > > >>>>>>> users depending on a library that adheres to SemVer, to define > a > > > >>>>>>> compatibility range like: [1.4.0,2.0.0). I see no reason why it > > > >>>>>>> should > > > >>>>>>> not > > > >>>>>>> be as easy as that. > > > >>>>>>> > > > >>>>>>> Please consider fixing this soon. > > > >>>>>>> > > > >>>>>>> I have not logged a Jira issue, as I cannot log into CodeHaus > > Jira. > > > >>>>>>> The > > > >>>>>>> signup link on this page displays an error: > > > >>>>>>> http://maven.apache.org/users/ > > > >>>>>>> **getting-help.html <http://maven.apache.org/**** > > > >>>>>>> users/getting-help.html< > > > http://maven.apache.org/**users/getting-help.html> > > > >>>>>>> <http:/**/maven.apache.org/users/**getting-help.html< > > > http://maven.apache.org/users/getting-help.html> > > > >>>>>>> > > > > >>>>>>> > > > >>>>>>> Jira issue MNG-3092, reported over 5 years ago, is related to > > this > > > >>>>>>> issue, > > > >>>>>>> but the initial report is for a similar issue, not this issue. > > The > > > >>>>>>> issue > > > >>>>>>> I > > > >>>>>>> describe above is reported and discussed in the comments for > > > MNG-3092 > > > >>>>>>> though. > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> Jesse > > > >>>>>>> > > > >>>>>>> > > > ------------------------------******--------------------------**--** > > > >>>>>>> --**--------- > > > >>>>>>> To unsubscribe, e-mail: > > > >>>>>>> users-unsubscribe@maven.****apac**he.org <http://apache.org>< > > > >>>>>>> users-unsubscribe@**maven.**apache.org < > http://maven.apache.org > > >< > > > >>>>>>> users-unsubscribe@**maven.apache.org< > > > [email protected]> > > > >>>>>>> > > > > >>>>>>> > > > >>>>>>> For additional commands, e-mail: [email protected] > > > >>>>>>> > > > >>>>>>> > ------------------------------****----------------------------** > > > >>>>>> --** > > > >>>>>> > > > >>>>> --------- > > > >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org< > > > http://apache.org> > > > >>>>> <users-unsubscribe@**maven.apache.org< > > > [email protected]> > > > >>>>> > > > > >>>>> For additional commands, e-mail: [email protected] > > > >>>>> > > > >>>>> ------------------------------****----------------------------** > > > >>>> --**--------- > > > >>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org< > > > http://apache.org> > > > >>>> <users-unsubscribe@**maven.apache.org< > > > [email protected]> > > > >>>> > > > > >>>> For additional commands, e-mail: [email protected] > > > >>>> > > > >>>> > > > >>>> ------------------------------****----------------------------** > > > >>> --**--------- > > > >>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org< > > > http://apache.org> > > > >>> <users-unsubscribe@**maven.apache.org< > > > [email protected]> > > > >>> > > > > >>> For additional commands, e-mail: [email protected] > > > >>> > > > >>> > > > >>> > > > > > > > > > > ------------------------------**------------------------------**--------- > > > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > > > [email protected]> > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > -- > > > Baptiste <Batmat> MATHUS - http://batmat.net > > > Sauvez un arbre, > > > Mangez un castor ! > > > nbsp;! > > > > > >
