You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Curtis Rueden <ct...@wisc.edu> on 2017/04/13 15:51:27 UTC

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

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 <kh...@gmx.de>
wrote:

> Hi,
>
>
> On 11/04/17 23:38, Stephen Connolly wrote:
>
>> On Tue 11 Apr 2017 at 20:55, Curtis Rueden <ct...@wisc.edu> 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.connolly@gmail.com> wrote:
>>>
>>> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <ct...@wisc.edu> 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 <
>>>>>
>>>> hector.magnanao@sap.com
>>>>
>>>>>
>>>>>> wrote:
>>>>>
>>>>> 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 ? The difference with this scenario is that the
>>>>>>
>>>>> producer
>>>>
>>>>> will always have a new build number.
>>>>>> As for your solution of using the range,  do I always have to change
>>>>>>
>>>>> the
>>>>
>>>>> pom file in the dependent build whenever a new build is produced by
>>>>>>
>>>>> the
>>>
>>>> producer ?
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Benson Margulies [mailto:bimargulies@gmail.com]
>>>>>> Sent: Monday, April 10, 2017 10:39 AM
>>>>>> To: Maven Users List <us...@maven.apache.org>
>>>>>> Subject: Re: dependency question
>>>>>>
>>>>>> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
>>>>>> <he...@sap.com> wrote:
>>>>>>
>>>>>>> I'm still a little confused about the answers I'm getting.  So, if
>>>>>>>
>>>>>> build
>>>>>
>>>>>> A is being updated with a new build number(even for a snapshot), and
>>>>>>
>>>>> build
>>>>>
>>>>>> B has it as a dependency in it's pom.file, how does the pom file in
>>>>>>
>>>>> Build B
>>>>>
>>>>>> need to look like in the dependency section so that it does get the
>>>>>>
>>>>> latest
>>>>>
>>>>>> snapshot build of build A ?
>>>>>>
>>>>>> This conversation seems to keep mixing up SNAPSHOT version processing
>>>>>> with various conventions for using version ranges.
>>>>>>
>>>>>> If the producer produces x.y.z-SNAPSHOT, and the consumer declares a
>>>>>> dependency on x.y.z-SNAPSHOT, every build of the consumer will go out
>>>>>> to the repositories to look for the latest snapshot build.
>>>>>>
>>>>>> Snapshots have risks and do not provide a repeatable build. Then
>>>>>> again, neither do ranges.
>>>>>>
>>>>>> If you don't want to use snapshots, then you write the dependency in
>>>>>> the consumer with a range
>>>>>>
>>>>>>     (1.0-2.0]
>>>>>>
>>>>>> or whatever makes sense. This will cause builds of the consumer to go
>>>>>> out to repositories and try to find the newest version within the
>>>>>> range. it's up to you to bump the version in the producer, manually
>>>>>>
>>>>> or
>>>
>>>> with the maven-release-plugin.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Scenario:
>>>>>>>
>>>>>>> Build A has 3 builds in it with names 1-Snapshot, 2-snapshot,
>>>>>>>
>>>>>> 3-snapshot
>>>>>
>>>>>> and they are all being uploaded to a repository.
>>>>>>
>>>>>>>
>>>>>>> What will the pom file in build B look like so that the next time
>>>>>>>
>>>>>> build
>>>>
>>>>> B is executed,  3-snapshot for build A will be picked up ?
>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
>>>>>>> Sent: Friday, April 7, 2017 10:50 AM
>>>>>>> To: Maven Users List <us...@maven.apache.org>
>>>>>>> Subject: Re: dependency question
>>>>>>>
>>>>>>> Hi Russlel,
>>>>>>> On 07/04/17 17:29, Russell Gold wrote:
>>>>>>>
>>>>>>> That’s the way it works: when you specify a snapshot, it takes the
>>>>>>>>
>>>>>>> latest.
>>>>>>
>>>>>>>
>>>>>>> This is not 100% true, cause it depends on the update policy you
>>>>>>>
>>>>>> have
>>>
>>>> defined in your settings either explicit or by default the updates
>>>>>>>
>>>>>> will
>>>>
>>>>> be checked every 24 hours...
>>>>>>>
>>>>>>> If you like to force this you can use mvn -U ...or define a
>>>>>>>
>>>>>> different
>>>
>>>> updatePolicy in your settings.xml for the appropriate repository.
>>>>>>>
>>>>>>> By using mvn -U you make sure for running this build Maven will
>>>>>>>
>>>>>> check
>>>
>>>> if
>>>>>
>>>>>> there are newer SNAPSHOT version available for dependencies which
>>>>>>>
>>>>>> have
>>>>
>>>>> defined a SNAPSHOT version....
>>>>>>>
>>>>>>> This is working for a single module project...but if you have a
>>>>>>>
>>>>>> multi
>>>
>>>> module build (Project C: A1 build before A2) which takes for
>>>>>>>
>>>>>> example
>>>
>>>> 5
>>>>
>>>>> minutes to build ...this is no longer 100% true...
>>>>>>>
>>>>>>> Now let us assume you have another project B which dependends on
>>>>>>>
>>>>>> two
>>>
>>>> different artifacts (A1, A2) of Project C ...this means in
>>>>>>>
>>>>>> consequence
>>>>
>>>>> those artifacts are build at two different times...
>>>>>>>
>>>>>>> This means it could happen that your build of Project B consumes A2
>>>>>>>
>>>>>> from
>>>>>
>>>>>> build #10 but A1 from build #9 ...
>>>>>>>
>>>>>>>
>>>>>>> In practical it usually works without any issue using the mvn -U
>>>>>>>
>>>>>> ...but
>>>>
>>>>> you should be aware of this issue...
>>>>>>>
>>>>>>>
>>>>>>> The only solution which I have found to make 100% sure is to use
>>>>>>>
>>>>>> the
>>>
>>>> output during the build of the project A and use those parsed
>>>>>>> informations about the SNAPSHOT versions and inject them into my
>>>>>>>
>>>>>> current
>>>>>
>>>>>> build ...(https://github.com/khmarbaise/deployment-recorder-
>>>>>>>
>>>>>> extension
>>>>
>>>>> not ready yet)...
>>>>>>>
>>>>>>> Kind regards
>>>>>>> Karl Heinz Marbaise
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> There are some corner cases where it won’t. I think it only checks
>>>>>>>>
>>>>>>> for
>>>>
>>>>> a new snapshot every few hours or so, so if you are putting out a lot
>>>>>>
>>>>> you
>>>>
>>>>> might conceivably miss one. You can reset that if you need to
>>>>>>
>>>>>>> .
>>>>>>>>
>>>>>>>>> On Apr 7, 2017, at 11:27 AM, Magnanao, Hector <
>>>>>>>>>
>>>>>>>> hector.magnanao@sap.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>> If the builds for A are always getting a unique build number as a
>>>>>>>>>
>>>>>>>> snapshot build,  how am I sure that B will always get the latest
>>>>>>
>>>>> snapshot
>>>>
>>>>> of A ?  Is there a way to name the A snapshot builds with a unique
>>>>>>
>>>>> build
>>>>
>>>>> number each time for this scenario.
>>>>>>
>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Russell Gold [mailto:russell.gold@oracle.com]
>>>>>>>>> Sent: Thursday, April 6, 2017 2:27 PM
>>>>>>>>> To: Maven Users List <us...@maven.apache.org>
>>>>>>>>> Subject: Re: dependency question
>>>>>>>>>
>>>>>>>>> The simplest way is simply to use a snapshot version of A. That
>>>>>>>>>
>>>>>>>> way B
>>>>
>>>>> will always use the latest snapshot. When you finally release A, you
>>>>>>
>>>>> can
>>>>
>>>>> have B point to the released version instead of the snapshot.
>>>>>>
>>>>>>>
>>>>>>>>> On Apr 6, 2017, at 2:52 PM, Magnanao, Hector <
>>>>>>>>>>
>>>>>>>>> hector.magnanao@sap.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>> I have to 2 java projects a and b in maven.  The B project uses
>>>>>>>>>>
>>>>>>>>> the
>>>>
>>>>> A
>>>>>
>>>>>> build as a dependency.  How do I ensure the whenever the A project
>>>>>>
>>>>> has
>>>
>>>> a
>>>>
>>>>> new build,  the B project will always use that latest build in A.  A
>>>>>>
>>>>> is
>>>
>>>> being built with a unique build number each time it gets built.  So
>>>>>>
>>>>> is
>>>
>>>> A
>>>>
>>>>> has build # 10 as the newest build,  the B project has to use build
>>>>>>
>>>>> #10
>>>
>>>> of
>>>>>
>>>>>> A.
>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hector Magnanao Jr.
>>>>>>>>>> SCM Analyst
>>>>>>>>>> SAP Fieldglass
>>>>>>>>>> Skype:  (331) 702-6142
>>>>>>>>>> Mobile:  (847) 857-8401
>>>>>>>>>> Email: Hector.magnanao@sap.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: Please officially support RELEASE and LATEST

