Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas

[Baptiste Mathus]

Btw (apart from the fact that kind of question should better be asked on
users ML), it seems a bit weird to me at first sight you're actually having
to configure both a nexus server, and a proxy.

For instance, we exclusively use a nexus server to do the actual
proxying(+hosting) of anything that maven has to download inside the
company. Not sure what's your use case to need to not go through your maven
repo manager any time.

My 2 cents.


2014-02-13 8:17 GMT+01:00 Anders Hammar :

> It would be great if you could file a JIRA ticket so that the docs can be
> fixed, see [1]!
> Use the website JIRA project.
>
> /Anders
>
> [1] http://maven.apache.org/issue-tracking.html
>
>
>
> On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian 
> wrote:
>
> > I develop behind a proxy.  Some of our servers sit behind that proxy as
> > well, including our Nexus Repository.  I have configured my settings.xml
> to
> > point to our proxy but to ignore the hosts that are behind that proxy.
>  If
> > I use a comma-delimited list in my nonProxyHosts, Maven seems to ignore
> > that list and apply the proxy to those hosts as well.  If I use a
> > pipe-delimited list in my nonProxyHosts, everything works great and Maven
> > does NOT try to apply the proxy to those hosts.
> >
> > According to this document only pipes are acceptable as delimiters, which
> > is what I observed:
> > https://maven.apache.org/guides/mini/guide-proxies.html
> >
> > According to this document either pipes or commas are acceptable as
> > delimiters which is incorrect according to my observation:
> > https://maven.apache.org/settings.html (Proxies header)
> >
> > This is an example of the proxies block in my settings.xml file that does
> > not work.  When Maven needs to hit 123.456.789.111 or my.nexus.host, it
> > applies the proxy to it.
> >
> >   
> >
> > 
> >
> >   My Proxy
> >
> >   true
> >
> >   http
> >
> >   
> >
> >   
> >
> >   my.proxy.com
> >
> >   80
> >
> >
> > localhost,123.456.789.*,my.nexus.host
> >
> > 
> >
> >   
> >
> > This example WORKS.  Proxy is ignored for any requests to 123.456.789.111
> > or my.nexus.host, etc.
> >
> >
> >   
> >
> > 
> >
> >   My Proxy
> >
> >   true
> >
> >   http
> >
> >   
> >
> >   
> >
> >   my.proxy.com
> >
> >   80
> >
> >
> > localhost|123.456.789.*|my.nexus.host
> >
> > 
> >
> >   
> >
> > Environment:
> > Maven 3.1.1
> > Mac OS-X 10.9
> >
> > Also reproduced this issue on:
> >
> > Apache Maven 3.0.4
> >
> > Ubuntu 11.04
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;!
>

Linkage error

[Kristian Rosenvold]

Stuart,

We're seeing java.lang.LinkageError: loader constraint violation: loader
(instance of org/codehaus/plexus/classworlds/realm/ClassRealm) previously
initiated loading for a different type with name
"javax/enterprise/util/TypeLiteral" using the maven-jetty-plugin on 3.1. I
can't really see this seeping through in DefaultClassRealmManager, but
google shows me https://java.net/jira/browse/GLASSFISH-20802


Is this something you understand ?

Kristia
n

Re: [VOTE] Release Maven 3.2.0

[Hervé BOUTEMY]

true, this is not a technical issue: technically, it is controlled from 
Xircles
http://xircles.codehaus.org/projects/maven/members

Le jeudi 13 février 2014 00:45:04 Paul Benedict a écrit :
> I already have privs to edit issues. But regarding your question, I don't
> think commiter privilege is a procedural necessity to getting more karma,
> is it? Furthermore, it's not even a JIRA instance under Apache's control so
> I don't think it makes a difference in this case.
> 
> On Thu, Feb 13, 2014 at 12:23 AM, Hervé BOUTEMY 
wrote:
> > you mean you want to enter the committer school?
> > 
> > because Jira karma happens when going committer :)
> > 
> > Regards,
> > 
> > Hervé
> > 
> > Le mercredi 12 février 2014 13:14:16 Paul Benedict a écrit :
> > > I'll gladly do some low-hanging JIRA maintenance like create the 3.2.1
> > > version if someone can grant me that karma.
> > > 
> > > On Tue, Feb 11, 2014 at 6:42 PM, Tony Chemit 
> > 
> > wrote:
> > > > On Wed, 12 Feb 2014 00:29:58 +
> > > > 
> > > > Stephen Connolly  wrote:
> > > > > Hurrah! At last!
> > > > > 
> > > > > (at least until the "there must be a .0 release or the world will
> > 
> > end"
> > 
> > > > gang
> > > > 
> > > > > on the PMC bash us back to 3.2.0)
> > > > 
> > > > Stephen, I won't survive a none .0 version, what do I tell to my devs
> > > > buddies ? :D
> > > > 
> > > > At least, I will save me 2 hours finding back why I had a 3.1.1 on a
> > > > server buggy with android plugin, just beacuse this was not the good
> > 
> > 3.1.1
> > 
> > > > version ;) Shame on me to test not final maven version ;).
> > > > 
> > > > Nice decision guys to move forward.
> > > > 
> > > > +1
> > > > 
> > > > And viva then maven 3.2.1 \o/
> > > > 
> > > > tony.
> > > > 
> > > > --
> > > > Tony Chemit
> > > > 
> > > > tél: +33 (0) 2 40 50 29 28
> > > > http://www.codelutin.com
> > > > email: che...@codelutin.com
> > > > twitter: https://twitter.com/tchemit
> > > > 
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas

[Anders Hammar]

It would be great if you could file a JIRA ticket so that the docs can be
fixed, see [1]!
Use the website JIRA project.

/Anders

[1] http://maven.apache.org/issue-tracking.html



On Thu, Feb 13, 2014 at 12:05 AM, Barnett, Ian  wrote:

> I develop behind a proxy.  Some of our servers sit behind that proxy as
> well, including our Nexus Repository.  I have configured my settings.xml to
> point to our proxy but to ignore the hosts that are behind that proxy.  If
> I use a comma-delimited list in my nonProxyHosts, Maven seems to ignore
> that list and apply the proxy to those hosts as well.  If I use a
> pipe-delimited list in my nonProxyHosts, everything works great and Maven
> does NOT try to apply the proxy to those hosts.
>
> According to this document only pipes are acceptable as delimiters, which
> is what I observed:
> https://maven.apache.org/guides/mini/guide-proxies.html
>
> According to this document either pipes or commas are acceptable as
> delimiters which is incorrect according to my observation:
> https://maven.apache.org/settings.html (Proxies header)
>
> This is an example of the proxies block in my settings.xml file that does
> not work.  When Maven needs to hit 123.456.789.111 or my.nexus.host, it
> applies the proxy to it.
>
>   
>
> 
>
>   My Proxy
>
>   true
>
>   http
>
>   
>
>   
>
>   my.proxy.com
>
>   80
>
>
> localhost,123.456.789.*,my.nexus.host
>
> 
>
>   
>
> This example WORKS.  Proxy is ignored for any requests to 123.456.789.111
> or my.nexus.host, etc.
>
>
>   
>
> 
>
>   My Proxy
>
>   true
>
>   http
>
>   
>
>   
>
>   my.proxy.com
>
>   80
>
>
> localhost|123.456.789.*|my.nexus.host
>
> 
>
>   
>
> Environment:
> Maven 3.1.1
> Mac OS-X 10.9
>
> Also reproduced this issue on:
>
> Apache Maven 3.0.4
>
> Ubuntu 11.04
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Maven Issue - pluginManagement - build Area Plugin

