Re: To RC or not RC

Am 11/26/12 00:49, schrieb Jason van Zyl: > It's easy enough to not push the tag, or blow it away. > > So I'll just stage it again. All I am saying is that this tag will be incorrect, if you ever need to re-create another 3.1.0 tag in subsversi

[ANN] Maven Dependency Analyzer 1.3 Released

The Maven team is pleased to announce the release of the Maven Dependency Analyzer, version 1.3 Analyzes the dependencies of a project for undeclared or unused artifacts. http://maven.apache.org/shared/maven-dependency-analyzer/ You should specify the version in your project's dependency config

[VOTE] Maven 3.1.0

Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-073/ The distributable binaries and sources for testing can be found here: https://repository

Re: To RC or not RC

On Sun, Nov 25, 2012 at 7:22 PM, Olivier Lamy wrote: > 2012/11/26 Stephen Connolly : >> Well technically we only vote on the sources *not* the binaries *nor* the > > You don't test the binaries we will propose to users for download ? > Do you think users download sources to build maven locally ? >

Re: To RC or not RC

2012/11/26 Stephen Connolly : > Well technically we only vote on the sources *not* the binaries *nor* the You don't test the binaries we will propose to users for download ? Do you think users download sources to build maven locally ? So for me binaries we produce as important as sources as long a

Re: To RC or not RC

Well technically we only vote on the sources *not* the binaries *nor* the SCM tag... We just have tge habit if giving the tag for good form... With the move to GIT, I don't see it as Bering so critical... You can always include the tag hash ID in the vote email and reproducibility isn't so importan

Re: To RC or not RC

2012/11/25 Jason van Zyl : > > On Nov 25, 2012, at 2:07 PM, Brett Porter wrote: > >> >> On 26/11/2012, at 6:42 AM, Jason van Zyl wrote: >> >>> I wish RCs were useful, but I don't believe anyone really looks or takes >>> the time to even try anything until it's actually released. >> >> 3.0.4 had

Re: To RC or not RC

It's easy enough to not push the tag, or blow it away. So I'll just stage it again. On Nov 25, 2012, at 3:46 PM, Stephen Connolly wrote: > +1 > > > On 25 November 2012 23:09, Benson Margulies wrote: > >> On Sun, Nov 25, 2012 at 5:29 PM, Christian Schulte wrote: >>> Am 11/25/12 20:42, schr

Re: To RC or not RC

+1 On 25 November 2012 23:09, Benson Margulies wrote: > On Sun, Nov 25, 2012 at 5:29 PM, Christian Schulte wrote: > > Am 11/25/12 20:42, schrieb Jason van Zyl: > >> I wish RCs were useful, but I don't believe anyone really looks or > takes the time to even try anything until it's actually rele

Re: To RC or not RC

On Sun, Nov 25, 2012 at 5:29 PM, Christian Schulte wrote: > Am 11/25/12 20:42, schrieb Jason van Zyl: >> I wish RCs were useful, but I don't believe anyone really looks or takes the >> time to even try anything until it's actually released. >> >> It's not hard to make RCs. So if folks want them,

Re: Shade and it's many options for controlling output

Anders Hammar wrote: >> The Enunciate plugin "attaches" its own artifact with a unique >artifactId. > > >Do you have an example of this? I checked the docs ( >http://enunciate.codehaus.org/executables.html#maven) and I can't see >this. The install and deploy goals are what I was referring to.

Re: Shade and it's many options for controlling output

The Enunciate plugin "attaches" its own artifact with a unique artifactId. I'm not sure of the implementation details, but it's got its own install-artifact and deploy-artifact goals that do the work. (Just to note that there's at least one other plugin doing something similar, not to make a c

Re: Shade and it's many options for controlling output

On 25 November 2012 22:14, Peter Janes wrote: > Anders Hammar wrote: > >> The Enunciate plugin "attaches" its own artifact with a unique >>> >> artifactId. >> >> >> Do you have an example of this? I checked the docs ( >> http://enunciate.codehaus.org/**executables.html#maven

Re: To RC or not RC

Am 11/25/12 20:42, schrieb Jason van Zyl: > I wish RCs were useful, but I don't believe anyone really looks or takes the > time to even try anything until it's actually released. > > It's not hard to make RCs. So if folks want them, not a problem, I can roll > an RC. > > Anyone have an opinion?

Re: To RC or not RC

On Nov 25, 2012, at 2:07 PM, Brett Porter wrote: > > On 26/11/2012, at 6:42 AM, Jason van Zyl wrote: > >> I wish RCs were useful, but I don't believe anyone really looks or takes the >> time to even try anything until it's actually released. > > 3.0.4 had 5 RCs from memory, and so far, 3.1.

Re: Shade and it's many options for controlling output

Anders Hammar wrote: The Enunciate plugin "attaches" its own artifact with a unique artifactId. Do you have an example of this? I checked the docs ( http://enunciate.codehaus.org/executables.html#maven) and I can't see this. The install and deploy goals are what I was referring to. I'm no

Re: To RC or not RC

On 26/11/2012, at 6:42 AM, Jason van Zyl wrote: > I wish RCs were useful, but I don't believe anyone really looks or takes the > time to even try anything until it's actually released. 3.0.4 had 5 RCs from memory, and so far, 3.1.0 has had one pulled back - seems like they are being useful?

Re: Shade and it's many options for controlling output

> The Enunciate plugin "attaches" its own artifact with a unique artifactId. Do you have an example of this? I checked the docs ( http://enunciate.codehaus.org/executables.html#maven) and I can't see this. > I'm not sure of the implementation details, but it's got its own > install-artifact and

Re: To RC or not RC

On Sun, 25 Nov 2012 15:24:54 -0500 Benson Margulies wrote: > I see no value to RCs around here. To me, RC's are valuable when the > packaging is unstable, and you want a way for people to kick the tires > of 'the package'. Our packaging is stable. +1 > > Any member of the community, even I, can

Re: Shade and it's many options for controlling output

The Enunciate plugin "attaches" its own artifact with a unique artifactId. I'm not sure of the implementation details, but it's got its own install-artifact and deploy-artifact goals that do the work. (Just to note that there's at least one other plugin doing something similar, not making a cl

Re: [VOTE] Maven 3.1.0

He cancelled it. On Sun, Nov 25, 2012 at 4:00 PM, Mark Derricutt wrote: > Jason, > > That repository no longer seems to be alive - was it cancelled or? > > On 26/11/2012, at 7:34 AM, Jason van Zyl wrote: > >> Hi, >> >> Here is a link to Jira with 30 issues resolved: >> https://jira.codehaus.org/

Re: Shade and it's many options for controlling output

More thought leads me toward additional simplification. I don't see why individual plugins need individual settings of outputDirectory. If the output is going into the reactor, I think it should be, by convention, in the project output directory, period. This is related to Anders' hatred of finalN

Re: [VOTE] Maven 3.1.0

Jason, That repository no longer seems to be alive - was it cancelled or? On 26/11/2012, at 7:34 AM, Jason van Zyl wrote: > Hi, > > Here is a link to Jira with 30 issues resolved: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967 > > Staging repo: > https://rep

Re: maven-changes-plugin: rest

On Sun, Nov 25, 2012 at 3:47 PM, Dennis Lundberg wrote: > Hi > > Thanks for fixing the Java 6 issue. > > Given that there are a lot of stuff I'd like to do for a 3.0 release, > and that there is a need to get a new version out soonish, I'd like for > the next release to be 2.9 and include all the

Re: maven-changes-plugin: rest

Hi Thanks for fixing the Java 6 issue. Given that there are a lot of stuff I'd like to do for a 3.0 release, and that there is a need to get a new version out soonish, I'd like for the next release to be 2.9 and include all the old stuff. When we do a 3.0 later on, I agree that we need to cut do

Re: Shade and it's many options for controlling output

I've had a look at the code. Kill it! On 25 November 2012 20:22, Benson Margulies wrote: > Given that all it turns out to *do* is to construct finalName, I am > perfectly willing to kill it. If bentmann decides to relax his vow of > never talking to us, I'm happy to hear what he says. > > > On

Re: To RC or not RC

I see no value to RCs around here. To me, RC's are valuable when the packaging is unstable, and you want a way for people to kick the tires of 'the package'. Our packaging is stable. Any member of the community, even I, can check out the trunk and build the core and try it out. I don't need to wai

Re: Shade and it's many options for controlling output

Given that all it turns out to *do* is to construct finalName, I am perfectly willing to kill it. If bentmann decides to relax his vow of never talking to us, I'm happy to hear what he says. On Sun, Nov 25, 2012 at 2:58 PM, Stephen Connolly wrote: > No. Not expected to remember... But sometimes

[RESULT] Re: [VOTE] Release Maven Dependency Plugin 2.6 and Maven Dependency Analyzer 1.3 - Attempt #2

Hi, The vote has passed with the following result : +1 (binding): Arnaud Héritier, Olivier Lamy, Hervé Boutemy, +1 (non binding): Anders Hammar, Tony Chemit I will promote the artifacts to the central repo. Thx On Fri, Nov 23, 2012 at 10:24 AM, Tony Chemit wrote: > On Fri, 23 Nov 2012 07:31:

Re: To RC or not RC

Hello, I would support Stephen's suggestion and go with a quick 3.1.0 and liked it better to fix-forward and release a 3.1.1 quite soon afterwards. In the end you will get more feedback from a release then from a RC. Regards Mirko On Sun, Nov 25, 2012 at 8:50 PM, Stephen Connolly wrote: > If yo

Re: Shade and it's many options for controlling output

No. Not expected to remember... But sometimes one does... especially bentmann in my experience ;-) On Sunday, 25 November 2012, Anders Hammar wrote: > Just a check, is one supposed to remember why one did something 4.5 years > ago? I can hardly remember what I did last week > > I'm currently

Re: To RC or not RC

I plan to be working on this for the next 8 weeks or so. There will definitely be another release within a couple months. Hopefully in 4-6 weeks. On Nov 25, 2012, at 11:50 AM, Stephen Connolly wrote: > If you are going to help do another release in the next 2 months or so > (barring unforeseen

Re: Shade and it's many options for controlling output

Just a check, is one supposed to remember why one did something 4.5 years ago? I can hardly remember what I did last week I'm currently searching JIRA to see if I can find a ticket that would match Benjamin's fix. /Anders On Sun, Nov 25, 2012 at 8:45 PM, Stephen Connolly < stephen.alan.conn

Re: To RC or not RC

If you are going to help do another release in the next 2 months or so (barring unforeseen circumstances) my vote is Jenkins tip style, no RCs, early and often. If we are going to resume the snails pace (I hope not) then RCs Thst's my €0.02 -Stephen On Sunday, 25 November 2012, Jason van Zyl wr

Re: Shade and it's many options for controlling output

So it is not to create the shaded artifact at a different coordinate without requiring the creation of an additional module? I agree it seems a tad insane, but if we could get bentmann to chime in as to what it is actually supposed to do, then I think we can make a correct decision... Of course t

To RC or not RC

I wish RCs were useful, but I don't believe anyone really looks or takes the time to even try anything until it's actually released. It's not hard to make RCs. So if folks want them, not a problem, I can roll an RC. Anyone have an opinion? Thanks, Jason --

Re: [VOTE] Maven 3.1.0

I'm fine with RCs. Though looking at the download counts for the plugins that changed between the versions not much happened during the RCs. I made the assumption people actually look at them, but they don't. If someone has access to the direct download counts of the distributions that can be v

Re: [VOTE] Maven 3.1.0

Sure, nuking this vote. I'm re-rolling it. On Nov 25, 2012, at 10:53 AM, Benson Margulies wrote: > If you are respinning, please get rid of the init-git-svn.sh script > from the source package. > > On Sun, Nov 25, 2012 at 1:48 PM, Jason van Zyl wrote: >> Yup, that fix got lost between the svn/

Re: [VOTE] Maven 3.1.0

http://mail-archives.apache.org/mod_mbox/maven-dev/201112.mbox/%3cdba1210a-2ea7-4dde-8286-5ff3af5ec...@tesla.io%3E Kristian 2012/11/25 Jason van Zyl : > Hi, > > Here is a link to Jira with 30 issues resolved: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967 > > S

Re: Shade and it's many options for controlling output

I am fairly depressed here, and I agree with Anders. The shadedArtifactId was added in svn rev 640405 by bbentman. The log for that change consists of: r640405 | bentmann | 2008-03-24 09:17:58 -0400 (Mon, 24 Mar 2008) | 1 l

Re: Shade and it's many options for controlling output

> I'm willing to go on a history expedition to see who added the > feature. The MavenProjectHelper API suports this feature, let alone > the naked MavenProject API. > I don't care who initially added this, just saying that if we're to do any changes here it should be to fix errors not to refine th

Re: Shade and it's many options for controlling output

Anders, I'm willing to go on a history expedition to see who added the feature. The MavenProjectHelper API suports this feature, let alone the naked MavenProject API. On Sun, Nov 25, 2012 at 2:06 PM, Anders Hammar wrote: >> > How would you attach an artifact with a DIFFERENT artifactId than the

Re: [VOTE] Maven 3.1.0

He's right, this one is nasty and it would completely screw Tycho users. Just mixed up branch names so the commit didn't go in. I have the fix. On Nov 25, 2012, at 10:44 AM, Benson Margulies wrote: > It does seem odd that this JIRA was marked fixed and wasn't actually > fixed. Generally, I'm op

Re: Shade and it's many options for controlling output

> > How would you attach an artifact with a DIFFERENT artifactId than the > > project? It doesn't make sense. > > This is *already* a feature of the plugin. I didn't invent it, I'm > just trying to clean up how your configure it. > Why would you try to clean up how to configure something that does

Re: [VOTE] Maven 3.1.0

Good, catch. It is fixed but got mingled into "master" locally by mistake instead of "trunk" so it didn't go in with the dcommit. On Nov 25, 2012, at 10:40 AM, Anders Hammar wrote: > -1 > > MNG-5381 is not fixed. Let's follow up in that ticket. > > /Anders > > > On Sun, Nov 25, 2012 at 7:37

Re: [VOTE] Maven 3.1.0

If you are respinning, please get rid of the init-git-svn.sh script from the source package. On Sun, Nov 25, 2012 at 1:48 PM, Jason van Zyl wrote: > Yup, that fix got lost between the svn/git monkey patching. The first thing > after this release is to flip the core to Git. > > On Nov 25, 2012, a

Re: Shade and it's many options for controlling output

On Sun, Nov 25, 2012 at 1:48 PM, Anders Hammar wrote: > How would you attach an artifact with a DIFFERENT artifactId than the > project? It doesn't make sense. This is *already* a feature of the plugin. I didn't invent it, I'm just trying to clean up how your configure it. > > I would vote for

Re: Shade and it's many options for controlling output

How would you attach an artifact with a DIFFERENT artifactId than the project? It doesn't make sense. I would vote for doing changes that make it impossible to use the plugin as I-would-like-to-create-any-file-the-way-i-used-to-with-Ant solution. I think that the possibilities to alter the final n

Re: [VOTE] Maven 3.1.0

Yup, that fix got lost between the svn/git monkey patching. The first thing after this release is to flip the core to Git. On Nov 25, 2012, at 10:46 AM, Benson Margulies wrote: > I've checked signatures and such, and so I'm +1. I also wouldn't > object to a respin over Ander's observation. >

Why do we even have MavenProjectHelper?

Can anyone shed any light on this for me? We've got lots of plugins that get the MavenProject itself injected, and the MavenProjectHelper does some pretty trivial things to wrap MavenProject APIs. - To unsubscribe, e-mail: dev-uns

Re: [VOTE] Maven 3.1.0

I've checked signatures and such, and so I'm +1. I also wouldn't object to a respin over Ander's observation. On Sun, Nov 25, 2012 at 1:43 PM, Jason van Zyl wrote: > Hi, > > Here is a link to Jira with 30 issues resolved: > https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version

Re: [VOTE] Maven 3.1.0

Hmm, let me take a look as I tested a bunch of Tycho builds here when I fixed it. On Nov 25, 2012, at 10:40 AM, Anders Hammar wrote: > -1 > > MNG-5381 is not fixed. Let's follow up in that ticket. > > /Anders > > > On Sun, Nov 25, 2012 at 7:37 PM, Benson Margulies > wrote: > >> Jason, thi

Re: [VOTE] Maven 3.1.0

It does seem odd that this JIRA was marked fixed and wasn't actually fixed. Generally, I'm opposed to blocking a release because 'one more bug' isn't fixed, but if this is a simple oversight perhaps it should be dealt with? - To u

Re: [VOTE] Maven 3.1.0

There you go. They are all in that same directory so I just pointed each archive out specifically. On Nov 25, 2012, at 10:37 AM, Benson Margulies wrote: > Jason, this email is missing the specific link to the buildable source > bundle which is part of the current release vote template. Since >

[VOTE] Maven 3.1.0

Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-072/ The specific binaries and sources for testing can be found here: https://repository.apac

Re: [VOTE] Maven 3.1.0

-1 MNG-5381 is not fixed. Let's follow up in that ticket. /Anders On Sun, Nov 25, 2012 at 7:37 PM, Benson Margulies wrote: > Jason, this email is missing the specific link to the buildable source > bundle which is part of the current release vote template. Since > Apache releases are source r

Re: [VOTE] Maven 3.1.0

Jason, this email is missing the specific link to the buildable source bundle which is part of the current release vote template. Since Apache releases are source releases, voters need to be reminded of the location of the source. I think that the relevant link is: https://repository.apache.org/

[VOTE] Maven 3.1.0

Hi, Here is a link to Jira with 30 issues resolved: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967 Staging repo: https://repository.apache.org/content/repositories/maven-072/ The specific binaries for testing can be found here: https://repository.apache.org/conte

maven-changes-plugin -- removal of non-REST for next release

Dennis, I hesitate to adopt my proposal for simplification until you've spoken up. --benson - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org

Shade and it's many options for controlling output

Shade has a collection of related parameters for controlling where the results end up. To me, they feel like a collection of individual items that are fairly confusing to the reader of the documentation. Since I'm planning to bump the major version and change the behavior, I'd like to consider rat

mvn tomcat:run

Hi I am getting the follwoing error message while running tomcat. Nov 23, 2012 9:51:27 PM org.sonatype.guice.bean.reflect.NamedClass WARNING: Error injecting: org.apache.maven.shared.filtering.DefaultMavenResource sFiltering java.lang.NoClassDefFoundError: Lorg/sonatype/plexus/build/incremen

Re: Changing MavenProjectHelper

On 25 Nov 2012, at 01:04, Hervé BOUTEMY wrote: > Since this is a plexus component implemented in Maven core [1], I don't see > any problem with adding a new Method: if the method exists in interface, it > exists in implementation. > We would have a problem if it was an interface that is expecte