Posted by Rick Huff <rh...@austin.utexas.edu>.
Curtis,

For what it's worth, I completely agree.  This is a broken part of Maven 
that we've learned to work around because of a theoretical benefit.  I 
can agree with needing to specify a version or version range for other 
dependencies, but for my code in non-Prod environments -- I want 
LATEST.  Always.

I looked into this about three(?) years ago and it looked a bit like a 
religious battle, so I just declared defeat.  I think there was a ticket 
created that was closed "Won't Fix".

We have Nexus rebuild it's metadata for the affected repositories and 
this adjusts the LATEST tag.

I started coding an optional parameter for Maven to be used locally and 
I think the code's 90% there, but I had a series of problems using Maven 
to build Maven and had to do other work and never got back to it.

On 04/24/2017 11:58 AM, 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 <ct...@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\u2014I 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
>>

-- 
Rick Huff, Principal Software Engineer
Identity and Access Management Team
ITS Applications, The University of Texas at Austin

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

Posted by Richard Sand <rs...@idfconnect.com>.
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" <ct...@wisc.edu>
To: "Maven Users List" <us...@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 <ji...@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 <ct...@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 <ct...@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

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

Posted by mike digioia <mp...@gmail.com>.
SUBMIT ME

On Mon, Apr 24, 2017 at 1:52 PM, Curtis Rueden <ct...@wisc.edu> 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 <scm> 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
> <scm> 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
> breaks backwards compatibility for no technical or social advantage that I
> can see. I am not trying to be difficult—if there was a rationale written
> somewhere for why these keywords are bad, I would love to see it!—but the
> only rationale I have actually found are vague and brief statements
> repeated second-hand that these keywords are somehow harmful to
> reproducibility. But as I argued in this thread's first post:
> reproducibility is still in danger thanks to version ranges and snapshots.
> The better solution here to encourage reproducibility is to actually
> encourage it via warnings—see below.
>
> > And what do you think is constructive to address the problem of
> > reproducibility ?
>
> Generally speaking, I think it should be illegal to deploy release versions
> whose dependencies result in irreproducible builds. To enforce that, we
> went so far as to write a new enforcer rule (part of
> org.scijava:scijava-maven-plugin):
>
> https://github.com/scijava/scijava-maven-plugin/blob/
> scijava-maven-plugin-1.0.0/src/main/java/org/scijava/
> maven/plugin/enforcer/
> RequireReproducibleBuilds.java#L53-L69
> https://github.com/scijava/scijava-maven-plugin/blob/
> scijava-maven-plugin-1.0.0/src/main/java/org/scijava/
> maven/plugin/SnapshotFinder.java#L46-L61
>
> This rule fails the build if it finds a SNAPSHOT parent, or any SNAPSHOT
> dependencies, recursively throughout the dependency tree. Because of this,
> we actually found some problematic releases on Central which have snapshot
> dependencies deep in their dependency trees. I cannot recall whether this
> rule currently fails the build if there are any version ranges, but I think
> it ought to do so.
>
> Our projects all require reproducible builds always on the master branch.
> Among other benefits, this allows "git bisect" to work reliably. See
> http://imagej.net/Architecture#Reproducible_builds for further discussion.
>
> I think that by default, Maven should warn if a build is irreproducible
> like this. That way, people new to Maven will be less likely to suffer pain
> later due to ignorance of this issue. People need to know when their builds
> are vulnerable. As things stand, I think many people just use a "snapshots
> all the time" approach because it is initially easier, without realizing
> how this will burn them in the future.
>
> That said, I also think there should be a property to disable the warning,
> since there are valid use cases (see above) for using rolling versions.
>
> 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 2:24 PM, Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
>
> > 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/
> ma
> > ster)...
> >
> > 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 <ji...@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 <ct...@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 <ct...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