[Anders Hammar]

I reported this Codehaus parent issue a long time ago (HAUS-2245 [1]).
Unfortunately the codehaus-parent seems to be in a unmaintained state.

/Anders

[1] http://jira.codehaus.org/i#browse/HAUS-2245


On Wed, Feb 12, 2014 at 9:07 PM, Karl Heinz Marbaise wrote:

> Hi,
> i have a question. The following situation. Pom file which uses the
> following parent:
>
> 
> org.codehaus
> codehaus-parent
> 4
> 
>
> 
>   ${mavenVersion}
> 
>
> and the following part in my pom file:
>
> 
> 
> 
> 
> org.apache.maven.plugins
> maven-enforcer-plugin
> 1.3.1
> 
> 
> 
> 
> 
>   org.apache.maven.plugins
>   maven-enforcer-plugin
>   
> 
>   enforce-maven
>   
>   ... The rule does not matter..
>
>
> So if i call (Maven 2.2.1)
>
> mvn clean package I got the following error:
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Failed to configure plugin parameters for: org.apache.maven.plugins:
> maven-enforcer-plugin:1.0
>
> Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be
> instantiated
>
> So if i call with Maven 3.0.5:
>
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-enforcer-plugin:1.0:enforce (enforce-maven) on project
> test-enforcer: Unable to parse configuration of mojo
> org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for parameter
> requireSameVersions: Abstract class or interface 
> 'org.apache.maven.enforcer.rule.api.EnforcerRule'
> cannot be instantiated -> [Help 1]
>
> Maven 3.1.X and Maven 3.2.X tested as well...
>
> So this looks to me that the pluginManagement does not overwrite the
> version 1.0 which is defined in the codehaus-parent. To be honest the
> codehaus-parent does not define it via pluginManagement it just uses the
> following:
>
> 
> 
> 
> org.apache.maven.plugins
> maven-enforcer-plugin
> 1.0
> 
> 
> enforce-maven
> 
> enforce
> 
> 
> 
> 
>
> (,2.1.0),(2.1.0,2.2.0),(2.2.0,)
> Maven 2.1.0 and 2.2.0 produce
> incorrect GPG signatures and checksums respectively.
> 
> 
> 
> 
> 
> 
> 
>
>
> First the codehaus-parent seemed to be wrong...so i can't overwrite the
> version of the plugin by using a pluginManagement block in inherited
> project which forces me to define the version explicitly in my pom in the
> build block to get that working like this:
>
> 
> 
>   org.apache.maven.plugins
>   maven-enforcer-plugin
>   1.3.1
>   
>
>
> WDYT ? Bug ? Right behaviour ?
>
>
> Kind regards
> Karl-Heinz Marbaise
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven 3.2.0

[Paul Benedict]

I already have privs to edit issues. But regarding your question, I don't
think commiter privilege is a procedural necessity to getting more karma,
is it? Furthermore, it's not even a JIRA instance under Apache's control so
I don't think it makes a difference in this case.


On Thu, Feb 13, 2014 at 12:23 AM, Hervé BOUTEMY wrote:

> you mean you want to enter the committer school?
>
> because Jira karma happens when going committer :)
>
> Regards,
>
> Hervé
>
> Le mercredi 12 février 2014 13:14:16 Paul Benedict a écrit :
> > I'll gladly do some low-hanging JIRA maintenance like create the 3.2.1
> > version if someone can grant me that karma.
> >
> > On Tue, Feb 11, 2014 at 6:42 PM, Tony Chemit 
> wrote:
> > > On Wed, 12 Feb 2014 00:29:58 +
> > >
> > > Stephen Connolly  wrote:
> > > > Hurrah! At last!
> > > >
> > > > (at least until the "there must be a .0 release or the world will
> end"
> > >
> > > gang
> > >
> > > > on the PMC bash us back to 3.2.0)
> > >
> > > Stephen, I won't survive a none .0 version, what do I tell to my devs
> > > buddies ? :D
> > >
> > > At least, I will save me 2 hours finding back why I had a 3.1.1 on a
> > > server buggy with android plugin, just beacuse this was not the good
> 3.1.1
> > > version ;) Shame on me to test not final maven version ;).
> > >
> > > Nice decision guys to move forward.
> > >
> > > +1
> > >
> > > And viva then maven 3.2.1 \o/
> > >
> > > tony.
> > >
> > > --
> > > Tony Chemit
> > > 
> > > tél: +33 (0) 2 40 50 29 28
> > > http://www.codelutin.com
> > > email: che...@codelutin.com
> > > twitter: https://twitter.com/tchemit
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers,
Paul

Re: Convert everything to Git

[Hervé BOUTEMY]

the only show stopper I know is for svn trunk which contains a lot of 
components

so -1 for plugins, shared, skins, resources

but no problem for me for other release roots containing only one component 
[1]

notice I don't see much gain: did we get much patches for components already 
in git? did nobody send a patch through github for a svn component replicated 
to github? Is everybody fluent with git (I still ses much "merge" commits in 
git)
So what's the rationale, really? (apart from bashing one scm over the other, 
in one or another direction)

So I'm -0 on such a change for parts where I feel it would be feasible

Regards,

Hervé

[1] 
https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/dist-tool-check-source-release.html

Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit :
> Can we start the process of converting everything to Git. I don't really see
> any benefit in using Subversion any longer.
> 
> If so then we should just get together for a day and convert them and then
> get infra to use what we converted to do the flip.
> 
> Jason (who would be happy to never execute svn again)
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven Issue - pluginManagement - build Area Plugin

[Hervé BOUTEMY]

Hi,

See model builder algorithm [1]
If someone codes a version in build/plugin, that mean he wants to override 
value injected from build/pluginManagement

consequence is that once overridden, pluginManagement doesn't apply any more

so: defining a version in build/plugin in a global parent pom is generally a 
bad idea

Regards,

Hervé

[1] http://maven.apache.org/ref/3-LATEST/maven-model-builder/

