date:20110114

Re: Classloader Problem with Maven 3.0.2

2011-01-14 Thread Wayne Fay

> A closer look at the logs show that Surefire runs the unit tests, then 
> Failsafe runs
> the single unit test configured (which fails because of the classloader 
> issues I
> began the thread with), and then Failsafe runs all the integration tests.
>
> Clearly something is misconfigured to cause that third block of testing and to
> create the classloader errors. Any insight is appreciated.

Did you check "mvn help:effective-pom" in your project/module to be
certain that some plugin configuration from a parent pom etc is not
contributing a configuration you had forgotten about or simply did not
realize was in effect to cause this third execution?

Wayne

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

Re: Welcome Wayne Fay to the Maven PMC

2011-01-14 Thread Stephen Connolly

congrats

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 15 Jan 2011 01:13, "Jesse Farinacci"  wrote:
> Congratulations, Wayne!! Thanks for all your efforts,
>
> On Fri, Jan 14, 2011 at 8:08 PM, Brian Fox  wrote:
>> I'm sure you all know Wayne since he's been around forever answering
>> user list questions. We recently voted him in both as a committer and
>> a PMC member, so please join me in congratulating him. We're secretly
>> hoping that he'll use his commit rights to start improving the
>> documentation since he's so good at answering questions ;-)
>>
>> Welcome Wayne!
>>
>> --Brian Fox
>> Apache Maven PMC Chair
>
> -Jesse
>
> --
> There are 10 types of people in this world, those
> that can read binary and those that can not.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>

Re: Welcome Wayne Fay to the Maven PMC

2011-01-14 Thread Jesse Farinacci

Congratulations, Wayne!! Thanks for all your efforts,

On Fri, Jan 14, 2011 at 8:08 PM, Brian Fox  wrote:
> I'm sure you all know Wayne since he's been around forever answering
> user list questions. We recently voted him in both as a committer and
> a PMC member, so please join me in congratulating him. We're secretly
> hoping that he'll use his commit rights to start improving the
> documentation since he's so good at answering questions ;-)
>
> Welcome Wayne!
>
> --Brian Fox
> Apache Maven PMC Chair

-Jesse

-- 
There are 10 types of people in this world, those
that can read binary and those that can not.

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

Re: Maven 3: deploy-file error 500 on Nexus Repo

2011-01-14 Thread Brian Fox

The 500 is an internal error on the Nexus side. We'll need to see your
Nexus logs to see what happened. You should send those to the nexus
user list for a quicker answer.

On Fri, Jan 14, 2011 at 9:01 AM, martib  wrote:
>
> I'm facing a problem under M3.0.2 or 3.0.1 with Nexus Repository
>  mvn deploy:deploy-file ...
>
> I've got a proxy-setting in my settings.xml.
> Everything works fine with Maven 2.2.1 and proxy configuration without
> change.
>
> But with Maven 3, I'm getting this error:
> (Environment: Maven 3.0.2, JDK 6, Nexus 1.8.0.1)
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file (default-cli)
> on project _no
> ne_maven_wlfulljar: Failed to deploy artifacts: Could not transfer artifact
> com.bea.weblogic:core-descriptor-wl:jar:1.3.
> 2.0 from/to thirdparty-repo
> (http://maven.x.ch:2501/nexus/content/repositories/thirdparty-repo):
> Failed to tr
> ansfer file:
> http://maven.x.ch:2501/nexus/content/repositories/thirdparty-repo/com/bea/weblogic/core-descriptor-
> wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar. Return code is: 500 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-deploy-plu
> gin:2.5:deploy-file (default-cli) on project _none_maven_wlfulljar: Failed
> to deploy artifacts: Could not transfer artif
> act com.bea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to thirdparty-repo
> (http://maven.x.ch:2501/nexus/conten
> t/repositories/thirdparty-repo): Failed to transfer file:
> http://maven.x.ch:2501/nexus/content/repositories/thir
> dparty-repo/com/bea/weblogic/core-descriptor-wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar.
> Return code is: 500
>        at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
>        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:84)
>        at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:60)
>        at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
>        at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
>        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
>        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
>        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>        at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>        at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
>        at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
>        at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
>        at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:354)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to deploy
> artifacts: Could not transfer artifact com.b
> ea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to thirdparty-repo
> (http://maven.x.ch:2501/nexus/content/reposit
> ories/thirdparty-repo): Failed to transfer file:
> http://maven.x.ch:2501/nexus/content/repositories/thirdparty-ie
> u-web/com/bea/weblogic/core-descriptor-wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar.
> Return code is: 500
>        at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240)
>        at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
>        at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
>        ... 19 more
> Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
> Failed to deploy artifacts: Could not transfe
> r artifact com.bea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to
> thirdparty-repo (http://maven.x.ch:2501/nexus
> /content/repositories/thirdparty-repo): Failed to transfer file:
> http://maven.x.ch:2501/nexus/content/repositori
> es/thirdparty-repo/com/bea/weblogic/core-descriptor-wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar.
> Return code is: 500
>        at
> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:140)
>        at
> org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:236)
>

Welcome Wayne Fay to the Maven PMC

2011-01-14 Thread Brian Fox

I'm sure you all know Wayne since he's been around forever answering
user list questions. We recently voted him in both as a committer and
a PMC member, so please join me in congratulating him. We're secretly
hoping that he'll use his commit rights to start improving the
documentation since he's so good at answering questions ;-)

Welcome Wayne!

--Brian Fox
Apache Maven PMC Chair

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

RE: Classloader Problem with Maven 3.0.2

2011-01-14 Thread Neil Chaudhuri

A closer look at the logs show that Surefire runs the unit tests, then Failsafe 
runs the single unit test configured (which fails because of the classloader 
issues I began the thread with), and then Failsafe runs all the integration 
tests.

Clearly something is misconfigured to cause that third block of testing and to 
create the classloader errors. Any insight is appreciated.