Re: generate a POM with dependencies only?

Posted by Maxim Solodovnik <so...@gmail.com>.
I would like to ask related question here

Is it possible to get dependency version?
I'm creating one big jar for all dependencies using assembly plugin, but
org.bouncycastle:bcprov-jdk15on cannot be repacked
So I need to manually track it's version :(
Would be great if I can get bcprov version and automatically set it using
xslt transformation

On Thu, May 4, 2017 at 1:39 AM, Richard Sand <rs...@idfconnect.com> wrote:

> Woohoo!
>
> Thanks Robert!
>
> -Richard
>
>
>
>
> ------ Original Message ------
> From: "Robert Scholte" <rf...@apache.org>
> To: "Maven Users List" <us...@maven.apache.org>
> Sent: 5/3/2017 2:38:56 PM
> Subject: Re: generate a POM with dependencies only?
>
> Yes, http://www.mojohaus.org/flatten-maven-plugin/
>>
>> On Wed, 03 May 2017 20:37:52 +0200, Richard Sand <rs...@idfconnect.com>
>> wrote:
>>
>> Is there a plugin/goal that will generate a "reduced" POM for a project
>>> that only contains the dependencies, but none of the other build/profile
>>> or any other tags?
>>>
>>> May sound like a strange ask - but the scenario I'm facing is that I'm
>>> building a particular set of jars/wars/zips (using assembly plugin), and
>>> the POMs for these artifacts all rely on a heirarchy of parent POMs  which
>>> have many dependencyManagement, build, and profile elements. My  customers
>>> have their own internal Maven repositories, and are not  connecting to my
>>> company's private repos, so their ask is that I provide  the POM for each
>>> artifact we distribute in the zip file. So basically I  want to give them a
>>> stripped down POM that only has the dependencies in  it so that they can
>>> upload the artifacts into their internal repos and  include them in their
>>> projects. They will never actually be building our  artifacts.
>>>
>>> Best regards,
>>>
>>> Richard
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
WBR
Maxim aka solomax

