maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tibor Digana <tibordig...@apache.org>
Subject Re: ComparableVersionTest
Date Sun, 25 Sep 2016 13:10:48 GMT
>>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+s40175n5881505h95@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+s40175n142166h86@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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message