Thanks. 

-Original Message-
From: Neil Chaudhuri 
Sent: Friday, January 14, 2011 6:46 PM
To: Maven Users List
Subject: RE: Classloader Problem with Maven 3.0.2

I upgraded Failsafe to 2.7.1, and things definitely progressed, but two 
interesting things are happening:

1) Every test runs even though I configure for only one test to run as you will 
see below.
2) All my tests that extend AbstractTestNGSpringContextTests are having 
problems with loading the application context. Sounds like some classloader 
stuff going on with Maven interacting with Spring and RESTEasy.

Again, everything works perfectly with Maven 2.2.0.

Here is the configuration again:

org.apache.maven.plugins
maven-failsafe-plugin
2.7.1

true
false

**/CategoriesServiceDelegateIT.java

integration-test

integration-test

verify

verify

Thanks.

-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Friday, January 14, 2011 4:30 PM
To: Maven Users List
Subject: Re: Classloader Problem with Maven 3.0.2

You're using an old and deprecated version of the failsafe plugin. I don't
think it works with Maven 3.
failsafe-m-p is now found at Apache Maven (not Codehaus Mojo):
http://maven.apache.org/plugins/maven-failsafe-plugin/

Upgrade and retry!

/Anders

On Fri, Jan 14, 2011 at 20:27, Neil Chaudhuri
wrote:

> I have upgraded from Maven 2.20 to 3.02, and I found many of my integration
> tests that used to pass are now failing because of a ClassCastException,
> which is an odd exception to find when no code has changed. I traced the
> issue to a classloader problem with Maven 3 that arises in another Java
> library (RESTEasy if you were wondering).
>
> Here is their code:
>
> try
>  {
> Object delegate =
> FactoryFinder.find(JAXRS_RUNTIME_DELEGATE_PROPERTY,
> JAXRS_DEFAULT_RUNTIME_DELEGATE);
> if (!(delegate instanceof RuntimeDelegate))
> {
>Class pClass = RuntimeDelegate.class;
>String classnameAsResource = pClass.getName().replace('.', '/')
> + ".class";
>ClassLoader loader = pClass.getClassLoader();
>if (loader == null)
>{
>   loader = ClassLoader.getSystemClassLoader();
>}
>URL targetTypeURL = loader.getResource(classnameAsResource);
>   throw new LinkageError("ClassCastException: attempting to cast" +
>
>  delegate.getClass().getClassLoader().getResource(classnameAsResource) +
>"to" + targetTypeURL.toString());
> }
> return (RuntimeDelegate) delegate;
>  }
>  catch (Exception ex)
>  {
> throw new RuntimeException(ex);
>  }
>
> And here is my pom configuration:
>
> 
>org.codehaus.mojo
>failsafe-maven-plugin
>2.4.3-alpha-1
>
>false
>false
>once
>
>
>  **/CategoriesServiceDelegateIT.java
>
>
>
>
>integration-test
>
>integration-test
>
>
>
>verify
>
>verify
>
>
>
> 
>
> When I set useSystemClassLoader to true, the ClassCastException goes away,
> but then nothing happens except for a hard exit. I see nothing in the logs
> or in failsafe-reports to tell me what happened.
>
> Any insight into why things work in Maven 2.20 but not in 3.02 is
> appreciated.
>
> Thanks.
>

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

RE: Classloader Problem with Maven 3.0.2

2011-01-14 Thread Neil Chaudhuri

I upgraded Failsafe to 2.7.1, and things definitely progressed, but two 
interesting things are happening:

1) Every test runs even though I configure for only one test to run as you will 
see below.
2) All my tests that extend AbstractTestNGSpringContextTests are having 
problems with loading the application context. Sounds like some classloader 
stuff going on with Maven interacting with Spring and RESTEasy.

Again, everything works perfectly with Maven 2.2.0.

Here is the configuration again:



org.apache.maven.plugins
maven-failsafe-plugin
2.7.1

true
false

**/CategoriesServiceDelegateIT.java




integration-test

integration-test



verify

verify








Thanks.




-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Friday, January 14, 2011 4:30 PM
To: Maven Users List
Subject: Re: Classloader Problem with Maven 3.0.2

You're using an old and deprecated version of the failsafe plugin. I don't
think it works with Maven 3.
failsafe-m-p is now found at Apache Maven (not Codehaus Mojo):
http://maven.apache.org/plugins/maven-failsafe-plugin/

Upgrade and retry!

/Anders

On Fri, Jan 14, 2011 at 20:27, Neil Chaudhuri
wrote:

> I have upgraded from Maven 2.20 to 3.02, and I found many of my integration
> tests that used to pass are now failing because of a ClassCastException,
> which is an odd exception to find when no code has changed. I traced the
> issue to a classloader problem with Maven 3 that arises in another Java
> library (RESTEasy if you were wondering).
>
> Here is their code:
>
> try
>  {
> Object delegate =
> FactoryFinder.find(JAXRS_RUNTIME_DELEGATE_PROPERTY,
> JAXRS_DEFAULT_RUNTIME_DELEGATE);
> if (!(delegate instanceof RuntimeDelegate))
> {
>Class pClass = RuntimeDelegate.class;
>String classnameAsResource = pClass.getName().replace('.', '/')
> + ".class";
>ClassLoader loader = pClass.getClassLoader();
>if (loader == null)
>{
>   loader = ClassLoader.getSystemClassLoader();
>}
>URL targetTypeURL = loader.getResource(classnameAsResource);
>   throw new LinkageError("ClassCastException: attempting to cast" +
>
>  delegate.getClass().getClassLoader().getResource(classnameAsResource) +
>"to" + targetTypeURL.toString());
> }
> return (RuntimeDelegate) delegate;
>  }
>  catch (Exception ex)
>  {
> throw new RuntimeException(ex);
>  }
>
> And here is my pom configuration:
>
> 
>org.codehaus.mojo
>failsafe-maven-plugin
>2.4.3-alpha-1
>
>false
>false
>once
>
>
>  **/CategoriesServiceDelegateIT.java
>
>
>
>
>integration-test
>
>integration-test
>
>
>
>verify
>
>verify
>
>
>
> 
>
> When I set useSystemClassLoader to true, the ClassCastException goes away,
> but then nothing happens except for a hard exit. I see nothing in the logs
> or in failsafe-reports to tell me what happened.
>
> Any insight into why things work in Maven 2.20 but not in 3.02 is
> appreciated.
>
> Thanks.
>

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

