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
