Re: What is the best way to use SemVer versions with maven-artifact?

I seem to recall that it's already configurable, that someone else has been here and done this. On Mon, Jan 11, 2021 at 8:24 AM Dennis Lundberg wrote: > Hi all, > > When using a CI environments that create a new SemVer-compliant version for > every build. These could use a qualifier like

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.3

+1 binding On Tue, Aug 11, 2020 at 1:08 PM Ian Lavallee wrote: > +1 > > On Mon, Aug 10, 2020 at 10:20 AM Elliotte Rusty Harold > > wrote: > > > Let's try this one more time. I updated Jira and regenerated the > > release notes. Nothing else has changed: > > > > Hi, > > > > We solved 3 issues:

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.2

upgrade that enables lots of new work in > > the dependency plugin. Can anyone else give us a +1? Thanks. > > > > On Fri, Jul 24, 2020 at 2:43 PM Benson Margulies > > wrote: > > > > > > +1 binding. > > > > > > > > > On Thu,

Re: [VOTE] Release Apache Maven Dependency Analyzer version 1.11.2

+1 binding. On Thu, Jul 23, 2020 at 5:39 PM Eric Lilja wrote: > On Fri, Jul 24, 2020 at 12:06 AM Sylwester Lachiewicz < > slachiew...@gmail.com> > wrote: > > > +1 > > > > in fact, in this release, based on commits, we have also fixed: > > MSHARED-879 Reproducible builds > > MSHARED-810 Support

Committer access for my google identity at github

id.apache.org lists bimargulies-google as an ID for me, but I don't see write access at github.com. Does someone have to do something?

Re: Plexus Logging API

We made a community decision years ago to support slf4j. It's not helpful to cast aspersions on it. If someone wants to lead an effort to supplant that with log4j now that it's alive again, or even jul (please, no), someone can start that process. Until then, using slf4j in an plugin is an

Re: Modernizing plugin dependencies

Would it make sense to branch from 2.1 and do a controlled update? What version of maven core are we willing to require? On Wed, May 13, 2020 at 1:41 PM Benson Margulies wrote: > 2.1 has a terrible bug; it does not compensate for long-ago changes in > which ArtifactItem.getClassifier() r

Re: Modernizing plugin dependencies

; On 13.05.20 01:59, Benson Margulies wrote: > > What's current best practice for updating the versions of the test > harness > > and other bits and bobs? > > > > the problem with Test harness is that it brings more recent versions of > maven-core with it which is from

Modernizing plugin dependencies

What's current best practice for updating the versions of the test harness and other bits and bobs?

https://issues.apache.org/jira/browse/MDEP-480

I'm helping someone dust this off as a warm up to development in the plugin. Could folks have a look at the JIRA and see if the feature makes sense?

Re: Merging via GitHub

Could you send me a pointer to refresh my memory on procedures? It's been a while ... On Mon, May 11, 2020 at 1:42 PM Michael Osipov wrote: > Folks, > > please do NOT merge via merge button in GitHub: > > > commit 158f54e3abc5c1d602146a08902482b6a19e2c27 (origin/master, > origin/HEAD) > >

Running mojo unit test in the debugger

I am trying to recall how to debug a Junit test that uses AbstractMojoTestCase. Simply asking an IDE to debug the test fails with plexus container errors. I cannot recall if these can be debugged as ordinary unit tests somehow, or whether we need to set remote debugging options to the surefire

MSHADE-209: 'too expensive test'

There's a good patch in a PR. It has no test, and the author references https://github.com/apache/maven-plugins/blame/8762d5746501b894cf766f38111fc514938be280/maven-shade-plugin/src/test/java/org/apache/maven/plugins/shade/filter/MinijarFilterTest.java containing a commented out test case marked

Re: [VOTE] Release Apache Maven 3.5.0-alpha-1

Is it still non-critical if the user lacks write access to that directory? On Sat, Feb 25, 2017 at 8:07 AM, Robert Scholte wrote: > Hi, > > found a non-critical issue. It seems like with every Maven build, a new > lib/ext/jansi-64-1-xxx.13 is generated. > If

Re: Build Maven offline

Then don't include it in the distro. Packaging non-standard, possibly broken, versions in distros is not doing anyone any favors. Users are better off just downloading for themselves. On Mon, Feb 13, 2017 at 8:47 AM, Guo Yunhe wrote: >> Don't. Don't do the same as done

