Quantcast

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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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 <[hidden email]>
wrote:

> Hi,
>
>
> On 11/04/17 23:38, Stephen Connolly wrote:
>
>> On Tue 11 Apr 2017 at 20:55, Curtis Rueden <[hidden email]> 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 <
>>> [hidden email]> wrote:
>>>
>>> On Tue 11 Apr 2017 at 16:02, Curtis Rueden <[hidden email]> 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 <
>>>>>
>>>> [hidden email]
>>>>
>>>>>
>>>>>> 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:[hidden email]]
>>>>>> Sent: Monday, April 10, 2017 10:39 AM
>>>>>> To: Maven Users List <[hidden email]>
>>>>>> Subject: Re: dependency question
>>>>>>
>>>>>> On Mon, Apr 10, 2017 at 8:18 AM, Magnanao, Hector
>>>>>> <[hidden email]> 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:[hidden email]]
>>>>>>> Sent: Friday, April 7, 2017 10:50 AM
>>>>>>> To: Maven Users List <[hidden email]>
>>>>>>> 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 <
>>>>>>>>>
>>>>>>>> [hidden email]>
>>>>>
>>>>>> 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:[hidden email]]
>>>>>>>>> Sent: Thursday, April 6, 2017 2:27 PM
>>>>>>>>> To: Maven Users List <[hidden email]>
>>>>>>>>> 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 <
>>>>>>>>>>
>>>>>>>>> [hidden email]>
>>>>>
>>>>>> 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: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Loading...