Re: generate a POM with dependencies only?

Posted by Richard Sand <rs...@idfconnect.com>.
Woohoo!

Thanks Robert!

-Richard



------ Original Message ------
From: "Robert Scholte" <rf...@apache.org>
To: "Maven Users List" <us...@maven.apache.org>
Sent: 5/3/2017 2:38:56 PM
Subject: Re: generate a POM with dependencies only?

>Yes, http://www.mojohaus.org/flatten-maven-plugin/
>
>On Wed, 03 May 2017 20:37:52 +0200, Richard Sand <rs...@idfconnect.com> 
>  wrote:
>
>>Is there a plugin/goal that will generate a "reduced" POM for a 
>>project  that only contains the dependencies, but none of the other 
>>build/profile  or any other tags?
>>
>>May sound like a strange ask - but the scenario I'm facing is that I'm 
>>  building a particular set of jars/wars/zips (using assembly plugin), 
>>and  the POMs for these artifacts all rely on a heirarchy of parent 
>>POMs  which have many dependencyManagement, build, and profile 
>>elements. My  customers have their own internal Maven repositories, 
>>and are not  connecting to my company's private repos, so their ask is 
>>that I provide  the POM for each artifact we distribute in the zip 
>>file. So basically I  want to give them a stripped down POM that only 
>>has the dependencies in  it so that they can upload the artifacts into 
>>their internal repos and  include them in their projects. They will 
>>never actually be building our  artifacts.
>>
>>Best regards,
>>
>>Richard
>>
>>
>>---------------------------------------------------------------------
>>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
>


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

Re: generate a POM with dependencies only?

Posted by Robert Scholte <rf...@apache.org>.
Yes, http://www.mojohaus.org/flatten-maven-plugin/

On Wed, 03 May 2017 20:37:52 +0200, Richard Sand <rs...@idfconnect.com>  
wrote:

> Is there a plugin/goal that will generate a "reduced" POM for a project  
> that only contains the dependencies, but none of the other build/profile  
> or any other tags?
>
> May sound like a strange ask - but the scenario I'm facing is that I'm  
> building a particular set of jars/wars/zips (using assembly plugin), and  
> the POMs for these artifacts all rely on a heirarchy of parent POMs  
> which have many dependencyManagement, build, and profile elements. My  
> customers have their own internal Maven repositories, and are not  
> connecting to my company's private repos, so their ask is that I provide  
> the POM for each artifact we distribute in the zip file. So basically I  
> want to give them a stripped down POM that only has the dependencies in  
> it so that they can upload the artifacts into their internal repos and  
> include them in their projects. They will never actually be building our  
> artifacts.
>
> Best regards,
>
> Richard
>
>
> ---------------------------------------------------------------------
> 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

