Hi,
On 24/04/17 19:46, Curtis Rueden wrote:
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!)
Not only for displaying...you can also use it to update them...
Yes I know there are issues in that plugin (I'm currently working on an
larger update
https://github.com/mojohaus/versions-maven-plugin/commits/master)...
Also updating to newer release versions can be done with that and
correctly checked in into version control.
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"
Maybe I misunderstand a thing here but the first part can be answered by
using your version control? Make a diff between latest release tag and
the current trunk/master ? If a component needs a release is something
which only can being answered by a human...
But might it be a good idea for a plugin ? If we could get more concrete
I'm willing to implement such things if this will help...
> -- 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.
What is the problem with that? Your repository manager should be
configured in that way that SNAPSHOT's will automatically being removed
after a time ?
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.
Can you list some of those use cases please which you are believe in ?
And what do you think is constructive to address the problem of
reproducibility ?
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 <jie...@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 <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?
You can simply let run versions-maven-plugin get a report about updates
or just let update versions-maven-plugin the pom and if you checkin the
pom the version control will find out if something has changed or not ?
Apart from that maybe I misunderstand a thing here, but using the
versions-maven-plugin is custom tooling for you?
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?
I agree fully to that, cause I've learned that using version ranges has
the same problem as you already mentioned. I would like to deprecate the
version ranges as well....
The SNAPSHOT's a very usefull but you can run in problems too...yes...
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.
My experience is that they simply don't understand the consequence using
LATEST/RELEASE nor the usage of version ranges...and often astonished of
build failures later and having problems reproducing builds...
Kind regards
Karl Heinz Marbaise
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