Le mercredi 12 février 2014 21:07:28 Karl Heinz Marbaise a écrit :
> Hi,
> i have a question. The following situation. Pom file which uses the
> following parent:
> 
>  
>  org.codehaus
>  codehaus-parent
>  4
>  
> 
>  
>${mavenVersion}
>  
> 
> and the following part in my pom file:
> 
>  
>  
>  
>  
>  org.apache.maven.plugins
>  maven-enforcer-plugin
>  1.3.1
>  
>  
>  
>  
>  
>org.apache.maven.plugins
>maven-enforcer-plugin
>
>  
>enforce-maven
>
>... The rule does not matter..
> 
> 
> So if i call (Maven 2.2.1)
> 
> mvn clean package I got the following error:
> 
> [INFO] [clean:clean {execution: default-clean}]
> [INFO]
> 
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Failed to configure plugin parameters for:
> org.apache.maven.plugins:maven-enforcer-plugin:1.0
> 
> Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be
> instantiated
> 
> So if i call with Maven 3.0.5:
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce
> (enforce-maven) on project test-enforcer: Unable to parse configuration
> of mojo org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for
> parameter requireSameVersions: Abstract class or interface
> 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be instantiated
> -> [Help 1]
> 
> Maven 3.1.X and Maven 3.2.X tested as well...
> 
> So this looks to me that the pluginManagement does not overwrite the
> version 1.0 which is defined in the codehaus-parent. To be honest the
> codehaus-parent does not define it via pluginManagement it just uses the
> following:
> 
> 
>  
>  
>  org.apache.maven.plugins
>  maven-enforcer-plugin
>  1.0
>  
>  
>  enforce-maven
>  
>  enforce
>  
>  
>  
>  
> 
> (,2.1.0),(2.1.0,2.2.0),(2.2.0,)
>  Maven 2.1.0 and 2.2.0
> produce incorrect GPG signatures and checksums respectively.
>  
>  
>  
>  
>  
>  
>  
> 
> 
> First the codehaus-parent seemed to be wrong...so i can't overwrite the
> version of the plugin by using a pluginManagement block in inherited
> project which forces me to define the version explicitly in my pom in
> the build block to get that working like this:
> 
>  
>  
>org.apache.maven.plugins
>maven-enforcer-plugin
>1.3.1
>
> 
> 
> WDYT ? Bug ? Right behaviour ?
> 
> 
> Kind regards
> Karl-Heinz Marbaise
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.2.0

[Hervé BOUTEMY]

you mean you want to enter the committer school?

because Jira karma happens when going committer :)

Regards,

Hervé

Le mercredi 12 février 2014 13:14:16 Paul Benedict a écrit :
> I'll gladly do some low-hanging JIRA maintenance like create the 3.2.1
> version if someone can grant me that karma.
> 
> On Tue, Feb 11, 2014 at 6:42 PM, Tony Chemit  wrote:
> > On Wed, 12 Feb 2014 00:29:58 +
> > 
> > Stephen Connolly  wrote:
> > > Hurrah! At last!
> > > 
> > > (at least until the "there must be a .0 release or the world will end"
> > 
> > gang
> > 
> > > on the PMC bash us back to 3.2.0)
> > 
> > Stephen, I won't survive a none .0 version, what do I tell to my devs
> > buddies ? :D
> > 
> > At least, I will save me 2 hours finding back why I had a 3.1.1 on a
> > server buggy with android plugin, just beacuse this was not the good 3.1.1
> > version ;) Shame on me to test not final maven version ;).
> > 
> > Nice decision guys to move forward.
> > 
> > +1
> > 
> > And viva then maven 3.2.1 \o/
> > 
> > tony.
> > 
> > --
> > Tony Chemit
> > 
> > tél: +33 (0) 2 40 50 29 28
> > http://www.codelutin.com
> > email: che...@codelutin.com
> > twitter: https://twitter.com/tchemit
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Convert everything to Git

[Fred Cooke]

The SVN repo should probably be retained anyway, just in RO format, and
with a new URL that indicates it shouldn't be used. You can try to retain
all history, but it's never quite in the same form, really. Perhaps no one
cares, though?

+1 for decompose into individual repos.

Fred.

PS, perhaps one day we'll meet, who knows. :-p



On Thu, Feb 13, 2014 at 5:50 PM, Jason van Zyl  wrote:

> Probably a little more decompose like a repository for each plugin and
> shared component. No reason all history can't be retained.
>
> On Feb 12, 2014, at 11:03 PM, Mark Derricutt  wrote:
>
> > Do you envisage one master git repo, or multiple repositories for each
> moveable piece?
> >
> > Full history retainment?
> >
> > On 13 Feb 2014, at 16:37, Jason van Zyl wrote:
> >
> >> Can we start the process of converting everything to Git. I don't
> really see any benefit in using Subversion any longer.
> >>
> >> If so then we should just get together for a day and convert them and
> then get infra to use what we converted to do the flip.
> >>
> >> Jason (who would be happy to never execute svn again)
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> To do two things at once is to do neither.
>
>  -- Publilius Syrus, Roman slave, first century B.C.
>
>
>
>
>
>
>
>
>
>

Re: Convert everything to Git

[Jason van Zyl]

Probably a little more decompose like a repository for each plugin and shared 
component. No reason all history can't be retained.

On Feb 12, 2014, at 11:03 PM, Mark Derricutt  wrote:

> Do you envisage one master git repo, or multiple repositories for each 
> moveable piece?
> 
> Full history retainment?
> 
> On 13 Feb 2014, at 16:37, Jason van Zyl wrote:
> 
>> Can we start the process of converting everything to Git. I don't really see 
>> any benefit in using Subversion any longer.
>> 
>> If so then we should just get together for a day and convert them and then 
>> get infra to use what we converted to do the flip.
>> 
>> Jason (who would be happy to never execute svn again)
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

To do two things at once is to do neither.
 
 -- Publilius Syrus, Roman slave, first century B.C.

Re: Convert everything to Git

[Jason van Zyl]

That's only because you haven't met me in person.

On Feb 12, 2014, at 10:38 PM, Fred Cooke  wrote:

> I like you more and more! :-)
> 
> 
> On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl  wrote:
> 
>> Can we start the process of converting everything to Git. I don't really
>> see any benefit in using Subversion any longer.
>> 
>> If so then we should just get together for a day and convert them and then
>> get infra to use what we converted to do the flip.
>> 
>> Jason (who would be happy to never execute svn again)
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

Simplex sigillum veri. (Simplicity is the seal of truth.)

Re: Convert everything to Git

[Mark Derricutt]

Do you envisage one master git repo, or multiple repositories for each 
moveable piece?


Full history retainment?

On 13 Feb 2014, at 16:37, Jason van Zyl wrote:

Can we start the process of converting everything to Git. I don't 
really see any benefit in using Subversion any longer.


If so then we should just get together for a day and convert them and 
then get infra to use what we converted to do the flip.


Jason (who would be happy to never execute svn again)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Convert everything to Git

[Fred Cooke]

I like you more and more! :-)


On Thu, Feb 13, 2014 at 4:37 PM, Jason van Zyl  wrote:

> Can we start the process of converting everything to Git. I don't really
> see any benefit in using Subversion any longer.
>
> If so then we should just get together for a day and convert them and then
> get infra to use what we converted to do the flip.
>
> Jason (who would be happy to never execute svn again)
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Convert everything to Git

[Jason van Zyl]

Can we start the process of converting everything to Git. I don't really see 
any benefit in using Subversion any longer.

If so then we should just get together for a day and convert them and then get 
infra to use what we converted to do the flip.

Jason (who would be happy to never execute svn again)
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Getting a list of used artifacts

[Bernd Eckenfels]

