Github user barthel commented on the pull request:
https://github.com/apache/maven/pull/70#issuecomment-151395866
Can I do anything to support the merge?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project doe
Hi,
here is my +1
Kind regards
Karl Heinz Marbaise
On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote:
Hi,
We solved 7 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317921&version=12333008
There are still a couple of issues left in JIRA:
https://issues.apache.org/j
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 ranges to
> depend on.
>
> Am
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 have
> enough informati
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 your dependencies will al
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
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 our case, we don't want
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
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 ran
Hi,
This is the first release of this new plugin.
The JDeps Plugin uses the jdeps tool to analyze classes for internal API
calls. For more information about the standard jdeps tool, please refer to
Java+Dependency+Analysis+Tool.
NOTE: The jdeps tool is available since JDK8.
Staging repo:
http
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.
F
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 13:03:03 -0400
> schrieb Be
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 plugin but also
versions:r
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
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 released could be auto-decorated w
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
---
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 of the use of version ra
Folks,
I would appreciate some assistance in thinking through the
implications of the use of version ranges.
As a thought experiment, consider a loosely-coupled collection of
maven project, maintained with a semver discipline.
Each component has dependencies, and those are written with ordinary
Yup, that did it. Thanks!
---
*G. Ann CAMPBELL* | SonarSource
Product Owner
http://sonarsource.com
On Sat, Oct 24, 2015 at 7:39 PM, Hervé BOUTEMY
wrote:
> Hi,
>
> I should have fixed it now: Doxia had updated its parent pom but not Doxia
> SiteTools, then they had different Java target.
>
> T
19 matches
Mail list logo
