Re: Reproducibility versus ranges

The idea I had in versions-m-p was to put XML PI with the original range beside the resolved value so that the range can be set back post prepare (see completionGoals) Oh where is my elusive time On Monday 26 October 2015, Bernd Eckenfels wrote: > Am Mon, 26 Oct 2015

Re: Reproducibility versus ranges

Conflicting ranges should break the build, and would break it in the first place. If it released OK in the first place with bounded ranges and your repo still has the artifacts, it can be released again. If the old ranges now won't release, you have a conflict to resolve in your tree. On Tue, Oct

Re: Reproducibility versus ranges

Hello, you dont need to remeber the ranges if you will not touch the ranged pom on the trunk/master/devel branch, only the release tags/commits/branches have that expanded version. (Just like the version tag, its the only pom incarnation with a non-snapshot one). Gruss Bernd Am Mon, 26 Oct 2015

Re: Reproducibility versus ranges

Ahh, but we do, everything is ranged! As explained, externals are ranged via composites in between to isolate us from their whims, eg spring, etc. On Tue, Oct 27, 2015 at 2:13 PM, Bernd Eckenfels wrote: > If you do not release POMs with ranges there are no poms with

Re: Reproducibility versus ranges

In our case, we don't want the original range back exactly, we want the current version of that, ie, higher lower bound to currently released things. Do not forget the transient ranges that need to be locked in our modified pom, either. Without this any tooling would be severely limited in use.

Re: Reproducibility versus ranges

False, you've locked to a specific version of a thing which depends on ranges. This does not lock down those ranges, as it doesn't have enough information to do that. On Tue, Oct 27, 2015 at 1:42 PM, Bernd Eckenfels wrote: > Hello, > > if you lock down ranges on release

Re: Reproducibility versus ranges

Hello, if you lock down ranges on release your dependencies will also have no ranges and you do not need to lock them down transitively. BTW: I really think tis is a topic for the maven-user list. Gruss Bernd Am Tue, 27 Oct 2015 11:21:09 +1300 schrieb Fred Cooke : > In

Re: Reproducibility versus ranges

Shoot me for not giving the full response. Release.properties is too hacky to contain all the info to be restored/restored with modifications. Never mind that if you lost the release.properties file and had to resume elsewhere you might get stuck. So in my view you need to stash the original

Re: Reproducibility versus ranges

If you do not release POMs with ranges there are no poms with ranges to depend on. Am Tue, 27 Oct 2015 14:03:01 +1300 schrieb Fred Cooke : > False, you've locked to a specific version of a thing which depends on > ranges. This does not lock down those ranges, as it doesn't

Re: Reproducibility versus ranges

You're right, this is the problem. What would need to be done is the version to be fixed for the release version (tag). /Anders (mobile) Den 26 okt 2015 15:55 skrev "Benson Margulies" : > Folks, > > I would appreciate some assistance in thinking through the > implications

Re: Reproducibility versus ranges

Am Mon, 26 Oct 2015 13:03:03 -0400 schrieb Benson Margulies : > Do we have any tooling for this? In my imagination, the top pom for a > product to be released could be auto-decorated with > dependencyManagement locks. I think besides the release-with-pom from the release

Re: Reproducibility versus ranges

There is a plugin by a friend of a friend (don't ask me what it's called) that writes out a de-ranged pom.xml as part of the build, in the event that you need to reproduce a build, eg, branching from a tag for a production fix, you swap in the tag, drop in the pom, make the change down stream as

Re: Reproducibility versus ranges

Am 26.10.2015 um 15:54 schrieb Benson Margulies: Am I missing something? Could it be that the release process somehow resolves the ranges and writes them into the poms? This is what 'mvn release:prepare-with-pom' would do. Regards, -- Christian

Re: Reproducibility versus ranges

On Mon, Oct 26, 2015 at 11:42 AM, Anders Hammar wrote: > You're right, this is the problem. What would need to be done is the > version to be fixed for the release version (tag). Do we have any tooling for this? In my imagination, the top pom for a product to be