Am Thu, 13 Feb 2014 02:19:17 +0100
schrieb Bernd Eckenfels :
> @Mojo(requiresDependencyCollection=TEST)
> project.getArtifacts()
> project.getPluginArtifacts()

Actual test  source is here:
https://github.com/ecki/lockdep-maven-plugin

Gruss
Bernd

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Getting a list of used artifacts

[Bernd Eckenfels]

Hello,

I want to write a plugin which does dump/verify the hashes of all
dependencies and plugins used in the build. That way I can "lock"
dependencies in the source not only by version, but also by checksum.

I have currently the following

@Mojo(requiresDependencyCollection=TEST)
project.getArtifacts()
project.getPluginArtifacts()

This looks about right, I get the dependencies of my project as well as
some plugins. For the Artifacts of the plugins I dont see a file
location, what would be the best way to get a file handle. Or is there
an alternate method where I can get the SHA1 hash of the (used) files?

Do you think this is a robust method to get hold of the most resolved
dependencies?

Gruss
Bernd

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Settings.xml nonProxyHosts Requires pipe-delimiter rather than commas

[Barnett, Ian]

I develop behind a proxy.  Some of our servers sit behind that proxy as well, 
including our Nexus Repository.  I have configured my settings.xml to point to 
our proxy but to ignore the hosts that are behind that proxy.  If I use a 
comma-delimited list in my nonProxyHosts, Maven seems to ignore that list and 
apply the proxy to those hosts as well.  If I use a pipe-delimited list in my 
nonProxyHosts, everything works great and Maven does NOT try to apply the proxy 
to those hosts.

According to this document only pipes are acceptable as delimiters, which is 
what I observed: https://maven.apache.org/guides/mini/guide-proxies.html

According to this document either pipes or commas are acceptable as delimiters 
which is incorrect according to my observation: 
https://maven.apache.org/settings.html (Proxies header)

This is an example of the proxies block in my settings.xml file that does not 
work.  When Maven needs to hit 123.456.789.111 or my.nexus.host, it applies the 
proxy to it.

  



  My Proxy

  true

  http

  

  

  my.proxy.com

  80

  localhost,123.456.789.*,my.nexus.host



  

This example WORKS.  Proxy is ignored for any requests to 123.456.789.111 or 
my.nexus.host, etc.


  



  My Proxy

  true

  http

  

  

  my.proxy.com

  80

  localhost|123.456.789.*|my.nexus.host



  

Environment:
Maven 3.1.1
Mac OS-X 10.9

Also reproduced this issue on:

Apache Maven 3.0.4

Ubuntu 11.04



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

[RESULT] [VOTE] Release Apache Maven Plugin Testing version 3.1.0

[Igor Fedorenko]

Hi,

The vote has passed with the following result:

+1 (binding): Jason, Olivier, Benson, Hervé
+1 (non binding): Igor

I will promote the artifacts to the central repo.

Can somebody with the awesome PMC powers copy the source release to the
Apache Distribution Area?


--
Regards,
Igor


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.2.0

[Igor Fedorenko]

I plan to restore the old/buggy behaviour and introduce new/correct api
later today.

--
Regards,
Igor

On 2/12/2014, 16:15, Mirko Friedenhagen wrote:

Hello Igor,

so you consider this a bug? While I agree with your xkcd (and may
easily work around the issue in the jacoco-maven-plugin) I do not see
any documentation on what artifactMap should hold, the String key is
not documented[0]. I see why you do not want to update the Major
version of Maven.

[0] 
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/MavenProject.java#L1142
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Feb 12, 2014 at 3:05 PM, Igor Fedorenko  wrote:

I lean towards keeping the current implementation as-is. Jococo maven
plugin relies on a bug in Maven core, there are at least two ways the
problem can be addressed by the plugin in a way compatible with 3.2.x
and earlier versions of Maven, and I think maintaining both the old
buggy code path and the new correct code path will introduce unnecessary
support burden on Maven core developers and confusion to Maven API users.

http://xkcd.com/1172/

--
Regards,
Igor


On 2/11/2014, 17:40, Igor Fedorenko wrote:


This is kinda tricky. We have three cases to consider

1. Plugin depends on main artifact only. For such dependency both 3.1.1
 and 3.2.0 use G:A key, so there is no problem there
2. Plugin depends on main and classified artifacts of the same GA. In
 this case 3.1.1 picked the last artifact and used it with G:A key,
 while 3.2.0 uses G:A for the main artifact and G:A:C for classified
 artifacts.
3. Plugin depends on classified artifact only. In this case 3.1.1 uses
 G:A key and 3.2.0 uses G:A:C

And I really need to support case #2 ;-)

The only 100% backwards compatible solution seems to keep the original
MavenProject#pluginArtifactMap and MavenProject#artifactMap as is, but
deprecate them and introduce new behaviour as new #pluginArtifactMapC
and #artifactMap members.

Does anyone see other options?


--
Regards,
Igor

On 2/11/2014, 16:39, Mirko Friedenhagen wrote:


Hello,

I probably found the culprit for my issue
https://jira.codehaus.org/browse/MNG-5552:
- This introduces the option to use a classifier when looking up stuff
from the ${plugin.artifactMap}
- Now the jacoco-maven-plugin uses an agent
(GAVC="org.jacoco:org.jacoco.agent:VERSION:runtime") which has a
classifier "runtime".
- With Maven < 3.2.0 the agent could be looked up (artifactMap.get)
with "org.jacoco:org.jacoco.agent", the key in the map was GA.
- With Maven 3.2.0 the key is now GAC
("org.jacoco:org.jacoco.agent:runtime")
- So now you are forced to give the classifier as well for the lookup,
when doing this it will break backwards compatibility.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Feb 11, 2014 at 4:42 PM, Mirko Friedenhagen
 wrote:


Hello,

not sure what's happening here. There seems to be a regression with
the jacoco-maven-plugin (works fine with Maven 3.0.2 and Maven 3.1.1).
What I did:
- Checked out https://github.com/1and1/testlink-junit
- Now running mvn320 -V -e clean verify gives the following:

12670 [ERROR] Failed to execute goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
(default-prepare-agent) on project tljunit-surefire: Execution
default-prepare-agent of goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
(default-prepare-agent) on project tljunit-surefire: Execution
default-prepare-agent of goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
failed.
at

org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)

at

org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

at

org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

at

org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)

at

org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)

at

org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at

org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.refle

Re: [VOTE] Release Maven 3.2.0

[Stephen Connolly]

We are not changing the public api signature, and the keys were
undocumented previously, so this does not need a bump to 4.0 IMHO (even if
that would get modelVersion 5.0 aligned with the Maven version)

On Wednesday, 12 February 2014, Mirko Friedenhagen 
wrote:

> Hello Igor,
>
> so you consider this a bug? While I agree with your xkcd (and may
> easily work around the issue in the jacoco-maven-plugin) I do not see
> any documentation on what artifactMap should hold, the String key is
> not documented[0]. I see why you do not want to update the Major
> version of Maven.
>
> [0]
> https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/MavenProject.java#L1142
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> https://bitbucket.org/mfriedenhagen/
>
>
> On Wed, Feb 12, 2014 at 3:05 PM, Igor Fedorenko 
> wrote:
> > I lean towards keeping the current implementation as-is. Jococo maven
> > plugin relies on a bug in Maven core, there are at least two ways the
> > problem can be addressed by the plugin in a way compatible with 3.2.x
> > and earlier versions of Maven, and I think maintaining both the old
> > buggy code path and the new correct code path will introduce unnecessary
> > support burden on Maven core developers and confusion to Maven API users.
> >
> > http://xkcd.com/1172/
> >
> > --
> > Regards,
> > Igor
> >
> >
> > On 2/11/2014, 17:40, Igor Fedorenko wrote:
> >>
> >> This is kinda tricky. We have three cases to consider
> >>
> >> 1. Plugin depends on main artifact only. For such dependency both 3.1.1
> >> and 3.2.0 use G:A key, so there is no problem there
> >> 2. Plugin depends on main and classified artifacts of the same GA. In
> >> this case 3.1.1 picked the last artifact and used it with G:A key,
> >> while 3.2.0 uses G:A for the main artifact and G:A:C for classified
> >> artifacts.
> >> 3. Plugin depends on classified artifact only. In this case 3.1.1 uses
> >> G:A key and 3.2.0 uses G:A:C
> >>
> >> And I really need to support case #2 ;-)
> >>
> >> The only 100% backwards compatible solution seems to keep the original
> >> MavenProject#pluginArtifactMap and MavenProject#artifactMap as is, but
> >> deprecate them and introduce new behaviour as new #pluginArtifactMapC
> >> and #artifactMap members.
> >>
> >> Does anyone see other options?
> >>
> >>
> >> --
> >> Regards,
> >> Igor
> >>
> >> On 2/11/2014, 16:39, Mirko Friedenhagen wrote:
> >>>
> >>> Hello,
> >>>
> >>> I probably found the culprit for my issue
> >>> https://jira.codehaus.org/browse/MNG-5552:
> >>> - This introduces the option to use a classifier when looking up stuff
> >>> from the ${plugin.artifactMap}
> >>> - Now the jacoco-maven-plugin uses an agent
> >>> (GAVC="org.jacoco:org.jacoco.agent:VERSION:runtime") which has a
> >>> classifier "runtime".
> >>> - With Maven < 3.2.0 the agent could be looked up (artifactMap.get)
> >>> with "org.jacoco:org.jacoco.agent", the key in the map was GA.
> >>> - With Maven 3.2.0 the key is now GAC
> >>> ("org.jacoco:org.jacoco.agent:runtime")
> >>> - So now you are forced to give the classifier as well for the lookup,
> >>> when doing this it will break backwards compatibility.
> >>> Regards Mirko
> >>> --
> >>> http://illegalstateexception.blogspot.com/
> >>> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
> >>> https://bitbucket.org/mfriedenhagen/
> >>>
> >>>
> >>> On Tue, Feb 11, 2014 at 4:42 PM, Mirko Friedenhagen
> >>>  wrote:
> 
>  Hello,
> 
>  not sure what's happening here. There seems to be a regression with
>  the jacoco-maven-plugin (works fine with Maven 3.0.2 and Maven 3.1.1).
>  What I did:
>  - Checked out https://github.com/1and1/testlink-junit
>  - Now running mvn320 -V -e clean verify gives the following:
> 
>  12670 [ERROR] Failed to execute goal
>  org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
>  (default-prepare-agent) on project tljunit-surefire: Execution
>  default-prepare-agent of goal
>  org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
>  failed



-- 
Sent from my phone

Re: [VOTE] Release Maven 3.2.0

[Mirko Friedenhagen]

Hello Igor,

so you consider this a bug? While I agree with your xkcd (and may
easily work around the issue in the jacoco-maven-plugin) I do not see
any documentation on what artifactMap should hold, the String key is
not documented[0]. I see why you do not want to update the Major
version of Maven.