Re: MNG-5567: Zips on classpath

How? When I declare a zip dependency on a non-reactor artifact, it is just zip. Packaging doesn't show up in , or is this what you are proposing? On Thu, Feb 9, 2017 at 12:18 PM, Michael Osipov <micha...@apache.org> wrote: > Am 2017-02-09 um 21:10 schrieb Benson Margulies: >>

Re: MNG-5567: Zips on classpath

-1 to zips on the classpath. We need to disentangle the java classpath from the general concept of 'module X depends on module Y'. I created quite a lot of code that uses zips as containers to pass files from one place to another, and would be horribly broken if their transitive dependencies

Re: [2/2] maven git commit: Merge branch 'MNG-5629'

there is always merge --squash. Makes the master history dead simple on the theory that no one cares about the dev history of a feature branch. On Mon, Jan 16, 2017 at 1:24 AM, Christian Schulte wrote: > Am 16.01.2017 um 10:21 schrieb Stephen Connolly: >> or if you want less

Re: [VOTE] Reset Maven Core, Integration Tests and Resolver repository master branches

+1 On Jan 4, 2017 10:03 AM, "Robert Scholte" wrote: > +1 > > On Wed, 04 Jan 2017 13:16:11 +0100, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > Hi, >> >> We have collectively managed to mess up our ability to follow the original >> release plan for 3.4.0

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

On Mon, Jan 2, 2017 at 1:38 PM, Hervé BOUTEMY wrote: > Christian, > > Please read Tibor's concerns: > - big change, > - near release (with parallel branches for JUnit 5) > And I'll add: noise, like addition of final, reordering of imports, > addition/ > suppression of

Re: Lets talk about our changes openly. maven-surefire git commit: [SUREFIRE-1324] Surefire incorrectly suppresses exceptions when closing resources.

The normal Apache process here is this: if someone finds a commit sufficiently objectionable, as per CTR, they https://www.apache.org/foundation/glossary.html#Veto it. It gets reverted post haste, no vote is needed. According to the Apache methodology, a change which has been made or proposed

Re: [VOTE] Maven Assembly Plugin 3.0.0

There is no reason to cancel over one missing link. If there are enough +1 votes, the vote passes. There's no need to view a -1 as a veto, especially if it's something that can be fixed up later. On Sun, Nov 6, 2016 at 6:22 PM, Michael Osipov wrote: > Am 2016-11-07 um 00:13

Combining parent and child configuration

I'm helping out a bit with the bnd-maven-plugin. They are currently recursing up the chain of parents, looking at the DOM for , to combine parent and child information. There's http://blog.sonatype.com/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/, but (a) gosh it

Anyone want to put a better general include/exclude filter in core?

This is adapted from a class in the shade plugin https://github.com/benson-basis/alta/blob/issue-5-include-exclude/src/main/java/com/github/veithen/alta/IncludeExcludeArtifactFilter.java I think it would live next to: org.apache.maven.artifact.resolver.filter.IncludesArtifactFilter pretty

Re: opinions on MJAVADOC-451

On Fri, Aug 5, 2016 at 10:37 AM, Christopher wrote: > I'm always in favor of adding skip properties. They are very useful for > manipulating builds for debugging, running on CI servers, controlling > executions in child poms, etc. Even if it's not recommended to run >

Re: [DISCUSSION] finishing Aether import: help find a new name

We have this body of code. People in the world use it. Refactoring this code to break its existing users, just to avoid an awkward name, strike me as a poor use of time. My suggestion remains that we pick some inoffensive descriptive string and use it.

Re: [DISCUSSION] finishing Aether import: help find a new name

I my view, we should not be inventing brand names for miscellaneous internal pieces of Maven. We have hundreds of such pieces. Why give nicknames to some? On Thu, Aug 4, 2016 at 11:40 AM, Manfred Moser wrote: > I also prefer something like a short name even if its a

Re: SHA512 by default for GPG sigs

Greg, the proposal is for the _Default ASF POM_ to be set up so that _all_ projects would use SHA-512. This is not a question for the Maven PMC. On Wed, May 18, 2016 at 1:58 PM, Greg Trasuk wrote: > > Hi Christopher: > > Thanks for your involvement. Apache Maven is one

Re: help review/accept [MSHADE-182]

