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