[0] 
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/project/MavenProject.java#L1142
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Wed, Feb 12, 2014 at 3:05 PM, Igor Fedorenko  wrote:
> I lean towards keeping the current implementation as-is. Jococo maven
> plugin relies on a bug in Maven core, there are at least two ways the
> problem can be addressed by the plugin in a way compatible with 3.2.x
> and earlier versions of Maven, and I think maintaining both the old
> buggy code path and the new correct code path will introduce unnecessary
> support burden on Maven core developers and confusion to Maven API users.
>
> http://xkcd.com/1172/
>
> --
> Regards,
> Igor
>
>
> On 2/11/2014, 17:40, Igor Fedorenko wrote:
>>
>> This is kinda tricky. We have three cases to consider
>>
>> 1. Plugin depends on main artifact only. For such dependency both 3.1.1
>> and 3.2.0 use G:A key, so there is no problem there
>> 2. Plugin depends on main and classified artifacts of the same GA. In
>> this case 3.1.1 picked the last artifact and used it with G:A key,
>> while 3.2.0 uses G:A for the main artifact and G:A:C for classified
>> artifacts.
>> 3. Plugin depends on classified artifact only. In this case 3.1.1 uses
>> G:A key and 3.2.0 uses G:A:C
>>
>> And I really need to support case #2 ;-)
>>
>> The only 100% backwards compatible solution seems to keep the original
>> MavenProject#pluginArtifactMap and MavenProject#artifactMap as is, but
>> deprecate them and introduce new behaviour as new #pluginArtifactMapC
>> and #artifactMap members.
>>
>> Does anyone see other options?
>>
>>
>> --
>> Regards,
>> Igor
>>
>> On 2/11/2014, 16:39, Mirko Friedenhagen wrote:
>>>
>>> Hello,
>>>
>>> I probably found the culprit for my issue
>>> https://jira.codehaus.org/browse/MNG-5552:
>>> - This introduces the option to use a classifier when looking up stuff
>>> from the ${plugin.artifactMap}
>>> - Now the jacoco-maven-plugin uses an agent
>>> (GAVC="org.jacoco:org.jacoco.agent:VERSION:runtime") which has a
>>> classifier "runtime".
>>> - With Maven < 3.2.0 the agent could be looked up (artifactMap.get)
>>> with "org.jacoco:org.jacoco.agent", the key in the map was GA.
>>> - With Maven 3.2.0 the key is now GAC
>>> ("org.jacoco:org.jacoco.agent:runtime")
>>> - So now you are forced to give the classifier as well for the lookup,
>>> when doing this it will break backwards compatibility.
>>> Regards Mirko
>>> --
>>> http://illegalstateexception.blogspot.com/
>>> https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
>>> https://bitbucket.org/mfriedenhagen/
>>>
>>>
>>> On Tue, Feb 11, 2014 at 4:42 PM, Mirko Friedenhagen
>>>  wrote:

 Hello,

 not sure what's happening here. There seems to be a regression with
 the jacoco-maven-plugin (works fine with Maven 3.0.2 and Maven 3.1.1).
 What I did:
 - Checked out https://github.com/1and1/testlink-junit
 - Now running mvn320 -V -e clean verify gives the following:

 12670 [ERROR] Failed to execute goal
 org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
 (default-prepare-agent) on project tljunit-surefire: Execution
 default-prepare-agent of goal
 org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
 failed. NullPointerException -> [Help 1]
 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
 execute goal
 org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
 (default-prepare-agent) on project tljunit-surefire: Execution
 default-prepare-agent of goal
 org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
 failed.
 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)

 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

 at

 org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

 at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)

 at

 org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)

 at

 org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

 at

 org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)

 at org.apache.maven.DefaultMaven.doExecute(Defa

Maven Issue - pluginManagement - build Area Plugin

[Karl Heinz Marbaise]

Hi,
i have a question. The following situation. Pom file which uses the 
following parent:



org.codehaus
codehaus-parent
4



  ${mavenVersion}


and the following part in my pom file:





org.apache.maven.plugins
maven-enforcer-plugin
1.3.1





  org.apache.maven.plugins
  maven-enforcer-plugin
  

  enforce-maven
  
  ... The rule does not matter..


So if i call (Maven 2.2.1)

mvn clean package I got the following error:

[INFO] [clean:clean {execution: default-clean}]
[INFO] 


[ERROR] BUILD ERROR
[INFO] 

[INFO] Failed to configure plugin parameters for: 
org.apache.maven.plugins:maven-enforcer-plugin:1.0


Cause: Class 'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be 
instantiated


So if i call with Maven 3.0.5:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce 
(enforce-maven) on project test-enforcer: Unable to parse configuration 
of mojo org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce for 
parameter requireSameVersions: Abstract class or interface 
'org.apache.maven.enforcer.rule.api.EnforcerRule' cannot be instantiated 
-> [Help 1]


Maven 3.1.X and Maven 3.2.X tested as well...

So this looks to me that the pluginManagement does not overwrite the 
version 1.0 which is defined in the codehaus-parent. To be honest the 
codehaus-parent does not define it via pluginManagement it just uses the 
following:





org.apache.maven.plugins
maven-enforcer-plugin
1.0


enforce-maven

enforce





(,2.1.0),(2.1.0,2.2.0),(2.2.0,)
Maven 2.1.0 and 2.2.0 
produce incorrect GPG signatures and checksums respectively.










First the codehaus-parent seemed to be wrong...so i can't overwrite the 
version of the plugin by using a pluginManagement block in inherited 
project which forces me to define the version explicitly in my pom in 
the build block to get that working like this:




  org.apache.maven.plugins
  maven-enforcer-plugin
  1.3.1
  


WDYT ? Bug ? Right behaviour ?


Kind regards
Karl-Heinz Marbaise


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.2.0

[Paul Benedict]

I'll gladly do some low-hanging JIRA maintenance like create the 3.2.1
version if someone can grant me that karma.


On Tue, Feb 11, 2014 at 6:42 PM, Tony Chemit  wrote:

> On Wed, 12 Feb 2014 00:29:58 +
> Stephen Connolly  wrote:
>
> > Hurrah! At last!
> >
> > (at least until the "there must be a .0 release or the world will end"
> gang
> > on the PMC bash us back to 3.2.0)
>
> Stephen, I won't survive a none .0 version, what do I tell to my devs
> buddies ? :D
>
> At least, I will save me 2 hours finding back why I had a 3.1.1 on a
> server buggy with android plugin, just beacuse this was not the good 3.1.1
> version ;) Shame on me to test not final maven version ;).
>
> Nice decision guys to move forward.
>
> +1
>
> And viva then maven 3.2.1 \o/
>
> tony.
>
> --
> Tony Chemit
> 
> tél: +33 (0) 2 40 50 29 28
> http://www.codelutin.com
> email: che...@codelutin.com
> twitter: https://twitter.com/tchemit
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Cheers,
Paul

Re: [VOTE] Release Maven 3.2.0

[Jason van Zyl]

Ok, that's fixed now.

On Feb 11, 2014, at 12:57 PM, jieryn  wrote:

> Regression from Apache Maven 3.1.1, seen via:
> 
> bash$ mvn -e -Dmaven.test.skip=true -DskipTests=true -T 2.0C clean install 
> "$@"
> [ERROR] Error executing Maven.
> java.lang.NumberFormatException: For input string: "2.0"
>at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>at java.lang.Integer.parseInt(Integer.java:492)
>at java.lang.Integer.valueOf(Integer.java:582)
>at org.apache.maven.cli.MavenCli.populateRequest(MavenCli.java:1092)
>at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:210)
>at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:606)
>at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 
> I'd say this would be a blocker, we use --threads * core multiplier
> support on a variety of platforms for automatic scaling.
> 
> 
> On Mon, Feb 10, 2014 at 9:18 PM, Jason van Zyl  wrote:
>> Time to release Maven 3.2.0!
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau 

Re: [Committer School] I would like to become a committer

[Stephen Connolly]

Woot! School roll is back up to 2!!!

