maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard Sand" <rs...@idfconnect.com>
Subject Re: Please officially support RELEASE and LATEST (was: Re: dependency question)
Date Mon, 24 Apr 2017 17:49:30 GMT
Are you using the versions plugin? I can't live without it, I've got it 
in my corporate master base POM

http://www.mojohaus.org/versions-maven-plugin/

-Richard


------ Original Message ------
From: "Curtis Rueden" <ctrueden@wisc.edu>
To: "Maven Users List" <users@maven.apache.org>
Sent: 4/24/2017 1:46:59 PM
Subject: Re: Please officially support RELEASE and LATEST (was: Re: 
dependency question)

>Hi Jesse,
>
>>  Prefer to harden the version # in a corporate pom. Then use
>>  versions-m-p to detect and update bulk dependencies across all our
>>  projects. We manage about 350 dependencies in the corporate pom
>
>Definitely agreed. I am managing a similar number, and indeed 
>versions-m-p
>is super nice for displaying which dependencies have new versions
>available. (Must remember to feed -U to mvn, though!)
>
>I am still looking for an easy way to answer the other question: "Have
>there been changes to this component since the last release" -- i.e. 
>"Does
>this component need a new release" -- since we use release-ready master
>branches. I think the allowSnapshots property is not sufficient in my 
>case,
>since the CI will always deploy a new SNAPSHOT in response to the "Bump 
>to
>next development cycle" commit which does nothing else besides bump the
>version on master after each release.
>
>And even if somehow the versions-m-p had a magicallySolveAllMyProblems 
>flag
>here, I still believe there are other use cases where RELEASE and 
>LATEST
>are useful -- and that deprecating/removing them does not do anything
>constructive to address the problem of irreproducible builds.
>
>Regards,
>Curtis
>
>P.S. to Rick Huff: Thanks for taking the time to reply. :-)
>
>--
>Curtis Rueden
>LOCI software architect - https://loci.wisc.edu/software
>ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
>On Mon, Apr 24, 2017 at 12:37 PM, jieryn <jieryn@gmail.com> wrote:
>
>>  Prefer to harden the version # in a corporate pom. Then use
>>  versions-m-p to detect and update bulk dependencies across all our
>>  projects. We manage about 350 dependencies in the corporate pom, and
>>  that doesn't even include the huge number that are scope=import for
>>  Arquillian and Selenium, etc.
>>
>>  On Mon, Apr 24, 2017 at 12:58 PM, Curtis Rueden <ctrueden@wisc.edu> 
>>wrote:
>>  >> I would like to argue for the inclusion / restoration / continued
>>  >> support of the RELEASE and LATEST tags.
>>  >
>>  > Really? No one else cares enough to respond?
>>  >
>>  > I am very often running into use cases where the easiest solution 
>>seems
>>  to
>>  > be LATEST and/or RELEASE. I have to manage a large Bill of 
>>Materials POM
>>  > and I need to know things like "which components have new releases
>>  > available" and "which components have SNAPSHOT builds since the 
>>last
>>  > release." How do other people answer these questions without custom
>>  > tooling, and without using LATEST or RELEASE tags?
>>  >
>>  > Regards,
>>  > Curtis
>>  >
>>  > --
>>  > Curtis Rueden
>>  > LOCI software architect - https://loci.wisc.edu/software
>>  > ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>  >
>>  >
>>  > On Thu, Apr 13, 2017 at 10:51 AM, Curtis Rueden <ctrueden@wisc.edu>
>>  wrote:
>>  >
>>  >> Hi Maven developers,
>>  >>
>>  >> I would like to argue for the inclusion / restoration / continued
>>  support
>>  >> of the RELEASE and LATEST tags.
>>  >>
>>  >> Reasons:
>>  >>
>>  >> 1) There are many valid use cases for them. For example, my script 
>>jrun
>>  >> [1] uses RELEASE right now to make it easier to launch a Maven 
>>GAV.
>>  >> Launching e.g. the Jython REPL is as easy as "jrun
>>  >> org.python:jython-standalone" from the CLI. But this relies on 
>>RELEASE
>>  >> working. I know that Maven is traditionally viewed as primarily a
>>  >> build-time tool, but it is also extremely useful for synthesizing
>>  runtime
>>  >> environments, and IMHO underutilized in this regard.
>>  >>
>>  >> 2) For LATEST, you can achieve basically the same behavior using a
>>  version
>>  >> range like [0,). There is no other way (that I know of) to achieve 
>>what
>>  the
>>  >> RELEASE tag does.
>>  >>
>>  >> 3) The argument that they harm reproducibility is totally valid. 
>>But so
>>  do
>>  >> SNAPSHOTs, and so do version ranges. And those have not been
>>  deprecated. So
>>  >> why are RELEASE and LATEST eschewed so heavily?
>>  >>
>>  >> Orthogonally: I think it would be awesome to warn about 
>>irreproducible
>>  >> builds, be they from SNAPSHOTs, version ranges, or these special
>>  keywords.
>>  >> People need to know when their builds are vulnerable. But there 
>>should
>>  >> probably also be a property to disable this warning, for the cases 
>>when
>>  the
>>  >> developer intentionally wants/needs to use them, and knows what 
>>they are
>>  >> doing. If the issue is just that no ones has time to work on e.g.
>>  MNG-6206,
>>  >> I could try to make some time for it—I feel strongly enough about 
>>this
>>  >> issue.
>>  >>
>>  >> Thanks for any insight, workarounds, counterarguments, agreement.
>>  >> (Especially if you agree: please speak up, so the core Maven devs 
>>know
>>  I'm
>>  >> not just an outlier here!)
>>  >>
>>  >> Regards,
>>  >> Curtis
>>  >>
>>  >> [1] https://github.com/ctrueden/jrun
>>  >>
>>  >> --
>>  >> Curtis Rueden
>>  >> LOCI software architect - https://loci.wisc.edu/software
>>  >> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>  >>
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>  For additional commands, e-mail: users-help@maven.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message