Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-05-01 Thread Curtis Rueden 
Hi Charles & everyone,

> To prevent SNAPSHOT churn you can use a plugin like
> exists-maven-plugin
> (https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html
> )
> to prevent re-releasing unchanged artifacts.

Thanks for the suggestion. I think exists-maven-plugin is really useful for
some scenarios.

However, I want to comment that I think one should not use
exists-maven-plugin in this way to address a symptom—400 forbidden errors
when redeploying same version to remote repository—rather than the root
problem of having two commits with the same release version number. With
this scheme, any time you build a commit from the history including the
"install" phase (e.g., if testing something with "git bisect"), you may end
up overwriting the release version in your local repository cache with
something which is _not_ actually the release build of the component. So I
think it is dangerous to lean on exists-maven-plugin in this way. I
actually _want_ the build to fail in the CI at the deploy step, to give me
a heads up that there are two commits like this, so that the problem can be
fixed before even more commits are made at that same version number.

Regards,
Curtis

--
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 9:09 PM, Charles Honton  wrote:

> To prevent SNAPSHOT churn you can use a plugin like exists-maven-plugin (
> https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html <
> https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html>) to
> prevent re-releasing unchanged artifacts.
>
> chas
>
> > On Apr 24, 2017, at 1:52 PM, Curtis Rueden  wrote:
> >
> > because every release concludes
> > with a "bump to next development cycle" commit
>
>

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread Charles Honton 
To prevent SNAPSHOT churn you can use a plugin like exists-maven-plugin 
(https://chonton.github.io/exists-maven-plugin/0.0.2/plugin-info.html 
) to 
prevent re-releasing unchanged artifacts.

chas

> On Apr 24, 2017, at 1:52 PM, Curtis Rueden  wrote:
> 
> because every release concludes
> with a "bump to next development cycle" commit

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread mike digioia 
SUBMIT ME

On Mon, Apr 24, 2017 at 1:52 PM, Curtis Rueden  wrote:

> Hi Karl,
>
> Thanks very much for your reply!
>
> > Not only for displaying...you can also use it to update them...
>
> Understood. But I actually don't want to always auto-update everything to
> latest releases. The point of the BOM is that the versions it references
> have been tested to work together. Especially for things like major
> breaking releases of third party components, we need to do those updates
> manually and carefully.
>
> > 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...
>
> Right. That is actually what our tooling was doing until now. However, the
> process is laborious and slow. For each of our ~200 first-party components
> whose GAVs are listed in the BOM, the tooling needs to:
>
> - Fetch the POM for the GAV in question.
> - Extract the  section from the (effective) POM.
> - Clone the indicated SCM locally (in our case: always a Git repository
> from GitHub).
> - Do the relevant git command(s) to decide whether master has really
> changed since the last release.
>
> It's the cloning step that is especially expensive here, even if you limit
> cloning depth.
>
> I came up with a (I hope) much simpler solution which does not rely on the
> SCM at all, but only on Maven and our remote repository manager:
>
> 1) Extract the component's versions/release tag from maven-metadata.xml of
> the relevant GA in the remote MRM.
> 2) Check the timestamp of that release's POM artifact in the remote MRM.
> 3) Extract the versions/lastUpdated tag from maven-metadata.xml of the
> relevant GA in the remote MRM.
> 4) Compare the release timestamp vs. the lastUpdated timestamp; if >30min
> different, real changes have occurred since the last release.
>
> In this way, I no longer have to clone 200 repositories just to confirm
> what the MRM already stores in its metadata. I also do not rely on the
>  tag being correct, nor even that the artifact's sources reside in
> public SCM anywhere. So I can now report on third-party components as well.
>
> Furthermore, I am in the process of updating step 1 above to lean on "mvn
> -U -s settings.xml -Dverbose=true versions:display-dependency-updates"
> instead, since that also rolls in an update of our MRM's public content
> group including everything it proxies. (The settings.xml here defines our
> MRM as the sole mirror.) So then, the MRM metadata is (fingers crossed!)
> guaranteed to be up-to-date during steps 2-4.
>
> > 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...
>
> I am writing a shell script right now, but may be willing to contribute
> code to a plugin if this sort of thing is useful enough to a sufficient
> number of people.
>
> > 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 ?
>
> My point is that if I run "mvn -U -DallowSnapshots=true
> versions:display-dependency-updates" it will always tell me that
> everything
> has a newer snapshot version available, because every release concludes
> with a "bump to next development cycle" commit, which triggers a CI build
> that deploys a newer artifact than the release artifact. What I need to
> know is whether a new version (snapshot or otherwise) has been pushed
> _after some reasonable grace period_ since the last release version was
> cut. The lastUpdated tag of the maven-metadata.xml is actually perfect for
> this, as described above.
>
> > Can you list some of those use cases please which you are believe in ?
>
> Sure! My two most major ones right now are:
>
> - My jrun script (https://github.com/ctrueden/jrun) bootstraps a runtime
> environment for a given "endpoint" which is defined as a GAV, or even
> simply a GA with V defaulting to RELEASE. If RELEASE were to stop working,
> I would have to implement special code to discern the latest release in
> some other way—I guess by checking the remote's maven-metadata.xml and
> looking at the versions/release tag myself.
>
> - We use LATEST to override the version of components—including whole
> sub-collections of components at a time—for easier SNAPSHOT coupling for
> local development between components. E.g., in Eclipse, the dependency will
> automatically switch from being a library/JAR dependency to being a project
> dependency. See this profile for an example: https://github.com/
> scijava/pom-scijava/blob/pom-scijava-14.0.0/pom.xml#L2634-L2683. See also
> http://imagej.net/Architecture#Using_snapshot_couplings_during_development
> .
> If LATEST goes away, I guess I can use [0,) everywhere, but that is pretty
> non-intuitive by comparison.
>
> My intuition

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread Curtis Rueden 
Hi Karl,

Thanks very much for your reply!

> Not only for displaying...you can also use it to update them...

Understood. But I actually don't want to always auto-update everything to
latest releases. The point of the BOM is that the versions it references
have been tested to work together. Especially for things like major
breaking releases of third party components, we need to do those updates
manually and carefully.

> 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...

Right. That is actually what our tooling was doing until now. However, the
process is laborious and slow. For each of our ~200 first-party components
whose GAVs are listed in the BOM, the tooling needs to:

- Fetch the POM for the GAV in question.
- Extract the  section from the (effective) POM.
- Clone the indicated SCM locally (in our case: always a Git repository
from GitHub).
- Do the relevant git command(s) to decide whether master has really
changed since the last release.

It's the cloning step that is especially expensive here, even if you limit
cloning depth.

I came up with a (I hope) much simpler solution which does not rely on the
SCM at all, but only on Maven and our remote repository manager:

1) Extract the component's versions/release tag from maven-metadata.xml of
the relevant GA in the remote MRM.
2) Check the timestamp of that release's POM artifact in the remote MRM.
3) Extract the versions/lastUpdated tag from maven-metadata.xml of the
relevant GA in the remote MRM.
4) Compare the release timestamp vs. the lastUpdated timestamp; if >30min
different, real changes have occurred since the last release.

In this way, I no longer have to clone 200 repositories just to confirm
what the MRM already stores in its metadata. I also do not rely on the
 tag being correct, nor even that the artifact's sources reside in
public SCM anywhere. So I can now report on third-party components as well.

Furthermore, I am in the process of updating step 1 above to lean on "mvn
-U -s settings.xml -Dverbose=true versions:display-dependency-updates"
instead, since that also rolls in an update of our MRM's public content
group including everything it proxies. (The settings.xml here defines our
MRM as the sole mirror.) So then, the MRM metadata is (fingers crossed!)
guaranteed to be up-to-date during steps 2-4.

> 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...

I am writing a shell script right now, but may be willing to contribute
code to a plugin if this sort of thing is useful enough to a sufficient
number of people.

> 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 ?

My point is that if I run "mvn -U -DallowSnapshots=true
versions:display-dependency-updates" it will always tell me that everything
has a newer snapshot version available, because every release concludes
with a "bump to next development cycle" commit, which triggers a CI build
that deploys a newer artifact than the release artifact. What I need to
know is whether a new version (snapshot or otherwise) has been pushed
_after some reasonable grace period_ since the last release version was
cut. The lastUpdated tag of the maven-metadata.xml is actually perfect for
this, as described above.

> Can you list some of those use cases please which you are believe in ?

Sure! My two most major ones right now are:

- My jrun script (https://github.com/ctrueden/jrun) bootstraps a runtime
environment for a given "endpoint" which is defined as a GAV, or even
simply a GA with V defaulting to RELEASE. If RELEASE were to stop working,
I would have to implement special code to discern the latest release in
some other way—I guess by checking the remote's maven-metadata.xml and
looking at the versions/release tag myself.

- We use LATEST to override the version of components—including whole
sub-collections of components at a time—for easier SNAPSHOT coupling for
local development between components. E.g., in Eclipse, the dependency will
automatically switch from being a library/JAR dependency to being a project
dependency. See this profile for an example: https://github.com/
scijava/pom-scijava/blob/pom-scijava-14.0.0/pom.xml#L2634-L2683. See also
http://imagej.net/Architecture#Using_snapshot_couplings_during_development.
If LATEST goes away, I guess I can use [0,) everywhere, but that is pretty
non-intuitive by comparison.

My intuition also strongly tells me that there are other valid use cases
here; I can think harder about it if you are still not convinced. Maybe
others here can respond as well with their use cases?

Moreover, I don't see the value of discontinuing these special keywords. It

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread Karl Heinz Marbaise 

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  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  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 

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

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread Richard Sand 
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" <ctrue...@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 <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?
 >
 > 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.

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread Curtis Rueden 
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  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  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 
> 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:

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread jieryn 
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  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  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

Re: Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-24 Thread Curtis Rueden 
> 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  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
>

Please officially support RELEASE and LATEST (was: Re: dependency question)

2017-04-13 Thread Curtis Rueden 
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


On Tue, Apr 11, 2017 at 4:56 PM, Karl Heinz Marbaise 
wrote:

> Hi,
>
>
> On 11/04/17 23:38, Stephen Connolly wrote:
>
>> On Tue 11 Apr 2017 at 20:55, Curtis Rueden  wrote:
>>
>> Hi Stephen,
>>>
>>> There is a special version keyword LATEST which means the very newest
> version, snapshot or otherwise. And RELEASE means the newest release
> (non-SNAPSHOT) version.
>

 Support for those were dropped in Maven 3

>>>
>>> By "support" do you mean "social support" as opposed to technical
>>> functionality?
>>>
>>
>>
>> They were supposed to be removed.
>>
>> If they are working now, that's a bug
>>
>
> Unfortunately they are working ;-(..
>
> https://issues.apache.org/jira/browse/MNG-6206
>
>
> Kind regards
> Karl Heinz Marbaise
>
>
>>
>>
>>> Because they are still present in the codebase, and they still work
>>> technically:
>>>https://github.com/apache/maven/blob/master/maven-
>>> resolver-provider/src/main/java/org/apache/maven/repository/internal/
>>> DefaultVersionResolver.java#L188-L197
>>>
>>> Regards,
>>> Curtis
>>>
>>> --
>>> Curtis Rueden
>>> LOCI software architect - https://loci.wisc.edu/software
>>> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>>>
>>>
>>> On Tue, Apr 11, 2017 at 2:44 PM, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
>>> On Tue 11 Apr 2017 at 16:02, Curtis Rueden  wrote:

 Hi Hector,
>
> This is fine as long as the dependency is always set to
>>
> x.y.z-Snapshot
>>>
 and the dependency is always overwritten this way.  What if the
>> producer produces x.y.z.1-Snapshot, x.y.z.2-Snapshot,
>>
> x.y.z.3-Snapshot
>>>
 and I want the dependent build to always get the latest in this case,
>> x.y.z.3-Snapshot ?
>>
>
> There is a special version keyword LATEST which means the very newest
> version, snapshot or otherwise. And RELEASE means the newest release
> (non-SNAPSHOT) version.
>


 Support for those were dropped in Maven 3

 *and* anyway they were only for *plugin* versions because the plugin
 version does not support ranges.

 For dependency versions, define a range


>
> Similar to version ranges, Maven will have to ask the remote repository
> about the latest known version in these cases, and will then use that.
>
> I want to emphasize, as others have mentioned, that using any of these
> strategies will result in _irreproducible builds_. That is, your code
>
 might

> build today, and then the same code will fail to build in the future,
> because the versions will resolve differently. The only way (I know of)
>
 to

> achieve reproducible builds is to use fixed release versions, always.
>
> Regards,
> Curtis
>
> --
> Curtis Rueden
> LOCI software architect - https://loci.wisc.edu/software
> ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
>
>
> On Tue, Apr 11, 2017 at 9:57 AM, Magnanao, Hector <
>