Patches that apply cleanly using the backing SCM system are best... so if
the component is using GIT then patches that GIt can apply should be
recommended. If the component is using Subversion, then patches that `svn
patch` can apply are recommended (of course people using older versions of
svn that don't have the patch subcommand will have a poorer patch
application time... but perhaps they can upgrade their svn client!


On 12 February 2014 14:33, Baptiste Mathus  wrote:

> Hi all,
>
> Some of you already know me through MOJO and my posts here, and I would
> like to try to get more involved in that Apache Maven tool I really like.
>
> I am interested in the following areas:
> enforcer, scm, release, and some others when needed...
>
> If anyone knows any issues that I could take a look at I would be very much
> appreciated.
>
> I've recently proposed a patch for
> ARCHETYPE-456,
> and currently working on SCM-741 [1] (my next goal is to see how this
> improvement can also be wired into the release-plugin and
> tackle MRELEASE-445 to validate the svn tagBase before starting, something
> that already bit me in the past).
>
> Thanks
>
> [1] https://jira.codehaus.org/browse/SCM-741
>and my current github branch
> https://github.com/Batmat/maven-scm/tree/SCM-741
>(already working on my machine, but missing tests because
> I'm somehow unable to run the whole test suite on my machine without it
> failing (even without my changes) :-/)
>
>
> -- Baptiste
>
> PS : btw, as most apache maven projects are also present on github, I
> wonder if there's a preferred patch format. Is
>
> http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patchan
> up-to-date reference?
>

[Committer School] I would like to become a committer

[Baptiste Mathus]

Hi all,

Some of you already know me through MOJO and my posts here, and I would
like to try to get more involved in that Apache Maven tool I really like.

I am interested in the following areas:
enforcer, scm, release, and some others when needed...

If anyone knows any issues that I could take a look at I would be very much
appreciated.

I've recently proposed a patch for
ARCHETYPE-456,
and currently working on SCM-741 [1] (my next goal is to see how this
improvement can also be wired into the release-plugin and
tackle MRELEASE-445 to validate the svn tagBase before starting, something
that already bit me in the past).

Thanks

[1] https://jira.codehaus.org/browse/SCM-741
   and my current github branch
https://github.com/Batmat/maven-scm/tree/SCM-741
   (already working on my machine, but missing tests because
I'm somehow unable to run the whole test suite on my machine without it
failing (even without my changes) :-/)


-- Baptiste

PS : btw, as most apache maven projects are also present on github, I
wonder if there's a preferred patch format. Is
http://maven.apache.org/guides/development/guide-m2-development.html#Creating_and_submitting_a_patchan
up-to-date reference?

Re: [VOTE] Release Maven 3.2.0

[Igor Fedorenko]

I lean towards keeping the current implementation as-is. Jococo maven
plugin relies on a bug in Maven core, there are at least two ways the
problem can be addressed by the plugin in a way compatible with 3.2.x
and earlier versions of Maven, and I think maintaining both the old
buggy code path and the new correct code path will introduce unnecessary
support burden on Maven core developers and confusion to Maven API users.

http://xkcd.com/1172/

--
Regards,
Igor

On 2/11/2014, 17:40, Igor Fedorenko wrote:

This is kinda tricky. We have three cases to consider

1. Plugin depends on main artifact only. For such dependency both 3.1.1
and 3.2.0 use G:A key, so there is no problem there
2. Plugin depends on main and classified artifacts of the same GA. In
this case 3.1.1 picked the last artifact and used it with G:A key,
while 3.2.0 uses G:A for the main artifact and G:A:C for classified
artifacts.
3. Plugin depends on classified artifact only. In this case 3.1.1 uses
G:A key and 3.2.0 uses G:A:C

And I really need to support case #2 ;-)

The only 100% backwards compatible solution seems to keep the original
MavenProject#pluginArtifactMap and MavenProject#artifactMap as is, but
deprecate them and introduce new behaviour as new #pluginArtifactMapC
and #artifactMap members.

Does anyone see other options?


--
Regards,
Igor

On 2/11/2014, 16:39, Mirko Friedenhagen wrote:

Hello,

I probably found the culprit for my issue
https://jira.codehaus.org/browse/MNG-5552:
- This introduces the option to use a classifier when looking up stuff
from the ${plugin.artifactMap}
- Now the jacoco-maven-plugin uses an agent
(GAVC="org.jacoco:org.jacoco.agent:VERSION:runtime") which has a
classifier "runtime".
- With Maven < 3.2.0 the agent could be looked up (artifactMap.get)
with "org.jacoco:org.jacoco.agent", the key in the map was GA.
- With Maven 3.2.0 the key is now GAC
("org.jacoco:org.jacoco.agent:runtime")
- So now you are forced to give the classifier as well for the lookup,
when doing this it will break backwards compatibility.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Tue, Feb 11, 2014 at 4:42 PM, Mirko Friedenhagen
 wrote:

Hello,

not sure what's happening here. There seems to be a regression with
the jacoco-maven-plugin (works fine with Maven 3.0.2 and Maven 3.1.1).
What I did:
- Checked out https://github.com/1and1/testlink-junit
- Now running mvn320 -V -e clean verify gives the following:

12670 [ERROR] Failed to execute goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
(default-prepare-agent) on project tljunit-surefire: Execution
default-prepare-agent of goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
(default-prepare-agent) on project tljunit-surefire: Execution
default-prepare-agent of goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)

at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)

at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)

at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)

at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)

at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)

at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)

at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-prepare-agent of goal
org.jacoco:jacoco-maven-plugin:0.6.4.201312101107:prepare-agent
failed.
at
org.apache.maven.plugin.Default

Re: Respinned releases and versions Re: [VOTE] Release Maven 3.2.0

[Chris Graham]

I prefer not to rehash what we all went painstakingly over a few months
back...