The tools jar is an old standby, do you need someone to fix a pom to have the right profile? On Tue, Jan 26, 2016 at 3:34 PM, Arnaud Héritier wrote: > No feedback guys ? > > On Thu, Jan 21, 2016 at 11:02 PM, Arnaud Héritier > wrote: > >> Build (install

Re: [VOTE] Release Apache Maven JAR Utilities version 1.2

+1 On Sat, Jan 2, 2016 at 8:42 PM, Michael Osipov wrote: > Am 2015-12-31 um 21:30 schrieb Michael Osipov: >> >> Hi, >> >> We solved 5 issues: >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12334441 >> >> >> There are still a couple of issues

Re: What happened to Maven Eclipse Plugin?

lipse was, only it doesn't eat my machine and crash as Eclipse + M2E used to do back before I made the switch. You have a tree of files or packages on the left, and one or more windows of code on the right, and some tool at the bottom. > > Gary > On Dec 25, 2015 12:49 PM, "Benson Marg

Re: What happened to Maven Eclipse Plugin?

Eclipse's single classpath makes it fundamentally broken with any maven project that has test dependences. So some of us bailed to intellij long ago. m-e-p has one set of incurable issues, and m2e, while much improved, can still eat all your memory on a moderate project. We've watched the lack

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

On Dec 13, 2015 3:25 AM, "Stephen Connolly" <stephen.alan.conno...@gmail.com> wrote: > pom? > 1. The feature descriptor is xml 2. I believe that this still adds transitive dependencies to the dependency graph. > > On Saturday 12 December 2015, Benson Marg

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

hange to the dependency tree, only to the management of classpaths by the plugins that, well, manage classpaths. They could have options to change this behavior in case someone really wants a war file in the classpath for some reason, but that should not be default behavior. No need, in this schema, to

Re: I wish we had a way to declare a dependency that wouldn't participate in the classpath

On Sun, Dec 13, 2015 at 9:40 AM, Benson Margulies <bimargul...@gmail.com> wrote: > On Dec 13, 2015 3:25 AM, "Stephen Connolly" > <stephen.alan.conno...@gmail.com> wrote: >> >> pom? > > > 1. The feature descriptor is xml > > 2.

I wish we had a way to declare a dependency that wouldn't participate in the classpath

Sometimes, we want to declare a dependency without changing a classpath. Project A builds an OSGi bundle and a Karaf feature (classifier 'feature', type 'xml'). Project B wants to consume the feature. it wants to declare the feature descriptor as a dependency, to (a) ensure reactor order, and

How the Lucene PMC manages releases

Given the number of 'burned' releases recently, I thought people might be interested in hearing about an alternative approach. When a Lucene dev has a sudden urge to make a release, he or she set up a release with a version of x.y.z-RC1. This is a real release. It goes up for a vote. If there's

Re: How the Lucene PMC manages releases

; Cheers, > Paul > > On Sun, Nov 15, 2015 at 11:48 AM, Anders Hammar <and...@hammar.net> wrote: > >> That's how Maven core releases were done in the early v3.0.x days. >> Personally I think it worked very good. >> >> /Anders (mobile) >> On Nov 15,

3-ing maven plugins

Could some kind soul please remind me of the wiki page where we've got a procedure for making plugins come up to the maven three base level? I want to do it to the maven-bundle-plugin over at felix (assuming, for the moment, that enough dependencies have been released) :-)

Re: [VOTE] Release Apache Maven Filtering 3.0.0

+1 On Mon, Nov 9, 2015 at 2:44 PM, Karl Heinz Marbaise wrote: > Hi, > > someone else ? > > Kind regards > Karl Heinz Marbaise > On 11/7/15 2:21 PM, Karl Heinz Marbaise wrote: >> >> Hi, >> >> Note: This is a Maven 3.0 / JDK 6 release >> >> We solved 6 issues: >> >>

How to split a component out of shade?

I recently taught the Apache Felix Maven Bundle Plugin to produce a dependency-reduced POM. I copied some source code from the maven-shade-plugin. When/if I update the bundle plugin to a Maven 3 base, I'd prefer to share rather than to copy. Do we have a common practice? Is the desired process to

Re: Updating the default versions for maven-compiler-plugin

-1. We might want to move to 1.7, but many people are still not in a position to use 1.8. On Fri, Nov 6, 2015 at 7:56 AM, Attila-Mihály Balázs wrote: > Hello, > > Given that we're almost in 2015, what do people think about updating the > default source / target for

Re: [VOTE] Release Apache Maven Shared Components POM Version 22

+1 On Sat, Oct 31, 2015 at 4:48 PM, Karl Heinz Marbaise wrote: > Hi, > > JIRA Reference: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311250=12328931 > > Changes since the last release: >

Re: easing Maven parent poms management

+1. I had infra set up a staging group for us some time ago to make this easier; you can stage all of them and test by using the repo URL for the staging group. On Sun, Nov 1, 2015 at 8:00 AM, Karl Heinz Marbaise wrote: > Hi, > > +1 for releasing them in one go... > > > On

Re: [VOTE] Maven 3.3.7

Sure you can close the PR. Put 'Closes #nn.' in a commit message. On Oct 28, 2015 4:38 PM, "Stephen Connolly" wrote: > I > > On Wednesday 28 October 2015, Michael Osipov wrote: > > > Am 2015-10-28 um 18:28 schrieb Stephen Connolly: > > > >>

Re: MNG-5899 Project models are no longer mutable in reactor

ure without making a giant mess? > > -- > Regards, > Igor > > On Tue, Oct 27, 2015, at 10:12 AM, Benson Margulies wrote: >> On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko <i...@ifedorenko.com> >> wrote: >> > Did you really mean "the core model has to

Re: [VOTE] Release Apache Maven Shade Plugin version 2.4.2 (Take 2)

+1 On Tue, Oct 27, 2015 at 4:20 PM, Karl Heinz Marbaise wrote: > Hi, > > i need one more binding VOTE... > > Kind regards > Karl Heinz Marbaise > > On 10/24/15 12:48 PM, Karl Heinz Marbaise wrote: >> >> Hi, >> >> We solved 7 issues: >> >>

Re: MNG-5899 Project models are no longer mutable in reactor

On Tue, Oct 27, 2015 at 9:58 AM, Igor Fedorenko wrote: > Did you really mean "the core model has to be mutable"? The rest of your > message appears to suggest you do not want the model to be mutable, but > I am not sure. > > In any case, I think the core model must not be

Reproducibility versus ranges

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

Re: Reproducibility versus ranges

or a product to be released could be auto-decorated with dependencyManagement locks. > > /Anders (mobile) > Den 26 okt 2015 15:55 skrev "Benson Margulies" <bimargul...@gmail.com>: > >> Folks, >> >> I would appreciate some assistance in thinking through the >&g

Re: [RESULT] [VOTE] Release Maven Checkstyle Plugin version 2.17

I'm on the case for the checkins. Or ducks. On Sun, Oct 18, 2015 at 3:45 PM, Michael Osipov <micha...@apache.org> wrote: > Hi, > > The vote has passed with the following result: > > +1 (binding): Karl Heinz Marbaise, Benson Margulies, Daniel Kulp, Hervé > Bout

Re: Maven plugin for code signing @Apache

Eclipse checks that sort of signature on jar files, as I recall. On Sun, Oct 18, 2015 at 2:14 AM, Hervé BOUTEMY wrote: > Hi, > > Perhaps the "code signing" feature for jars should be explained, since we > already have maven-gpg-plugin [1] to sign code, that is used for

Re: Problem testing the checkstyle release

1 schrieb Benson Margulies: >> >> Maven-plugins 28 is released, of course; what's up? It worked for me, >> but not for one of my co-workers. > > > Benson, > > where you actually able to resolve your problem? From my point of view this > shou

Re: [RESULT] [VOTE] Release Apache Maven Release version 2.5.3

This vote passes: +1 binding: bimargulies, khmarbais, herve.boutemy, rfscholte +1: tibordigana On Sat, Oct 17, 2015 at 3:45 PM, Robert Scholte <rfscho...@apache.org> wrote: > +1 > > Op Wed, 14 Oct 2015 14:05:18 +0200 schreef Benson Margulies > <bimargul...@gmail.com>: &g

[ANN] Apache Maven Release Plugin 2.5.3 Released

The Apache Maven team is pleased to announce the release of the Apache Maven Release Component, version 2.5.3 This component automates tagging and preparing releases, and includes the maven-release-plugin. http://maven.apache.org/maven-release/ You should specify the version in your project's

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

make the regular release, or >> 2. start Take 3 if we want me to fix something. >> >> Honestly making the release Vote of surefire is more painful than >> maven-shared-* staff. >> >> Enjoy the Vote ☺ >> >> >> On Fri, Oct 16, 2015 at 7:25 PM, Bens

Re: VOTE] Release Apache Maven Shared Archiver 3.0.0