Re: Classloader Problem with Maven 3.0.2

2011-01-14 Thread Anders Hammar

You're using an old and deprecated version of the failsafe plugin. I don't
think it works with Maven 3.
failsafe-m-p is now found at Apache Maven (not Codehaus Mojo):
http://maven.apache.org/plugins/maven-failsafe-plugin/

Upgrade and retry!

/Anders

On Fri, Jan 14, 2011 at 20:27, Neil Chaudhuri
wrote:

> I have upgraded from Maven 2.20 to 3.02, and I found many of my integration
> tests that used to pass are now failing because of a ClassCastException,
> which is an odd exception to find when no code has changed. I traced the
> issue to a classloader problem with Maven 3 that arises in another Java
> library (RESTEasy if you were wondering).
>
> Here is their code:
>
> try
>  {
> Object delegate =
> FactoryFinder.find(JAXRS_RUNTIME_DELEGATE_PROPERTY,
> JAXRS_DEFAULT_RUNTIME_DELEGATE);
> if (!(delegate instanceof RuntimeDelegate))
> {
>Class pClass = RuntimeDelegate.class;
>String classnameAsResource = pClass.getName().replace('.', '/')
> + ".class";
>ClassLoader loader = pClass.getClassLoader();
>if (loader == null)
>{
>   loader = ClassLoader.getSystemClassLoader();
>}
>URL targetTypeURL = loader.getResource(classnameAsResource);
>   throw new LinkageError("ClassCastException: attempting to cast" +
>
>  delegate.getClass().getClassLoader().getResource(classnameAsResource) +
>"to" + targetTypeURL.toString());
> }
> return (RuntimeDelegate) delegate;
>  }
>  catch (Exception ex)
>  {
> throw new RuntimeException(ex);
>  }
>
> And here is my pom configuration:
>
> 
>org.codehaus.mojo
>failsafe-maven-plugin
>2.4.3-alpha-1
>
>false
>false
>once
>
>
>  **/CategoriesServiceDelegateIT.java
>
>
>
>
>integration-test
>
>integration-test
>
>
>
>verify
>
>verify
>
>
>
> 
>
> When I set useSystemClassLoader to true, the ClassCastException goes away,
> but then nothing happens except for a hard exit. I see nothing in the logs
> or in failsafe-reports to tell me what happened.
>
> Any insight into why things work in Maven 2.20 but not in 3.02 is
> appreciated.
>
> Thanks.
>

Re: Classloader Problem with Maven 3.0.2

2011-01-14 Thread Wayne Fay

> Any insight into why things work in Maven 2.20 but not in 3.02 is appreciated.

I don't believe that Maven 2.20 is a real version. Of course, 3.02
doesn't exist either, but I assume that is supposed to be 3.0.2. So
are you trying to upgrade from 2.2.0? Have you tried with 2.2.1?

Are you using the exact same  configuration (with the plugin
versions declared etc) and only changing the Maven version? Have you
tried mvn -X to get more information about what is going on during
your build, and compared the output from mvn2 and mvn3?

Wayne

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

Classloader Problem with Maven 3.0.2

2011-01-14 Thread Neil Chaudhuri

I have upgraded from Maven 2.20 to 3.02, and I found many of my integration 
tests that used to pass are now failing because of a ClassCastException, which 
is an odd exception to find when no code has changed. I traced the issue to a 
classloader problem with Maven 3 that arises in another Java library (RESTEasy 
if you were wondering).

Here is their code:

try
  {
 Object delegate =
 FactoryFinder.find(JAXRS_RUNTIME_DELEGATE_PROPERTY,
 JAXRS_DEFAULT_RUNTIME_DELEGATE);
 if (!(delegate instanceof RuntimeDelegate))
 {
Class pClass = RuntimeDelegate.class;
String classnameAsResource = pClass.getName().replace('.', '/') + 
".class";
ClassLoader loader = pClass.getClassLoader();
if (loader == null)
{
   loader = ClassLoader.getSystemClassLoader();
}
URL targetTypeURL = loader.getResource(classnameAsResource);
   throw new LinkageError("ClassCastException: attempting to cast" +

delegate.getClass().getClassLoader().getResource(classnameAsResource) +
"to" + targetTypeURL.toString());
 }
 return (RuntimeDelegate) delegate;
  }
  catch (Exception ex)
  {
 throw new RuntimeException(ex);
  }

And here is my pom configuration:


org.codehaus.mojo
failsafe-maven-plugin
2.4.3-alpha-1

false
false
once

**/CategoriesServiceDelegateIT.java




integration-test

integration-test



verify

verify





When I set useSystemClassLoader to true, the ClassCastException goes away, but 
then nothing happens except for a hard exit. I see nothing in the logs or in 
failsafe-reports to tell me what happened.

Any insight into why things work in Maven 2.20 but not in 3.02 is appreciated.

Thanks.

Re: use of plugin and pluginmanagement

2011-01-14 Thread amaresh mourya

thanks,

Re: plugin-testing

2011-01-14 Thread oliver

Hi,

the documentation of the maven-invoker-plugin is very basic but I think I got 
it now. But there is one problem left: how can I test the generation of 
archetypes ('mvn archetype:generate ...'). Any ideas?

regards,
Oliver

