>>I think we could make a kind of an interface to delegate the real comparison to an user implemented thing (via extensions)....We could make the api and use the current implementation as a default ?
This was my thought as well. It can be really a nightmare, as I understood as well, which is worse than a freedom. Maybe let it be for now. On Sun, Sep 25, 2016 at 1:22 PM, Karl Heinz Marbaise-3 [via Maven] < ml-node+s40175n5881505...@n5.nabble.com> wrote: > Hi Hervé, > Hi Tibor, > > > On 25/09/16 12:05, Hervé BOUTEMY wrote: > > yes, letting people implement their own version comparison algorithm is > a > > dream I have for a long time: this would avoid immediate complaints, or > change > > our answer to complaints > > This is a point... > > > > > but I fear this will be complex to document (and honestly, this would > require > > per-artifact configuration, since the list of exceptions won't be the > same for > > everybody) > > > > And believe me, writing a version comarison algorithm is not so easy... > > Then the dream soon becomes a nightmare :) > > If you start thinking about version comparison in detail (I have > started with this a little bit ;-( ) it will become really a > nightmare...and really hard... > > What happens with artifacts in your repository manager if you change the > version comparison ? Can you reuse them ? What happens if two people use > different comparisons can they use the same repository to share their > artifacts which includes their transitive dependencies (which implies > the comparison) ? This are only a few question which I have started > with? Which brings a extreme complexity which I have to admit can't > handle... > > > > > > another fact that prevented me to do so: when is version comparison > used? When > > people use version ranges for defining their dependencies: I still don't > > understand what's the resolution algorithm used to choose a version form > the > > range (max? other?). And why people want to make their dependencies > resolution > > non-detemrinistic, since the resolution tomorrow won't give the same > result as > > today. > > That's one big thing which I never understand why people trying to use > version ranges...and like to use them...just to prevent some changes in > their pom files which are documented via their version control ? > > > > > > Making version ranges usage consistent requires IMHO more work than just > > making version comparison customizable > > I think we could make a kind of an interface to delegate the real > comparison to an user implemented thing (via extensions)....We could > make the api and use the current implementation as a default ? (For > version ranges I'm not sure how that would really work)... > > Kind regards > Karl Heinz > > > > > > > Regards, > > > > Hervé > > > > Le dimanche 25 septembre 2016 11:47:28 Tibor Digana a écrit : > >> As for instance comparing 6.1 > 6.1H. A good example would be 1.2.3 > > >> 1.2.3-RC1 but Maven may receive a new Jira request where 6.1H breaks > >> something else, and therefore never ending story to change comparator. > >> That now you have to always change implementation by users requests in > Jira. > >> I know that you are talking about Test review but my point is not the > test > >> however I read your test completely and have nothing against your test > >> LGTM. The purpose of the scripts is to move the responsibility to user > in > >> order to implement some user's wishes on their side. > >> > >> > >> > >> On Sun, Sep 25, 2016 at 11:25 AM, Karl Heinz Marbaise <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5881505&i=0>> > >> > >> wrote: > >>> Hi Tibor, > >>> > >>> maybe you misunderstand my request...I would like to have review on > the > >>> code in comparison to the original ComparableVersionTest which uses > >>> Comparator as return type which produces warnings in IDE about raw > types > >>> which I tried to fix...and now I would like to have someone taken a > look > >>> on > >>> it if I didn't missing an important thing in the test which might make > an > >>> assumption which I oversight... > >>> > >>> > >>> Why should a user write a script in .mvn ? What should be the purpose > of > >>> that...? > >>> > >>> Kind regards > >>> Karl Heinz > >>> > >>> On 25/09/16 11:17, Tibor Digana wrote: > >>>> If it just works, ok. > >>>> But I am thinking of different topic related to Versions. Since > Versions > >>>> have been discussed in Jira even before I am thinking if it is more > >>>> suitable to let the users write some script as > versions-comparator.bsh in > >>>> Bean Shell in folder ".mvn". > >>>> > >>>> On Sat, Sep 24, 2016 at 7:13 PM, Karl Heinz Marbaise-3 [via Maven] < > >>>> [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5881505&i=1>> wrote: > >>>> > >>>> Hi, > >>>> > >>>>> I have polished the code of the ComparableVersionTest class a little > >>>>> bit...which looks like this: > >>>>> > >>>>> https://gist.github.com/khmarbaise/a75a967983118de0dddea0adbd21b9d7 > >>>>> > >>>>> This will prevent warnings in IDE about raw types... > >>>>> > >>>>> WDYT ? > >>>>> > >>>>> Kind regards > >>>>> Karl Heinz Marbaise > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > > >>>>> To unsubscribe, e-mail: [hidden email] > >>>>> <http:///user/SendEmail.jtp?type=node&node=5881382&i=0> > >>>>> For additional commands, e-mail: [hidden email] > >>>>> <http:///user/SendEmail.jtp?type=node&node=5881382&i=1> > >>>>> > >>>>> > >>>>> > >>>>> ------------------------------ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5881505&i=2> > For additional commands, e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=5881505&i=3> > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://maven.40175.n5.nabble.com/ComparableVersionTest- > tp5881382p5881505.html > To start a new topic under Maven Developers, email > ml-node+s40175n142166...@n5.nabble.com > To unsubscribe from Maven Developers, click here > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > . > NAML > <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://maven.40175.n5.nabble.com/ComparableVersionTest-tp5881382p5881536.html Sent from the Maven Developers mailing list archive at Nabble.com.