+1 binding. Checked sum, tested the other day by running plugins using it. On Sat, Oct 17, 2015 at 10:18 AM, Karl Heinz Marbaise wrote: > Hi, > > here we need two more binding VOTE's.. > > Kind regards > Karl Heinz Marbaise > On 10/16/15 11:54 AM, Karl Heinz Marbaise wrote: >>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

2015-10-16 16:35 GMT+02:00 Benson Margulies <bimargul...@gmail.com>: > >> On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana <tibordig...@apache.org> >> wrote: >> > Can you give me the link? >> >> >> https://github.com/ops4j/org.ops4j.pax.exam2/com

Problem testing the checkstyle release

Maven-plugins 28 is released, of course; what's up? It worked for me, but not for one of my co-workers. $ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] [INFO] Building Parent for Text Analytics Maven

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

On Fri, Oct 16, 2015 at 8:20 AM, Tibor Digana wrote: > https://repository.apache.org/content/repositories/maven-1222 Tested on my current major project. No issues. +1 binding. - To unsubscribe, e-mail:

Re: [VOTE] Release Maven Checkstyle Plugin version 2.17

On Fri, Oct 16, 2015 at 5:53 AM, Karl Heinz Marbaise wrote: > http://maven.apache.org/guides/development/guide-testing-releases.html +1 Ran it on one of my projects, where it promptly exploded due to checkstyle incompatibilities. So I know it worked.

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

