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
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 :) 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. Making version ranges usage consistent requires IMHO more work than just making version comparison customizable 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 <khmarba...@gmx.de> > > 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] < > >> ml-node+s40175n5881382...@n5.nabble.com> 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> > >>> > >>> > >>> > >>> ------------------------------ > >>> If you reply to this email, your message will be added to the discussion > >>> below: > >>> http://maven.40175.n5.nabble.com/ComparableVersionTest-tp5881382.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?m > >>> acro=unsubscribe_by_code&node=142166&code=dGlib3JkaWdhbmFAYX > >>> BhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg==> > >>> . > >>> NAML > >>> <http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?m > >>> acro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base > >>> =nabble.naml.namespaces.BasicNamespace-nabble.view.web. > >>> template.NabbleNamespace-nabble.view.web.template.NodeNamesp > >>> ace&breadcrumbs=notify_subscribers%21nabble%3Aemail. > >>> naml-instant_emails%21nabble%3Aemail.naml-send_instant_ > >>> email%21nabble%3Aemail.naml> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