generate a POM with dependencies only?

Posted by Richard Sand <rs...@idfconnect.com>.
Is there a plugin/goal that will generate a "reduced" POM for a project 
that only contains the dependencies, but none of the other build/profile 
or any other tags?

May sound like a strange ask - but the scenario I'm facing is that I'm 
building a particular set of jars/wars/zips (using assembly plugin), and 
the POMs for these artifacts all rely on a heirarchy of parent POMs 
which have many dependencyManagement, build, and profile elements. My 
customers have their own internal Maven repositories, and are not 
connecting to my company's private repos, so their ask is that I provide 
the POM for each artifact we distribute in the zip file. So basically I 
want to give them a stripped down POM that only has the dependencies in 
it so that they can upload the artifacts into their internal repos and 
include them in their projects. They will never actually be building our 
artifacts.

Best regards,

Richard


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

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

Posted by Curtis Rueden <ct...@wisc.edu>.
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
> <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 <ch...@honton.org> 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 <ct...@wisc.edu> wrote:
> >
> > because every release concludes
> > with a "bump to next development cycle" commit
>
>

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

Posted by Charles Honton <ch...@honton.org>.
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 <ct...@wisc.edu> wrote:
> 
> because every release concludes
> with a "bump to next development cycle" commit

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

Posted by Curtis Rueden <ct...@wisc.edu>.
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 <scm> 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
<scm> 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
breaks backwards compatibility for no technical or social advantage that I
can see. I am not trying to be difficult—if there was a rationale written
somewhere for why these keywords are bad, I would love to see it!—but the
only rationale I have actually found are vague and brief statements
repeated second-hand that these keywords are somehow harmful to
reproducibility. But as I argued in this thread's first post:
reproducibility is still in danger thanks to version ranges and snapshots.
The better solution here to encourage reproducibility is to actually
encourage it via warnings—see below.

> And what do you think is constructive to address the problem of
> reproducibility ?

Generally speaking, I think it should be illegal to deploy release versions
whose dependencies result in irreproducible builds. To enforce that, we
went so far as to write a new enforcer rule (part of
org.scijava:scijava-maven-plugin):

https://github.com/scijava/scijava-maven-plugin/blob/
scijava-maven-plugin-1.0.0/src/main/java/org/scijava/maven/plugin/enforcer/
RequireReproducibleBuilds.java#L53-L69
https://github.com/scijava/scijava-maven-plugin/blob/
scijava-maven-plugin-1.0.0/src/main/java/org/scijava/
maven/plugin/SnapshotFinder.java#L46-L61

This rule fails the build if it finds a SNAPSHOT parent, or any SNAPSHOT
dependencies, recursively throughout the dependency tree. Because of this,
we actually found some problematic releases on Central which have snapshot
dependencies deep in their dependency trees. I cannot recall whether this
rule currently fails the build if there are any version ranges, but I think
it ought to do so.

Our projects all require reproducible builds always on the master branch.
Among other benefits, this allows "git bisect" to work reliably. See
http://imagej.net/Architecture#Reproducible_builds for further discussion.

I think that by default, Maven should warn if a build is irreproducible
like this. That way, people new to Maven will be less likely to suffer pain
later due to ignorance of this issue. People need to know when their builds
are vulnerable. As things stand, I think many people just use a "snapshots
all the time" approach because it is initially easier, without realizing
how this will burn them in the future.

That said, I also think there should be a property to disable the warning,
since there are valid use cases (see above) for using rolling versions.

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 2:24 PM, Karl Heinz Marbaise <kh...@gmx.de>
wrote:

> 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/ma
> ster)...
>
> 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 <ji...@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 <ct...@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 <ct...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

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

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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 <ji...@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 <ct...@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 <ct...@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\u2014I 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

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

Posted by Curtis Rueden <ct...@wisc.edu>.
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 <ji...@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 <ct...@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 <ct...@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
>
>

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

Posted by jieryn <ji...@gmail.com>.
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 <ct...@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 <ct...@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

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

Posted by Curtis Rueden <ct...@wisc.edu>.
> 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 <ct...@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
>