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 <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>
------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
