> On Oct 13, 2015, at 8:44 AM, Benson Margulies wrote:
>
> I got a lecture on this from Stephen Connolly, who took some time out
> from Marathon training to educate me. We're all wrong.
>
> The only way to 'lock down' a version is to use a range: [foo). All
> other
I think you meant [foo], i.e. both square brackets, for version range
that means "version foo and nothing else".
--
Regards,
Igor
On Tue, Oct 13, 2015, at 08:44 AM, Benson Margulies wrote:
> I got a lecture on this from Stephen Connolly, who took some time out
> from Marathon training to
I got a lecture on this from Stephen Connolly, who took some time out
from Marathon training to educate me. We're all wrong.
The only way to 'lock down' a version is to use a range: [foo). All
other versions are 'recommended'.
If there are no ranges, then the resolution algorithm decides what
On 13 October 2015 at 15:14, Benson Margulies wrote:
> I am perfectly willing to stand corrected; I started this email thread
> to get some insight. I may have misheard Stephen over the noise of the
> other runners.
No that was collecting my son from school... even more
> On Oct 13, 2015, at 10:45 AM, Benson Margulies wrote:
>
>>
>> I am just accustomed to seeing the whole graph in M2Eclipse and excluding,
>> refactoring and locking things down while I’m running tests. I get
>> everything working and then don’t think about much until
OK, I retract my doc comment in part:
"In addition, the version and scope of artifacts which are
incorporated from transitive dependencies may also be controlled by
specifying them in a dependency management section." is hinting at
reality, but I think it could be made much stronger; the
> The second is the ease of messing up.
>
> The maven-release project is set up as a ticking bomb under this
> regime. The project uses dependencyManagement to lock to a version; so
> if any dependency requires a newer version, the result is the
> explosion we have experienced. To me, this seems
On Tue, Oct 13, 2015 at 10:29 AM, Jason van Zyl wrote:
>
>> The second is the ease of messing up.
>>
>> The maven-release project is set up as a ticking bomb under this
>> regime. The project uses dependencyManagement to lock to a version; so
>> if any dependency requires a newer
I am perfectly willing to stand corrected; I started this email thread
to get some insight. I may have misheard Stephen over the noise of the
other runners.
However, I will say that I don't like two aspects of this, and I
wonder if they could be improved.
The first is documentation.
>> > > >> > >>> >> [ERROR] urls[22] =
>> > > >> > >>> >>
>> > > >> > >>>
>> > > >> >
>> > > >>
>> > >
>> >
>> file:/Users/benson/.m2/repository/org/netbeans/lib/cvsclient/20060125/cvsclient-20060125.jar
>>
This is presumably a core issue, won't someone comment who delves into
that part of the salt mine?
On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran wrote:
> I encounter the same issue and filed at
> https://issues.apache.org/jira/browse/MRELEASE-907
>
> -D
>
> On Sat, Oct 10, 2015
> [ERROR] urls[37] =
> > >>> >>
> > >>>
> >
> file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-manager-plexus/1.8/maven-scm-manager-plexus-1.8.jar
> >
> > >>> >> [ERROR] urls[38] =
> > >>> &g
The fully-document JIRA is MRELEASE-925.
On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies wrote:
> This is presumably a core issue, won't someone comment who delves into
> that part of the salt mine?
>
>
> On Sun, Oct 11, 2015 at 2:57 PM, Dan Tran
I encounter the same issue and filed at
https://issues.apache.org/jira/browse/MRELEASE-907
-D
On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies
wrote:
> I see that the bad version of plexus-utils is called out in the
> maven-release parent pom. I patched it in place in
itory/org/apache/maven/scm/maven-scm-manager-plexus/1.8/maven-scm-manager-plexus-1.8.jar
>
> >>> >> [ERROR] urls[38] =
> >>> >>
> >>>
> file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-svn-commons/1.9.4/maven-scm-p
benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-integrity/1.9.4/maven-scm-provider-integrity-1.9.4.jar
>
> > >
> > > >>> >> [ERROR] urls[34] =
> > > >>> >>
> > > >>>
> > >
> >
> file:
n/scm/maven-scm-provider-synergy/1.9.4/maven-scm-provider-synergy-1.9.4.jar
>> >
>> > >>> >> [ERROR] urls[31] =
>> > >>> >>
>> > >>>
>> >
>> file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-vss/1
gt; >> >
> >> > >>> >> [ERROR] urls[29] =
> >> > >>> >>
> >> > >>>
> >> >
> >>
> file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-svnexe/1.9.4/maven-scm-provider-svnexe-1.9.4.ja
> > >>> >>
> >> > >>>
> >> >
> >>
> file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-starteam/1.9.4/maven-scm-provider-starteam-1.9.4.jar
>
> >> >
> >> > >>> >> [ERROR] urls[29] =
> >> > >>> >>
>
er-hg/1.9.4/maven-scm-provider-hg-1.9.4.jar
> > >> >
> > >> > >>> >> [ERROR] urls[27] =
> > >> > >>> >>
> > >> > >>>
> > >> >
> > >>
> >
> file:/Users/benson/.m2/reposito
; > > >> > >>> >>
> > > >> > >>>
> > > >> >
> > > >>
> > >
> >
> file:/Users/benson/.m2/repository/org/apache/maven/scm/maven-scm-provider-perforce/1.9.4/maven-scm-provider-perforce-1.9.4.jar
> > &g
mvn release:prepare with 3.2.5
➜ maven-plugins mvn release:prepare
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building Apache Maven Plugins 28-SNAPSHOT
[INFO]
I see that the bad version of plexus-utils is called out in the
maven-release parent pom. I patched it in place in my local repo, and
now I can run the release of maven-plugins. I'll write a JIRA for the
release plugin.
On Sat, Oct 10, 2015 at 8:40 PM, Benson Margulies
This happens trying to release maven-plugins version 28, with 3.2.5
and 3.3.1, even after cleaning my local repo.
That class is not in plexus-utils 3.0.10, which is being used here,
it is in the newer version of plexus-utils in the maven lib dir.
I could force a dependency on the right
24 matches
Mail list logo