Am 13.01.2011 um 08:31 schrieb Stephen Connolly:

> maven-invoker-plugin its usually better for plugin testing. verifier is for
> writing plugin tests from eg junit. invoker works differently
> 
> - Stephen
> 
> ---
> Sent from my Android phone, so random spelling mistakes, random nonsense
> words and other nonsense are a direct result of using swype to type on the
> screen
> On 12 Jan 2011 21:58, "oliver"  wrote:

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

Re: use of plugin and pluginmanagement

2011-01-14 Thread Wayne Fay

> What extra things  provides than using only .

PluginManagement does ONE THING ONLY (essentially).
It provides a central location for all of your plugin versioning and
configuration.
THAT'S IT.

You still need to declare the  in the  section of your
various poms (children or parents) where you actually want to USE any
of those plugins in your build.

> POM, why is that ? Because the maven
> documentationsays
> you need to add plugin entry in your child POM to use that plugin
> (specified in parent POM's pluginManagement section,). I thought I will add
> that plugin in child pom only if I want to change version.

Then you thought wrong.

> CASE2: if I donot use   and only use :
> ---> In this case also I can get everything I want as above. All child pom
> gets the plugins define in parent pom without adding any entry. OS what's
> the difference?

The plugins declared in the build section of your parent will be
inherited (and executed) in all of those children poms. In many cases,
you might only want a given plugin to actually be used in a few of
those children, or even just one, and frequently not in the parent.

> So whats the point in going for , Is it only to Enforce to
> use same version of plugin and provide some clarity to whole application
> (parent and child) or it is for more than these?

That is essentially the only purpose for pluginManagement.

Wayne

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

Re: Using profiles to control execution of a maven build (conditional execution)

2011-01-14 Thread Dean Schulze

Could you elaborate some more on "using Maven correctly".  I've inherited a 
large maven build where things apparently done correctly and I don't want to 
add any more "incorrect" things to it.

--- On Thu, 1/13/11, Brian Topping  wrote:

From: Brian Topping 
Subject: Re: Using profiles to control execution of a maven build (conditional 
execution)
To: "Maven Users List" 
Date: Thursday, January 13, 2011, 3:19 PM

You might want to look in the list archives, there was a discussion in which I 
learned a lot from others on the list about the pros and cons of using profiles 
versus using separate (nearly identical) POMs.  My takeaway was that if one 
just jumps on profiles as the solution to every conditional situation, the 
build will grow a second head like a hydra in a bad horror flick and you'll 
really regret it.

The point is that profiles are often an expedient substitute for using Maven 
correctly.  They should always be considered "last resort" unless you know what 
you are getting yourself into.  

In my situation, I wanted to have a whole subtree of sources compiled if they 
were there, otherwise fetched from Nexus if needed.  Profiles work great for 
that, but I can see exactly where the hydra head fits on the beast now and 
don't intend on doing anything more with them unless absolutely necessary.

$0.02... 

On Jan 13, 2011, at 5:10 PM, Dean Schulze wrote:

> 
>                I need to modify the maven build for a large project 
> to skip certain steps during typical development builds (i.e. don't 
> build the *-source.jar files).  I've searched for "conditional 
> execution" for maven, but haven't found anything.
> 
> A dev profile sounds like the intuitive way to do this - but I don't 
> know how intuitive maven is.  The docs for profiles show how to set 
> different properties (i.e. database connection parameters) for different
> profiles.  I suppose I could set a property and then test if that 
> property is set in the maven-source-plugin - executions - execution tag.
> 
> Is this the right way to do conditional execution in maven?
> 
> What's the "right" way to do this in maven?
> 
> Thanks.
> 
> 
> 
> 

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

Re: use of plugin and pluginmanagement

2011-01-14 Thread amaresh mourya

Hi All,

Are the  and  behave in same way as
far as inheritance of   and  are concerned
respectively...

Because I found two contrast behavior from these two :

1. In case of all plugins specified in Parent POM get
inherited by child POM.
-> Example:  SUPER POM has a default set of plugins defined in
 section and I can run those on any POM without any
 entry defined to that POM. [all plugins get inherited]
2. In case of  only those dependencies will get
inherited that have been specified in child POM via {groupId, artifactId}
  -> Example : see this example over maven
documenetation

Help me understand the  !!!
Thanks,
Amaresh

Why is that difference in behavior?.
Thanks,
Amaresh

On Fri, Jan 14, 2011 at 4:51 PM, amaresh mourya wrote:

> Hi All,
>
> What extra things  provides than using only .
>
> CASE 1: if I have  a parent POM having few plugins in 
> section
> ---> so the children POMs will be using same version of plugin as specified
> in  and I do not even need to specify anything in my child
> POM, why is that ? Because the maven 
> documentationsays you 
> need to add plugin entry in your child POM to use that plugin
> (specified in parent POM's pluginManagement section,). I thought I will add
> that plugin in child pom only if I want to change version.
>
> Line from the page :
> *"If we added these specifications to the plugins element, they would
> apply only to a single POM. However, if we apply them under the
> pluginManagement* element, then this POM *and all inheriting POMs that add
> the maven-jar-plugin to the build will get the pre-process-classesexecution 
> as well. So rather than the above mess included in every child
> pom.xml, only the following is required:* "
>
> CASE2: if I donot use   and only use :
> ---> In this case also I can get everything I want as above. All child pom
> gets the plugins define in parent pom without adding any entry. OS what's
> the difference?
>
> So whats the point in going for , Is it only to Enforce
> to use same version of plugin and provide some clarity to whole application
> (parent and child) or it is for more than these?
>
> Please provide some test case to understand the difference..
> Thanks,
> Amaresh
>
>
>

Re: Problem with properties in Maven.

2011-01-14 Thread Alexander Vaysberg

yes, now i know it. But think this part must be on separate scope. Not
globally for alls, or?
If it's globally, than it any must write, which name of the properties
don't be used, or?
Am 14.01.2011 15:52, schrieb Siegmar Alber:
> Hi Alexander,
>
>
> 2011/1/14 Alexander Vaysberg :
>> I think, that I a one problem with properties in maven found. The
>> problem in pom with properties. If any know any other properties, which
>> worked same. Please say. Thank you.
>>
>> ...
>> 
>>  0.998
>>  4.8.2
>>  bla
>>  
>> ...
> with the "test" property you (accidentally?) set a parameter of the
> surefire-plugin[1]. Remove or rename your property and it should work
> :-)
>
> [1] http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#test
>


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

Re: Problem with properties in Maven.

2011-01-14 Thread Siegmar Alber

Hi Alexander,


2011/1/14 Alexander Vaysberg :
>
> I think, that I a one problem with properties in maven found. The
> problem in pom with properties. If any know any other properties, which
> worked same. Please say. Thank you.
>
> ...
> 
>      0.998
>      4.8.2
>      bla
>  
> ...

with the "test" property you (accidentally?) set a parameter of the
surefire-plugin[1]. Remove or rename your property and it should work
:-)

[1] http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#test

-- 
Have fun,
Siegmar

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

Re: Problem with properties in Maven.

2011-01-14 Thread Justin Edelson

How is this a problem? You're telling surefire to execute a test which doesn't 
exist and this causes a failure. This seems like the expected behavior.

On Jan 14, 2011, at 9:08 AM, Alexander Vaysberg  wrote:

> Hi,
> 
> I think, that I a one problem with properties in maven found. The
> problem in pom with properties. If any know any other properties, which
> worked same. Please say. Thank you.
> 
> The Problem can you reproduce with maven 2.2.1 and maven 3.0.1 in
> plug-in surefire. I create the property test:
> ...
> 
>  0.998
>  4.8.2
>  bla
>  
> ...
> and if I call mvn clean package test don't worked:
> on the version 2.2.1
> 
> [INFO]
> 
> [ERROR] BUILD FAILURE
> [INFO]
> 
> [INFO] No tests were executed!  (Set -DfailIfNoTests=false to ignore
> this error.)
> [INFO]
> 
> [INFO] For more information, run Maven with the -e switch
> 
> and 3.0.1
> 
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 1.087s
> [INFO] Finished at: Fri Jan 14 15:01:48 CET 2011
> [INFO] Final Memory: 6M/119M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test)
> on project test: No tests were executed!  (Set -DfailIfNoTests=false to
> ignore this error.) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
> 
> The Output for surefire :
> 
> #surefire
> #Fri Jan 14 15:00:57 CET 2011
> testClassesDirectory=/work/Projekts/test/test/target/test-classes
> classPathUrl.3=/work/repo/maven/mockit/jmockit/0.998/jmockit-0.998.jar
> classPathUrl.2=/work/repo/maven/junit/junit/4.8.2/junit-4.8.2.jar
> useManifestOnlyJar=true
> classPathUrl.1=/work/Projekts/test/test/target/classes
> reportsDirectory=/work/Projekts/test/test/target/surefire-reports
> classPathUrl.0=/work/Projekts/test/test/target/test-classes
> dirscanner.0=directoryScannerOptions
> providerConfiguration=org.apache.maven.surefire.junitcore.JUnitCoreProvider
> testSuiteDefinitionTestSourceDirectory=/work/Projekts/test/test/src/test/java
> surefireClassPathUrl.2=/work/repo/maven/org/apache/maven/surefire/surefire-api/2.7.1/surefire-api-2.7.1.jar
> requestedTest=bla
> surefireClassPathUrl.1=/work/repo/maven/org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar
> surefireClassPathUrl.0=/work/repo/maven/org/apache/maven/surefire/surefire-junit47/2.7.1/surefire-junit47-2.7.1.jar
> report.2=org.apache.maven.surefire.report.XMLReporter
> useSystemClassLoader=true
> report.1=org.apache.maven.surefire.report.BriefFileReporter
> report.0=org.apache.maven.surefire.report.ForkingConsoleReporter
> isTrimStackTrace=true
> dirscanner.0.params=/work/Projekts/test/test/target/test-classes|[**/bla.java]|[]
> enableAssertions=true
> failIfNoTests=true
> dirscanner.0.types=java.io.File|java.util.ArrayList|java.util.ArrayList
> includes0=**/bla.java
> parallel=false
> childDelegation=false
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 

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

Re: Problem with properties in Maven.

2011-01-14 Thread Wendy Smoak

On Fri, Jan 14, 2011 at 9:08 AM, Alexander Vaysberg  wrote:
> I think, that I a one problem with properties in maven found. The
> problem in pom with properties. If any know any other properties, which
> worked same. Please say. Thank you.
>
>  The Problem can you reproduce with maven 2.2.1 and maven 3.0.1 in
> plug-in surefire. I create the property test:
> ...
> 
>      0.998
>      4.8.2
>      bla
>  

Can you post more of the pom?  Where in the pom are the properties
defined, and how are you using the properties elsewhere in the pom?

If you can create a simple example project that demonstrates the
problem, that's probably the quickest way to get someone to take a
look.

-- 
Wendy

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

Problem with properties in Maven.

2011-01-14 Thread Alexander Vaysberg

Hi,

I think, that I a one problem with properties in maven found. The
problem in pom with properties. If any know any other properties, which
worked same. Please say. Thank you.

 The Problem can you reproduce with maven 2.2.1 and maven 3.0.1 in
plug-in surefire. I create the property test:
...

  0.998
  4.8.2
  bla
  
...
and if I call mvn clean package test don't worked:
on the version 2.2.1

[INFO]

[ERROR] BUILD FAILURE
[INFO]

[INFO] No tests were executed!  (Set -DfailIfNoTests=false to ignore
this error.)
[INFO]

[INFO] For more information, run Maven with the -e switch

and 3.0.1

[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time: 1.087s
[INFO] Finished at: Fri Jan 14 15:01:48 CET 2011
[INFO] Final Memory: 6M/119M
[INFO]

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.7.1:test (default-test)
on project test: No tests were executed!  (Set -DfailIfNoTests=false to
ignore this error.) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

The Output for surefire :

#surefire
#Fri Jan 14 15:00:57 CET 2011
testClassesDirectory=/work/Projekts/test/test/target/test-classes
classPathUrl.3=/work/repo/maven/mockit/jmockit/0.998/jmockit-0.998.jar
classPathUrl.2=/work/repo/maven/junit/junit/4.8.2/junit-4.8.2.jar
useManifestOnlyJar=true
classPathUrl.1=/work/Projekts/test/test/target/classes
reportsDirectory=/work/Projekts/test/test/target/surefire-reports
classPathUrl.0=/work/Projekts/test/test/target/test-classes
dirscanner.0=directoryScannerOptions
providerConfiguration=org.apache.maven.surefire.junitcore.JUnitCoreProvider
testSuiteDefinitionTestSourceDirectory=/work/Projekts/test/test/src/test/java
surefireClassPathUrl.2=/work/repo/maven/org/apache/maven/surefire/surefire-api/2.7.1/surefire-api-2.7.1.jar
requestedTest=bla
surefireClassPathUrl.1=/work/repo/maven/org/codehaus/plexus/plexus-utils/2.0.5/plexus-utils-2.0.5.jar
surefireClassPathUrl.0=/work/repo/maven/org/apache/maven/surefire/surefire-junit47/2.7.1/surefire-junit47-2.7.1.jar
report.2=org.apache.maven.surefire.report.XMLReporter
useSystemClassLoader=true
report.1=org.apache.maven.surefire.report.BriefFileReporter
report.0=org.apache.maven.surefire.report.ForkingConsoleReporter
isTrimStackTrace=true
dirscanner.0.params=/work/Projekts/test/test/target/test-classes|[**/bla.java]|[]
enableAssertions=true
failIfNoTests=true
dirscanner.0.types=java.io.File|java.util.ArrayList|java.util.ArrayList
includes0=**/bla.java
parallel=false
childDelegation=false



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

Maven 3: deploy-file error 500 on Nexus Repo

2011-01-14 Thread martib


I'm facing a problem under M3.0.2 or 3.0.1 with Nexus Repository
  mvn deploy:deploy-file ...

I've got a proxy-setting in my settings.xml.
Everything works fine with Maven 2.2.1 and proxy configuration without
change.
  
But with Maven 3, I'm getting this error:
(Environment: Maven 3.0.2, JDK 6, Nexus 1.8.0.1)

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy-file (default-cli)
on project _no
ne_maven_wlfulljar: Failed to deploy artifacts: Could not transfer artifact
com.bea.weblogic:core-descriptor-wl:jar:1.3.
2.0 from/to thirdparty-repo
(http://maven.x.ch:2501/nexus/content/repositories/thirdparty-repo):
Failed to tr
ansfer file:
http://maven.x.ch:2501/nexus/content/repositories/thirdparty-repo/com/bea/weblogic/core-descriptor-
wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar. Return code is: 500 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-deploy-plu
gin:2.5:deploy-file (default-cli) on project _none_maven_wlfulljar: Failed
to deploy artifacts: Could not transfer artif
act com.bea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to thirdparty-repo
(http://maven.x.ch:2501/nexus/conten
t/repositories/thirdparty-repo): Failed to transfer file:
http://maven.x.ch:2501/nexus/content/repositories/thir
dparty-repo/com/bea/weblogic/core-descriptor-wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar.
Return code is: 500
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
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:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:60)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:354)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to deploy
artifacts: Could not transfer artifact com.b
ea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to thirdparty-repo
(http://maven.x.ch:2501/nexus/content/reposit
ories/thirdparty-repo): Failed to transfer file:
http://maven.x.ch:2501/nexus/content/repositories/thirdparty-ie
u-web/com/bea/weblogic/core-descriptor-wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar.
Return code is: 500
at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:240)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.artifact.deployer.ArtifactDeploymentException:
Failed to deploy artifacts: Could not transfe
r artifact com.bea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to
thirdparty-repo (http://maven.x.ch:2501/nexus
/content/repositories/thirdparty-repo): Failed to transfer file:
http://maven.x.ch:2501/nexus/content/repositori
es/thirdparty-repo/com/bea/weblogic/core-descriptor-wl/1.3.2.0/core-descriptor-wl-1.3.2.0.jar.
Return code is: 500
at
org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:140)
at
org.apache.maven.plugin.deploy.DeployFileMojo.execute(DeployFileMojo.java:236)
... 21 more
Caused by: org.sonatype.aether.deployment.DeploymentException: Failed to
deploy artifacts: Could not transfer artifact c
om.bea.weblogic:core-descriptor-wl:jar:1.3.2.0 from/to thirdparty-repo
(http://maven.x.ch:2501/nexus/content/rep
ositories/thirdparty-repo): Failed to transfer file:
http://maven.x.ch:2501/nexus/content/repositories/thirdpart

Re: Cobertura and Surefire

2011-01-14 Thread Stefan Schulze

Jeff Jensen wrote:
> > Sounds nice, but this doesn't meet my requirement, that the 
> > tests with coverage-checks (and only one time, not twice)
> > should run, when the developers do "mvn test".
> There is no acceptable solution to this "requirement".  Many 
> of us "would like" to not run them twice, and in actuality 
> running them twice is not a problem for things like site gen.

Thank you for this information, that it's currently simply not possible.

I think that's a shortcoming of cobertura-maven-plugin. It should be possible 
to overwrite the "default" surefire-configuration within the 
cobertura-configuration.
But for now I have to look for another way (thank you and the others for the 
suggestions)

> > we unfortunately don't use a
> > regular CI-server but a bunch of shellscripts and cron-jobs. 
> > So it's not as trivial as with Hudson (Jenkins?) to use this 
> > kind of build-pipeline.
> Looks like it is time to invest a couple of days and set it 
> up!  Your work life will be easier and maintenance cheaper.

I completely aggree with you and I'd love to replace the scripts by a neat 
Hudson-installation. But the only way to do this (or the only way I can 
imagine) is to create a buildjob which simply calls our current 
master-buildscript. But I don't think I improved anything by doing this.
We can't use the most of hudson out of the box. Even the updating of the 
working-copy is not trivial: not only that we use CM Synergy (little support 
for it in Hudson and no public Java-API), but we need a combination of CM 
Synergy and Change Synergy to calculate the tasks to update.
I would really appreciate to migrate the build of the last 100 modules to Maven 
without the need of specialized builds for each target-stage, using a 
"mainstream" SCM-tool and so on... Unfortunately I think the client wouldn't 
pay for this work (not to forget the QA of the whole application).
But I think, I go off on a tangent.
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

Re: tomcat-m-p war dependency

2011-01-14 Thread Ryan Connolly

So it would appear that project war dependencies DO get deployed using
addContextWarDependencies property.  However, the war dependency must have
tomcat declared.  Not only was I unable to find any
documentation on this feature but as you can guess, m3 issues a clear
warning about the use of this unofficial scope.  I've created a JIRA for
this warning as I am guessing m3.1 will disallow this.  This will meet our
needs for the time being so I thought I would post this in case others
desire the same functionality but did not know to use tomcat scope.

http://jira.codehaus.org/browse/MTOMCAT-75
On Jan 13, 2011 3:04 PM, "Ryan Connolly"  wrote:
> Olivier,
> Not sure if you are being alerted of comments on the JIRA or not but in
> case you are not I've commented in more detail there. Thanks for taking a
> look!
> -Ryan
> On Jan 13, 2011 3:33 AM, "Olivier Lamy"  wrote:
>> Hello,
>> I have added a comment in the jira issue.
>> It sounds more reasonnable to have a new mojo for this with a more
>> simple syntax which could executed from the cli.
>>
>> Feel free to add an other comment.
>>
>>
>> Thanks,
>> --
>> Olivier Lamy
>> http://twitter.com/olamy
>> http://www.linkedin.com/in/olamy
>>
>> 2011/1/13 Ryan Connolly :
>>> Ok, my patch has been submitted:
> http://jira.codehaus.org/browse/MTOMCAT-74
>>>
>>> Please do take a peek at it. It would be great to see this in 1.2 if at
> all
>>> possible!
>>>
>>> -Ryan
>>>
>>>
>>> On Tue, Jan 11, 2011 at 5:27 PM, Olivier Lamy  wrote:
>>>
 Patchs are always welcome :-)

 2011/1/11 Ryan Connolly :
 > Thanks for the reply, Olivier. I'll give your suggestion a try.
> Would
 it
 > be worth my time trying to create a patch for this feature or would
 rather
 > just a feature request in JIRA?
 >
 > Thanks again.
 > -Ryan
 > On Jan 11, 2011 5:09 PM, "Olivier Lamy"  wrote:
 >> Hello,
 >> It's not supported currently (btw it's a good idea).
 >> You can use copy goal [1] from dependency plugin to get your
artifact
 >> and use deploy-only mojo from t-m-p
 >>
 >>
 >> [1]
 >

>
http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html
 >>
 >> 2011/1/11 Ryan Connolly :
 >>> Hi:
 >>> Does anyone happen to know whether it is possible to configure
 >>> tomcat:run to deploy a defined war dependency as well as run the
 current
 >>> project as a dynamic web app in the embedded container? I've tried
 > setting
 >>> the true
 >>> configuration option and have declared a war dependency in the
 tomcat-m-p
 >>> but the dependency does not appear to deploy to the embedded
> container.
 > Has
 >>> anyone else tried a similar configuration? Any advice would be
 > appreciated.
 >>> An example of what I thought might work follows:
 >>>
 >>> 
 >>> org.codehaus.mojo
 >>> tomcat-maven-plugin
 >>> 1.1
 >>> 
 >>> true
 >>> 
 >>> 
 >>> 
 >>> com.mycompany
 >>> war-artifactid
 >>> 1.0
 >>> war
 >>> 
 >>> 
 >>> 
 >>>
 >>>
 >>> Thanks,
 >>> -Ryan
 >>>
 >>
 >>
 >>
 >> --
 >> Olivier Lamy
 >> http://twitter.com/olamy
 >> http://www.linkedin.com/in/olamy
 >>
 >>
-
 >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 >> For additional commands, e-mail: users-h...@maven.apache.org
 >>
 >



 --
 Olivier Lamy
 http://twitter.com/olamy
 http://www.linkedin.com/in/olamy

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


>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy
>> http://www.linkedin.com/in/olamy
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>

use of plugin and pluginmanagement

2011-01-14 Thread amaresh mourya

Hi All,

What extra things  provides than using only .

CASE 1: if I have  a parent POM having few plugins in 
section
---> so the children POMs will be using same version of plugin as specified
in  and I do not even need to specify anything in my child
POM, why is that ? Because the maven
documentationsays
you need to add plugin entry in your child POM to use that plugin
(specified in parent POM's pluginManagement section,). I thought I will add
that plugin in child pom only if I want to change version.

Line from the page :
*"If we added these specifications to the plugins element, they would apply
only to a single POM. However, if we apply them under the
pluginManagement*element, then this POM
*and all inheriting POMs that add the maven-jar-plugin to the build will get
the pre-process-classes execution as well. So rather than the above mess
included in every child pom.xml, only the following is required:* "

CASE2: if I donot use   and only use :
---> In this case also I can get everything I want as above. All child pom
gets the plugins define in parent pom without adding any entry. OS what's
the difference?

So whats the point in going for , Is it only to Enforce to
use same version of plugin and provide some clarity to whole application
(parent and child) or it is for more than these?

Please provide some test case to understand the difference..
Thanks,
Amaresh

Archetype Plugin does not automatically call the update-local-catalog goal

2011-01-14 Thread Thiébault Benoît

Hi everyone,

I am building new archetypes to normalize my software developments and I 
encounter what seems to be a bug.

In the documentation it is written that the update-local-catalog goal is bound 
"by default to the lifecycle phase: install".

However, when I build my archetype, Maven (2.2.1) does not execute the goal and 
I have to run it manually to add the archetype to the local catalog. Here is 
what Maven prints:
> mvn install
[INFO] Scanning for projects...
[INFO] 
[INFO] Building archetype for standard projects
[INFO]task-segment: [install]
[INFO] 
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 9 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 0 resource
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory: 
/Users/ben/Documents/workspace/com-artenum-archetype/target/surefire-reports

---
 T E S T S
---
There are no tests to run.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar {execution: default-jar}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing 
/Users/ben/Documents/workspace/com-artenum-archetype/target/com-artenum-archetype-1.0.0-SNAPSHOT.jar
 to 
/Users/ben/.m2/repository/com/artenum/com-artenum-archetype/1.0.0-SNAPSHOT/com-artenum-archetype-1.0.0-SNAPSHOT.jar
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 
[INFO] Total time: 7 seconds
[INFO] Finished at: Fri Jan 14 11:17:56 CET 2011
[INFO] Final Memory: 16M/81M
[INFO] 

The file is correctly install in the repository, but the catalog is not updated.
Is it me or is it a bug?

Here is my POM:

http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0






com.artenum
com-artenum-archetype
1.0.0-SNAPSHOT






Artenum archetype for standard projects

This archetype shall be used to create new standardized Artenum 
project. 

http://www.artenum.com

Artenum
http://www.artenum.com

2011




General Public License (GPL)

http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt














jar




UTF-8






org.apache.maven.archetype
archetype-packaging
2.0







maven-archetype-plugin
2.0








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

Re: antlr-3.1.3 depends on antlr-2.7.7.

2011-01-14 Thread Nicola Musatti

The antltr dependencies are correct as they are now, if you are using 
antlr 3.x you do need antlr 2.7.7 too.


Cheers,
Nicola Musatti

Hayarobi Park wrote:
The antlr-3.1.3 depends on antlr-runtime-3.1.3, which depends on 
stringtemplate-3.2, and stringtemplate depends on antlr-2.7.7; the 
dependency scope is all compile.


I got two versions of antlr, when I using 'mvn 
dependency:copy-dependencies'. I'm looking for a way to use only one 
antlr by using dependencyManagement or other methods. Could you help me?



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





Chi riceve il presente messaggio e' tenuto a verificare se lo stesso non gli
sia pervenuto per errore. In tal caso e' pregato di avvisare immediatamente
il mittente e, tenuto conto delle responsabilita' connesse all'indebito
utilizzo e/o divulgazione del messaggio e/o delle informazioni in esso
contenute, voglia cancellare l'originale e distruggere le varie copie o
stampe.

The receiver of this message is required to check if he/she has received it
erroneously. If so, the receiver is requested to immediately inform the
sender and - in consideration of the responsibilities arising from undue use
and/or disclosure of the message and/or the information contained therein -
destroy the original message and any copy or printout thereof. 



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

Re: antlr-3.1.3 depends on antlr-2.7.7.

2011-01-14 Thread Stephen Connolly

different packages in. the jars

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 14 Jan 2011 05:44, "Anders Hammar"  wrote:
>
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html#Dependency_Exclusions
>
> You would then exclude antlr-2.7.7 as you don't want it.
>
> I'm somewhat surprise of this problem though. I would expect that
> antlr-3.1.3 would have this exclusion in place allready, as it would
affect
> them too (antlr-3.1.3 shouldn't have a indirect dependency to
antlr-2.7.7).
>
> /Anders
>
> On Fri, Jan 14, 2011 at 05:40, Hayarobi Park 
wrote:
>
>> The antlr-3.1.3 depends on antlr-runtime-3.1.3, which depends on
>> stringtemplate-3.2, and stringtemplate depends on antlr-2.7.7; the
>> dependency scope is all compile.
>>
>> I got two versions of antlr, when I using 'mvn
>> dependency:copy-dependencies'. I'm looking for a way to use only one
antlr
>> by using dependencyManagement or other methods. Could you help me?
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>

Re: Classloader Problem with Maven 3.0.2

Re: Welcome Wayne Fay to the Maven PMC

Re: Welcome Wayne Fay to the Maven PMC

Re: Maven 3: deploy-file error 500 on Nexus Repo

Welcome Wayne Fay to the Maven PMC

RE: Classloader Problem with Maven 3.0.2

RE: Classloader Problem with Maven 3.0.2

Re: Classloader Problem with Maven 3.0.2

Re: Classloader Problem with Maven 3.0.2

Classloader Problem with Maven 3.0.2

Re: use of plugin and pluginmanagement

Re: plugin-testing

Re: use of plugin and pluginmanagement

Re: Using profiles to control execution of a maven build (conditional execution)

Re: use of plugin and pluginmanagement

Re: Problem with properties in Maven.

Re: Problem with properties in Maven.

Re: Problem with properties in Maven.

Re: Problem with properties in Maven.

Problem with properties in Maven.

Maven 3: deploy-file error 500 on Nexus Repo

Re: Cobertura and Surefire

Re: tomcat-m-p war dependency

use of plugin and pluginmanagement

Archetype Plugin does not automatically call the update-local-catalog goal

Re: antlr-3.1.3 depends on antlr-2.7.7.

Re: antlr-3.1.3 depends on antlr-2.7.7.

27 matches

Site Navigation

Mail list logo

Footer information