Step 1: here's the backtrace of the InvocationTargetException. It's caused by an IllegalArgumentException, which I will break on next. That is in turn, as you supposed, caused by the use of the file:

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

Um, maybe I voted too soon. Using the new failsafe plugin, I get the following, and no backtrace, on each of my integration test classes. Any suggestions, Tibor? --- Test set: com.basistech.ws.itest.FrontEndIT

Re: Problem testing the checkstyle release

? On Fri, Oct 16, 2015 at 9:19 AM, Anders Hammar <and...@hammar.net> wrote: > It looks like a specific staging repo is accessed (look at the URL in the > end). As the parent has been released it is no longer available there. > > /Anders (mobile) > Den 16 okt 2015 15:01 sk

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

ely on target/classes/, use surefire-plugin because that's what the > unit tests do. > > > On Fri, Oct 16, 2015 at 3:04 PM, Benson Margulies <bimargul...@gmail.com> > wrote: > >> Um, maybe I voted too soon. Using the new failsafe plugin, I get the >

Re: Problem testing the checkstyle release

and I only > activate it explicitly when testing staged stuff. Me too. That's what my co-worker was trying to do. > > /Anders (mobile) > Den 16 okt 2015 15:35 skrev "Benson Margulies" <bimargul...@gmail.com>: > >> Anders, I added a pluginRepository for th

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

:78) > > > On Fri, Oct 16, 2015 at 3:46 PM, Benson Margulies <bimargul...@gmail.com> > wrote: > >> Step 1: here's the backtrace of the InvocationTargetException. It's >> caused by an IllegalArgumentException, which I will break on next. >> >> That is in t

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

I've committed the fix to the master for pax-exam. On Fri, Oct 16, 2015 at 10:19 AM, Benson Margulies <bimargul...@gmail.com> wrote: > On Fri, Oct 16, 2015 at 9:56 AM, Tibor Digana > <tibor.dig...@googlemail.com> wrote: >> try to debug this stack part of ProbeRunner. >

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.19 (Take 2)

On Fri, Oct 16, 2015 at 10:31 AM, Tibor Digana <tibordig...@apache.org> wrote: > Can you give me the link? https://github.com/ops4j/org.ops4j.pax.exam2/commit/c466e58cae6c2275a38bc2712cc76a70f768d769 > > On Fri, Oct 16, 2015 at 4:27 PM, Benson Margulies [via Maven] < > m

Releasable by default?

I'd like to open a discussion of a possible policy. The policy would look something like the following: ___ All of the projects managed by the Maven PMC are maintained in a releasable condition. If a developer wants to make a change that will result in an a component being unreleasable for any

[VOTE] Release Apache Maven Release version 2.5.3

Hi, We solved 2 issues: Release Notes - Maven Release Plugin - Version 2.5.3 ** Bug * [MRELEASE-921] - perform goal doesn't support providerImplementation * [MRELEASE-925] - Old version of plexus utils forced here causes failures There are still a couple of issues left in JIRA:

Re: Releasable by default?

not trying to coerce anyone; the Apache veto/revert mechanism for CTR is perfectly sufficient, as per your remark about 'fix it and move on.' I perceive a presumption of 'leave it to the person who wants to make a release to make a branch'. I'd like to move the presumption in the other direction. &

Re: svn commit: r1708587 - in /maven/release/trunk: ./ maven-release-manager/ maven-release-manager/src/main/java/org/apache/maven/shared/release/config/ maven-release-manager/src/main/java/org/apache

On Wed, Oct 14, 2015 at 6:41 PM, Olivier Lamy wrote: > did you create a branch with this change? > At least to help the guys who worked on that... Since it was a single commit, I didn't think it necessary. I could either reapply it to trunk or make a branch; to some extent I'm

Re: [RESULT] [VOTE] Release Apache Maven maven-plugin parent-pom version 28

rbaise <khmarba...@gmx.de> wrote: > >> Hi, >> >> +1 ... >> >> Kind regards >> Karl Heinz Marbaise >> >> On 10/11/15 2:56 AM, Benson Margulies wrote: >> >>> Hi, >>> >>> 2 changes in JIRA. Many other commits.

Release is in limbo waiting for SCM release; I veto a commit from May

I am now -1 on commit 1677765 chrisgwarp 1.9.5-SNAPSHOT from maven-release. Back in May, this made source changes to require an unreleased, incompatible, SCM version. Now I can't release release to fix a critical problem. Further, since it involves this level of API dependency, I think it

[ANN] Apache Maven Plugins (parent POM) version 28 Released

The Apache Maven team is pleased to announce the release of the Apache Maven Plugins parent POM, version 28. This POM is the common parent of all of the plugins maintained by the Apache Maven PMC, and, as such, is of limited use to developers outside of the Maven project. See the svn history of

Re: Can anyone explain this missing plexus utils class?

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

Re: Can anyone explain this missing plexus utils class?

h stronger; the difference between 'all 12 modules say version=N' and 'the parent has depManagement that says N' needs to be cast into higher relief. On Tue, Oct 13, 2015 at 10:14 AM, Benson Margulies <bimargul...@gmail.com> wrote: > I am perfectly willing to stand corrected; I started this email t

Re: Can anyone explain this missing plexus utils class?

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

Re: Can anyone explain this missing plexus utils class?

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.

Re: [VOTE] Release Apache Maven Shared Utils 3.0.0 (Take 2)

+1. On Tue, Oct 13, 2015 at 4:08 PM, Karl Heinz Marbaise wrote: > Hi, > > I need two more binding VOTEs... > > Kind regards > Karl Heinz Marbaise > On 10/13/15 7:26 PM, Karl Heinz Marbaise wrote: >> >> Hi, >> >> here is my +1. >> >> >> Kind regards >> Karl Heinz Marbaise >> On

Re: Can anyone explain this missing plexus utils class?

roject/consumer level, one must have pluginManagement > to pick up the correct plexus-util (3.0.15) Dan, pluginManangement != dependencyManagement. > > > -Dan > > On Sun, Oct 11, 2015 at 5:22 PM, Benson Margulies <bimargul...@gmail.com> > wrote: > >> On O

Intend to release release 2.5.3

To me, it's a pretty urgent situation when the current version of the release plugin blows up; what if we end up unable to release the release plugin? So, absent any objections or further discussion of the plexus-utils version, I intend start the process for 2.5.3 tomorrow, since I already made

Re: Two more proposed releases

y non-jira issues? >> >> On Sat, Oct 10, 2015 at 11:31 PM, Robert Scholte <rfscho...@apache.org> >> wrote: >> >>> maven-common-artifact-filters shouldn't be a problem. >>> >>> but the API for maven-artifact-transfer isn't stable enough y

Re: [VOTE] Release Apache Maven Common Artifact Filters version 2.0

I guess I swapped two of them in reading the email. I will unwind. On Oct 11, 2015 1:53 AM, "Tibor Digana" wrote: > @Benson > That's good that you take this responsibility but I guess you rush too much > with this artifact since we still use the old maven-shared-utils:0.7

Re: [CANCELLED] [VOTE] Release Apache Maven Common Artifact Filters version 2.0

.so i don't see a reason for that rush > at the moment... > > > On 10/11/15 2:12 AM, Benson Margulies wrote: >> >> Hi, >> >> We solved 5 issues: >> >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12331499=Text=12317922=Cre

Re: Can anyone explain this missing plexus utils class?

gt; On Sat, Oct 10, 2015 at 5:43 PM, Benson Margulies <bimargul...@gmail.com> > 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 my local repo, and >> now I can run the release of mave

Re: Two more proposed releases

uggest some JIRAs that help get us closer to releasable plugins, I'll be happy to look at them. > > On Sun, Oct 11, 2015 at 1:05 PM, Benson Margulies [via Maven] < > ml-node+s40175n5848364...@n5.nabble.com> wrote: > >> Just writing for myself, I want to explain why I am pu

Re: Can anyone explain this missing plexus utils class?

The fully-document JIRA is MRELEASE-925. On Sun, Oct 11, 2015 at 3:00 PM, Benson Margulies <bimargul...@gmail.com> 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 Tr

Re: Can anyone explain this missing plexus utils class?

.12 which is missing in my repo. >> >> On Sun, Oct 11, 2015 at 9:02 PM, Benson Margulies [via Maven] < >> ml-node+s40175n5848412...@n5.nabble.com> wrote: >> >> > The fully-document JIRA is MRELEASE-925. >> > >> > On Sun, Oct 11, 2015 at 3:00 P

Re: [ANN] Apache Maven maven-dependency-tree 3.0

As far as I knew, JIRA would only include resolved issues in a release. it used to complain if an unresolved issue was tagged with a release that one was releasing. The log shows that Robert did this. So I marked it resolved in JIRA.

Re: [ANN] Apache Maven maven-dependency-tree 3.0

arbaise > On 10/12/15 12:38 AM, Benson Margulies wrote: >> >> As far as I knew, JIRA would only include resolved issues in a >> release. it used to complain if an unresolved issue was tagged with a >> release that one was releasing. >> >>

Re: [ANN] Apache Maven maven-dependency-tree 3.0

he.org/jira/secure/ReleaseNote.jspa?projectId=12317922=12331490 > > is MSHARED-420 wrongly assigned to maven-dependency-tree 3.0, cause it is > not part of the release nor it is it ready ? > > > Kind regards > Karl Heinz Marbaise > > On 10/10/15 9:04 PM, Benson Margulies wrote

Re: [ANN] Apache Maven maven-dependency-tree 3.0

I am confused and away from my computer. I will try to clarify later On Oct 11, 2015 5:57 PM, "Karl Heinz Marbaise" <khmarba...@gmx.de> wrote: > Hi Benson, > > On 10/11/15 11:39 PM, Benson Margulies wrote: > >> Hey, I just assume that the JIRAs are corre

Re: Can anyone explain this missing plexus utils class?

than writing the same things in the regular dependency element does. What do you expect to happen if two dependencies disagree on version? > If it not so, it is a very serious miss understanding for lots of users > > Can someone confirm? > > -Dan > > On Sun, Oct 11, 2015 at 1:07 PM,

[ANN] Apache Maven Assembly Plugin 2.6 Released

The Apache Maven team is pleased to announce the release of the Apache Maven Assembly Plugin, version 2.6 This plugin builds directories and archives of files, usually for releases. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin

Getting plugins to easily releasable condition -- parent 28?

I'm motivated to get back to the state where it's easy to release a plugin from the trunk. Is there any impediment to releasing parent 28 of the plugins? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional

Two more proposed releases

maven-common-artifact-filters and maven-artifact-transfer, both 3.0. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

[ANN] Apache Maven maven-dependency-tree 3.0

The Maven team is pleased to announce the release of the Apache Maven Dependency Tree, version 3.0 A tree-based API for resolution of Maven project dependencies http://maven.apache.org/shared/maven-dependency-tree/ You should specify the version in your project's dependency configuration:

Can anyone explain this missing plexus utils class?

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]

  1   2   3   4   5   6   7   8   9   10   >