On Wed, Feb 12, 2014 at 8:06 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On 12 February 2014 08:35, Arnaud Héritier  wrote:
>
> > Hi,
> >
> >   I'm in favor to not reuse the version. Like many others I'm often lost
> > between intermediate and final versions (but we can see it also as a
> maven
> > dev and advanced users privilege/constraint too - thus applying to very
> few
> > people).
> >
> >  We discussed about it many times and AFAIK we have 2 solutions to
> achieve
> > this :
> >
> >   1/ We just pass some minor versions like Apache Tomcat is doing (
> > http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many
> > "not released" versions). We announce only releases considered stable
> > (let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and
> > versions in Jira. Users will have to take care to append all release
> notes
> > of none stable version to know what we changed between two stables
> versions
> > (or we have to do it for them).
> >   2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it
> is
> > like Sonatype Nexus team is doing. We have distinct tags in our SCM
> > (3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable
> > version we publicly announce. In Jira we only have a 3.2.0 version and we
> > just reopen or add issues in it to track the release landing. For users
> > we'll just announce a 3.2.0 but the binary they'll have will be called
> > 3.2.0_2 for example.
> >
> >   In both cases we will throw in the bin unstable releases.
> >
> >   I like both approaches and prefer them compared to our current one.
> >   Between both of them I would prefer the second one (transparent for
> users
> > and not difficult for us).
> >
> >   WDYT ?
> >
>
> I prefer any scheme where we do not reuse a version number *ever*.
>
> We can handle the JIRA problem by just moving the issues fixed in forward
> (or just renaming the version that wasn't released in JIRA)
>
> The version was never released therefore it doesn't exist. The only
> remnants would be the tag in SCM.
>
> If there are any users "confused" then we just tell them the answer "that
> version just didn't meet our release criteria"...
>
> The users will get over it... plugins or core... they will still get over
> it... they don't care what version number we give something once bigger
> numbers have more features and/or less bugs
>
> The only down side I can see is that we would be admitting that we have a
> quality bar... right now, unless you follow the dev list, it could seem
> that we don't do a lot of testing of releases - because you don't see all
> the (take 2) style votes. By skipping version numbers we would be saying
> "look here we do have a quality bar" and users would then be able to
> complain about how low that bar is with respect to their expectations...
>
> Still I would rather that kind of pressure from users and field questions
> like "what happened to 3.2.0?" than respin 3.2.0
>
> That is my EURO 0.02
>
> As always the chair will bow to the decision of the PMC committee!
>
> -Stephen
>
>
> >
> > Note : Even If I'm in favor of this change I really don't want to hold up
> > the current release which such debate/vote thus I think it may be better
> to
> > apply this change only for the next release depending of how many time
> all
> > active developers think they need to finalize the 3.2.0 release and
> launch
> > another vote.
> >
> > Arnaud
> >
> >
> > On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt  wrote:
> >
> > > On 12 Feb 2014, at 13:57, Benson Margulies wrote:
> > >
> > > > 3.2.0.1 :-)
> > >
> > > 3.2.0-patchlevel-1-GA.
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > For additional commands, e-mail: dev-h...@maven.apache.org
> > >
> > >
> >
> >
> > --
> > -
> > Arnaud Héritier
> > http://aheritier.net
> > Mail/GTalk: aheritier AT gmail DOT com
> > Twitter/Skype : aheritier
> >
>

Re: Respinned releases and versions Re: [VOTE] Release Maven 3.2.0

[Stephen Connolly]

On 12 February 2014 08:35, Arnaud Héritier  wrote:

> Hi,
>
>   I'm in favor to not reuse the version. Like many others I'm often lost
> between intermediate and final versions (but we can see it also as a maven
> dev and advanced users privilege/constraint too - thus applying to very few
> people).
>
>  We discussed about it many times and AFAIK we have 2 solutions to achieve
> this :
>
>   1/ We just pass some minor versions like Apache Tomcat is doing (
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many
> "not released" versions). We announce only releases considered stable
> (let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and
> versions in Jira. Users will have to take care to append all release notes
> of none stable version to know what we changed between two stables versions
> (or we have to do it for them).
>   2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it is
> like Sonatype Nexus team is doing. We have distinct tags in our SCM
> (3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable
> version we publicly announce. In Jira we only have a 3.2.0 version and we
> just reopen or add issues in it to track the release landing. For users
> we'll just announce a 3.2.0 but the binary they'll have will be called
> 3.2.0_2 for example.
>
>   In both cases we will throw in the bin unstable releases.
>
>   I like both approaches and prefer them compared to our current one.
>   Between both of them I would prefer the second one (transparent for users
> and not difficult for us).
>
>   WDYT ?
>

I prefer any scheme where we do not reuse a version number *ever*.

We can handle the JIRA problem by just moving the issues fixed in forward
(or just renaming the version that wasn't released in JIRA)

The version was never released therefore it doesn't exist. The only
remnants would be the tag in SCM.

If there are any users "confused" then we just tell them the answer "that
version just didn't meet our release criteria"...

The users will get over it... plugins or core... they will still get over
it... they don't care what version number we give something once bigger
numbers have more features and/or less bugs

The only down side I can see is that we would be admitting that we have a
quality bar... right now, unless you follow the dev list, it could seem
that we don't do a lot of testing of releases - because you don't see all
the (take 2) style votes. By skipping version numbers we would be saying
"look here we do have a quality bar" and users would then be able to
complain about how low that bar is with respect to their expectations...

Still I would rather that kind of pressure from users and field questions
like "what happened to 3.2.0?" than respin 3.2.0

That is my EURO 0.02

As always the chair will bow to the decision of the PMC committee!

-Stephen


>
> Note : Even If I'm in favor of this change I really don't want to hold up
> the current release which such debate/vote thus I think it may be better to
> apply this change only for the next release depending of how many time all
> active developers think they need to finalize the 3.2.0 release and launch
> another vote.
>
> Arnaud
>
>
> On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt  wrote:
>
> > On 12 Feb 2014, at 13:57, Benson Margulies wrote:
> >
> > > 3.2.0.1 :-)
> >
> > 3.2.0-patchlevel-1-GA.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Re: Respinned releases and versions Re: [VOTE] Release Maven 3.2.0

[Anders Hammar]

Clarification to 2): Sonatype uses the x.y.z-b version scheme (dash, not
underscore) which works with Maven's suggsted version syntax. This is also
the syntax I use for all customers I work with and that use staging.
The 'b' is the release build, which starts on '1' and is incremented for
each new release.

Earlier we used to do RC builds (or at least Benjamin did so) which I found
very good to test new core versions early. The drawback was that we had to
respin to get rid of the 'RC' in the version.

In any case, we've discussed this earlier and even voted on it I believe.
Regardless of what one individual thinks is "the right way", I don't think
it's cool to just ignore what has already been decided on.
Personally I don't even see the problem re-using version numbers for Maven
core releases. For plugin releases there is a much more likely to be some
confusion though.

/Anders


On Wed, Feb 12, 2014 at 9:35 AM, Arnaud Héritier wrote:

> Hi,
>
>   I'm in favor to not reuse the version. Like many others I'm often lost
> between intermediate and final versions (but we can see it also as a maven
> dev and advanced users privilege/constraint too - thus applying to very few
> people).
>
>  We discussed about it many times and AFAIK we have 2 solutions to achieve
> this :
>
>   1/ We just pass some minor versions like Apache Tomcat is doing (
> http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many
> "not released" versions). We announce only releases considered stable
> (let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and
> versions in Jira. Users will have to take care to append all release notes
> of none stable version to know what we changed between two stables versions
> (or we have to do it for them).
>   2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it is
> like Sonatype Nexus team is doing. We have distinct tags in our SCM
> (3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable
> version we publicly announce. In Jira we only have a 3.2.0 version and we
> just reopen or add issues in it to track the release landing. For users
> we'll just announce a 3.2.0 but the binary they'll have will be called
> 3.2.0_2 for example.
>
>   In both cases we will throw in the bin unstable releases.
>
>   I like both approaches and prefer them compared to our current one.
>   Between both of them I would prefer the second one (transparent for users
> and not difficult for us).
>
>   WDYT ?
>
> Note : Even If I'm in favor of this change I really don't want to hold up
> the current release which such debate/vote thus I think it may be better to
> apply this change only for the next release depending of how many time all
> active developers think they need to finalize the 3.2.0 release and launch
> another vote.
>
> Arnaud
>
>
> On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt  wrote:
>
> > On 12 Feb 2014, at 13:57, Benson Margulies wrote:
> >
> > > 3.2.0.1 :-)
> >
> > 3.2.0-patchlevel-1-GA.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
>
> --
> -
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>

Respinned releases and versions Re: [VOTE] Release Maven 3.2.0

[Arnaud Héritier]

Hi,

  I'm in favor to not reuse the version. Like many others I'm often lost
between intermediate and final versions (but we can see it also as a maven
dev and advanced users privilege/constraint too - thus applying to very few
people).

 We discussed about it many times and AFAIK we have 2 solutions to achieve
this :

  1/ We just pass some minor versions like Apache Tomcat is doing (
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html you may find many
"not released" versions). We announce only releases considered stable
(let's say 3.2.1 and not 3.2.0), we have distinct tags in our SCM and
versions in Jira. Users will have to take care to append all release notes
of none stable version to know what we changed between two stables versions
(or we have to do it for them).
  2/ We add an extra release number like 3.2.0_1, 3.2.0_2... I think it is
like Sonatype Nexus team is doing. We have distinct tags in our SCM
(3.2.0_1, 3.2.0_2) but we can manually add a 3.2.0 tag to the stable
version we publicly announce. In Jira we only have a 3.2.0 version and we
just reopen or add issues in it to track the release landing. For users
we'll just announce a 3.2.0 but the binary they'll have will be called
3.2.0_2 for example.

  In both cases we will throw in the bin unstable releases.

  I like both approaches and prefer them compared to our current one.
  Between both of them I would prefer the second one (transparent for users
and not difficult for us).

  WDYT ?

Note : Even If I'm in favor of this change I really don't want to hold up
the current release which such debate/vote thus I think it may be better to
apply this change only for the next release depending of how many time all
active developers think they need to finalize the 3.2.0 release and launch
another vote.

Arnaud


On Wed, Feb 12, 2014 at 3:05 AM, Mark Derricutt  wrote:

> On 12 Feb 2014, at 13:57, Benson Margulies wrote:
>
> > 3.2.0.1 :-)
>
> 3.2.0-patchlevel-1-GA.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier