Re: How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
I think by using ${project.version}.
/Anders
On Wed, Oct 27, 2010 at 20:57, Marshall Schor m...@schor.com wrote:
We have a common project parent-pom, and a build-resources-bundle project
containing various build resources, bundled into a Jar artifact. One of
these
resources is used in configuring the maven remote-resources-plugin, for
instance.
We start with the configuration where both the parent-pom and
build-resources-bundle are at version 1-SNAPSHOT.
The parent-pom is set up as an aggregator pom, with one child: the
build-resources-bundle project.
Executing mvn release:prepare on the parent-pom causes the prepare phase to
go
and update the versions of these from 1-SNAPSHOT to 1 for the tag.
However,
this process does not notice that the remote-resource-plugin's
configuration in
the parent-pom is specifying the build-resources-bundle at version
1-SNAPSHOT -
so that version is *not* updated.
If a release:perform were to be done, it would build from the tag checkout,
and
configure the remote-resources-plugin to use the 1-SNAPSHOT version of the
build-resources-bundle; I want it to be using the 1 version of the
bundle.
To work around this, I could run the release:prepare, and then update
manually,
the tag, to update the reference from 1-SNAPSHOT to 1.
The other thing I could imagine doing is uncoupling these two artifacts,
and
releasing the build-resources-bundle separately. This would require that I
duplicate a bunch of things from the common project parent-pom, into the
build-resources-bundle, and do a separate release cycle, just for it, and
then
have the parent-pom depend on the released version.
What is the maven way for doing this kind of thing?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven SQL plugin
I think we can extend the configuration to support multiple filesets ( ie fileset[] ). -D On Wed, Oct 27, 2010 at 10:13 PM, Chris Odney chris.od...@gmail.com wrote: Yup, I would like to do that. However, I settled for an alternative for my project. If someone could help me with a starting point in the code(Am I asking for too much? ) I will take it from there. Thanks, Chris. On Wed, Oct 20, 2010 at 2:25 AM, Wayne Fay wayne...@gmail.com wrote: In this case, I cannot use the fileset as the ordering mechanism is alphabetical. srcFiles seems a good choice however I cannot specify wildcards :( Have you considered simply modifying the Maven SQL plugin to add the functionality you require, and then offering your changes back for inclusion in a future release of the plugin? Adding a feature like you're proposing should be relatively simple, I'd assume. Wayne - 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: How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
I thought of that as well, but if it is a parent pom, children will most
likely redefine ${project.version} to have their own.
Marshall, I think you can refine your scenario by doing the following :
- remove the configuration part from your parent pom
- release it together with your build-resources-bundle project
- create a new artifact that declares as parent your parent pom, and add the
configuration for build-resources-bundle (you can even use
${project.parent.version} to reference it)
- make your project artifacts inherit from this new pom.
This way, you avoid duplication of configuration.
2010/10/28 Anders Hammar and...@hammar.net
I think by using ${project.version}.
/Anders
On Wed, Oct 27, 2010 at 20:57, Marshall Schor m...@schor.com wrote:
We have a common project parent-pom, and a build-resources-bundle project
containing various build resources, bundled into a Jar artifact. One
of
these
resources is used in configuring the maven remote-resources-plugin, for
instance.
We start with the configuration where both the parent-pom and
build-resources-bundle are at version 1-SNAPSHOT.
The parent-pom is set up as an aggregator pom, with one child: the
build-resources-bundle project.
Executing mvn release:prepare on the parent-pom causes the prepare phase
to
go
and update the versions of these from 1-SNAPSHOT to 1 for the tag.
However,
this process does not notice that the remote-resource-plugin's
configuration in
the parent-pom is specifying the build-resources-bundle at version
1-SNAPSHOT -
so that version is *not* updated.
If a release:perform were to be done, it would build from the tag
checkout,
and
configure the remote-resources-plugin to use the 1-SNAPSHOT version of
the
build-resources-bundle; I want it to be using the 1 version of the
bundle.
To work around this, I could run the release:prepare, and then update
manually,
the tag, to update the reference from 1-SNAPSHOT to 1.
The other thing I could imagine doing is uncoupling these two artifacts,
and
releasing the build-resources-bundle separately. This would require that
I
duplicate a bunch of things from the common project parent-pom, into the
build-resources-bundle, and do a separate release cycle, just for it, and
then
have the parent-pom depend on the released version.
What is the maven way for doing this kind of thing?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Vincent
Re: How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
The subject suggests that the projects will be release together, hence very
likely have the same version.
/Anders
On Thu, Oct 28, 2010 at 08:29, Vincent Latombe vincent.lato...@gmail.comwrote:
I thought of that as well, but if it is a parent pom, children will most
likely redefine ${project.version} to have their own.
Marshall, I think you can refine your scenario by doing the following :
- remove the configuration part from your parent pom
- release it together with your build-resources-bundle project
- create a new artifact that declares as parent your parent pom, and add
the
configuration for build-resources-bundle (you can even use
${project.parent.version} to reference it)
- make your project artifacts inherit from this new pom.
This way, you avoid duplication of configuration.
2010/10/28 Anders Hammar and...@hammar.net
I think by using ${project.version}.
/Anders
On Wed, Oct 27, 2010 at 20:57, Marshall Schor m...@schor.com wrote:
We have a common project parent-pom, and a build-resources-bundle
project
containing various build resources, bundled into a Jar artifact. One
of
these
resources is used in configuring the maven remote-resources-plugin, for
instance.
We start with the configuration where both the parent-pom and
build-resources-bundle are at version 1-SNAPSHOT.
The parent-pom is set up as an aggregator pom, with one child: the
build-resources-bundle project.
Executing mvn release:prepare on the parent-pom causes the prepare
phase
to
go
and update the versions of these from 1-SNAPSHOT to 1 for the tag.
However,
this process does not notice that the remote-resource-plugin's
configuration in
the parent-pom is specifying the build-resources-bundle at version
1-SNAPSHOT -
so that version is *not* updated.
If a release:perform were to be done, it would build from the tag
checkout,
and
configure the remote-resources-plugin to use the 1-SNAPSHOT version of
the
build-resources-bundle; I want it to be using the 1 version of the
bundle.
To work around this, I could run the release:prepare, and then update
manually,
the tag, to update the reference from 1-SNAPSHOT to 1.
The other thing I could imagine doing is uncoupling these two
artifacts,
and
releasing the build-resources-bundle separately. This would require
that
I
duplicate a bunch of things from the common project parent-pom, into
the
build-resources-bundle, and do a separate release cycle, just for it,
and
then
have the parent-pom depend on the released version.
What is the maven way for doing this kind of thing?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Vincent
Re: using the CheckoutMojo in my own plugin
Hi there,
you may want to read through this thread:
http://www.mail-archive.com/users@maven.apache.org/msg113122.html
I have done the same thing, but was using the Maven API to resolve the
plugin rather than trying it via the container directly.
HTH
Andreas
Am 10/28/10 1:41 AM, schrieb Jared Prestwich:
I'm writting a plugin that checks the dependencies and seperates my company
dependencies out. That works fine but now I would like to run a checkout on
those.
I have the connectionUrl set in the poms. I just need to call checkout.
I have tried getting an object of CheckoutMojo type but it always comes back
as a Null.
I thought maybe to bag that and just do a CommandLine call but I like the
idea of a universal scm plugin.
This is the latest iteration:
CheckoutMojo co = (CheckoutMojo) lookupCheckoutMojo();
...
co.execute();
protected Mojo lookupCheckoutMojo()
{
PlexusContainer container = new DefaultPlexusContainer();
container.initialize();
container.start();
return (Mojo) container.lookup( Mojo.ROLE,
org.apache.maven.plugins:maven-scm-plugin:1.4:checkout);
}
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: using the CheckoutMojo in my own plugin
Hi,
Why not simply use scm apis ? (you can have a look at the checkout
mojo to understand how it works).
The mojo is simply a kind of wrapper around the scm apis (all the
stuff is done in the scm apis).
2010/10/28 Jared Prestwich jprestw...@accessdata.com:
I'm writting a plugin that checks the dependencies and seperates my company
dependencies out. That works fine but now I would like to run a checkout on
those.
I have the connectionUrl set in the poms. I just need to call checkout.
I have tried getting an object of CheckoutMojo type but it always comes back
as a Null.
I thought maybe to bag that and just do a CommandLine call but I like the
idea of a universal scm plugin.
This is the latest iteration:
CheckoutMojo co = (CheckoutMojo) lookupCheckoutMojo();
...
co.execute();
protected Mojo lookupCheckoutMojo()
{
PlexusContainer container = new DefaultPlexusContainer();
container.initialize();
container.start();
return (Mojo) container.lookup( Mojo.ROLE,
org.apache.maven.plugins:maven-scm-plugin:1.4:checkout);
}
--
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
jar-with-dependencies, order of entries
Hi, we're using the jar-with-dependencies descriptor to assemble our artifacts. Now when we're switching from 3.0-beta-1 to 3.0 of Maven we are experience a change of behavior of the assembly process. Before, the resources of the assembled project would be assembled before any other dependency of the project. After the switch to 3.0 of Maven, other dependencies will be assembled (unpacked) before the resources of the current project is added. Should it not be that the resources of the current project should be added first? This make things like log4j configurations to be the one from other projects/dependencies, as the assembly plugin will not add duplicate entries... example: project x and y, x depends on y x - src/main/resources/log4j.xml y - src/main/resources/log4j.xml assembly jar-with-dependencies on project x will contain log4j.xml from project y, this is not exactly what you would expect right? Version/result matrix: Maven version = maven-assembly-plugin version = result 3.0-beta-1 = 2.2-beta-5 = log4j from x 3.0 = 2.2-beta-5 = log4j from y 3.0-beta-1 = 2.2 = log4j from y 3.0 = 2.2 = log4j from y - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
The common project parent-pom and build-resources-bundle project, yes,
however the children (each project) won't have the same version.
2010/10/28 Anders Hammar and...@hammar.net
The subject suggests that the projects will be release together, hence very
likely have the same version.
/Anders
On Thu, Oct 28, 2010 at 08:29, Vincent Latombe vincent.lato...@gmail.com
wrote:
I thought of that as well, but if it is a parent pom, children will most
likely redefine ${project.version} to have their own.
Marshall, I think you can refine your scenario by doing the following :
- remove the configuration part from your parent pom
- release it together with your build-resources-bundle project
- create a new artifact that declares as parent your parent pom, and add
the
configuration for build-resources-bundle (you can even use
${project.parent.version} to reference it)
- make your project artifacts inherit from this new pom.
This way, you avoid duplication of configuration.
2010/10/28 Anders Hammar and...@hammar.net
I think by using ${project.version}.
/Anders
On Wed, Oct 27, 2010 at 20:57, Marshall Schor m...@schor.com wrote:
We have a common project parent-pom, and a build-resources-bundle
project
containing various build resources, bundled into a Jar artifact.
One
of
these
resources is used in configuring the maven remote-resources-plugin,
for
instance.
We start with the configuration where both the parent-pom and
build-resources-bundle are at version 1-SNAPSHOT.
The parent-pom is set up as an aggregator pom, with one child: the
build-resources-bundle project.
Executing mvn release:prepare on the parent-pom causes the prepare
phase
to
go
and update the versions of these from 1-SNAPSHOT to 1 for the
tag.
However,
this process does not notice that the remote-resource-plugin's
configuration in
the parent-pom is specifying the build-resources-bundle at version
1-SNAPSHOT -
so that version is *not* updated.
If a release:perform were to be done, it would build from the tag
checkout,
and
configure the remote-resources-plugin to use the 1-SNAPSHOT version
of
the
build-resources-bundle; I want it to be using the 1 version of the
bundle.
To work around this, I could run the release:prepare, and then update
manually,
the tag, to update the reference from 1-SNAPSHOT to 1.
The other thing I could imagine doing is uncoupling these two
artifacts,
and
releasing the build-resources-bundle separately. This would require
that
I
duplicate a bunch of things from the common project parent-pom, into
the
build-resources-bundle, and do a separate release cycle, just for it,
and
then
have the parent-pom depend on the released version.
What is the maven way for doing this kind of thing?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Vincent
--
Vincent
Re: maven-eclipse-plugin Does not resolve workspace project name
So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Fay wayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
M3 fails to download parent pom
Is this a known issue? A new company parent pom release was not downloaded by maven 3, and hence failed to do anything with my project. Running maven 2.2.1 on the project successfully downloaded the parent pom. Running maven 3 gave the following output: $ mvn -X help:effective-pom Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200) Java version: 1.6.0_20 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.6.4 arch: x86_64 Family: mac [INFO] Error stacktraces are turned on. [DEBUG] Reading user settings from /Users/dashorst/.m2/settings.xml [DEBUG] Reading global settings from /usr/share/maven/conf/settings.xml [DEBUG] Using local repository at /Users/dashorst/.m2/repository [INFO] Scanning for projects... [ERROR] The build could not read 1 project - [Help 1] org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM: Could not find artifact nl.topicus.onderwijs:onderwijs-project-parent:pom:1.3 and 'parent.relativePath' points at wrong local POM @ line 4, column 10 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:325) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:607) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:556) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:228) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) 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:352) [ERROR] [ERROR] The project nl.topicus.eduarte:eduarte:2.06-SNAPSHOT (/Users/dashorst/Workspaces/eduarte/eduarte/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact nl.topicus.onderwijs:onderwijs-project-parent:pom:1.3 and 'parent.relativePath' points at wrong local POM @ line 4, column 10 - [Help 2] org.apache.maven.model.resolution.UnresolvableModelException: Could not find artifact nl.topicus.onderwijs:onderwijs-project-parent:pom:1.3 at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:183) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:819) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:670) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:308) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:354) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:305) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:607) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:556) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:228) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) 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:352) Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact
Re: M3 fails to download parent pom
I had encounter that few days back. And what I did is the location of the parent folder contains the pom.xml into the relativePath just like parent groupIdnl.topicus.onderwijs/groupId artifactIdonderwijs-project-parent/artifactId version1.3/version relativePathlocation of your parent folder/relativePath /parent On Thu, Oct 28, 2010 at 5:22 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Is this a known issue? A new company parent pom release was not downloaded by maven 3, and hence failed to do anything with my project. Running maven 2.2.1 on the project successfully downloaded the parent pom. Running maven 3 gave the following output: $ mvn -X help:effective-pom Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200) Java version: 1.6.0_20 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.6.4 arch: x86_64 Family: mac [INFO] Error stacktraces are turned on. [DEBUG] Reading user settings from /Users/dashorst/.m2/settings.xml [DEBUG] Reading global settings from /usr/share/maven/conf/settings.xml [DEBUG] Using local repository at /Users/dashorst/.m2/repository [INFO] Scanning for projects... [ERROR] The build could not read 1 project - [Help 1] org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [FATAL] Non-resolvable parent POM: Could not find artifact nl.topicus.onderwijs:onderwijs-project-parent:pom:1.3 and 'parent.relativePath' points at wrong local POM @ line 4, column 10 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:325) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:607) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:556) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:228) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) 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:352) [ERROR] [ERROR] The project nl.topicus.eduarte:eduarte:2.06-SNAPSHOT (/Users/dashorst/Workspaces/eduarte/eduarte/pom.xml) has 1 error [ERROR] Non-resolvable parent POM: Could not find artifact nl.topicus.onderwijs:onderwijs-project-parent:pom:1.3 and 'parent.relativePath' points at wrong local POM @ line 4, column 10 - [Help 2] org.apache.maven.model.resolution.UnresolvableModelException: Could not find artifact nl.topicus.onderwijs:onderwijs-project-parent:pom:1.3 at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:183) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:819) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:670) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:308) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:354) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:305) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:607) at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:556) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:228) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
Emma codecoverage against maven dependent jars
Hi All, I am trying to get the code coverage for the maven dependent jars. I tried the below plugin, however it is able to provide code coverage only if the source files that are present in the project. It is unable to instrument the jars if the source files are in the form of jars, that are added as maven dependency. Could someone help me ? plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdemma-maven-plugin/artifactId version1.0-alpha-2/version inheritedtrue/inherited /plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdsurefire-report-maven-plugin/artifactId inheritedtrue/inherited /plugin /plugins Regards, Pradeep
Re: How to release 2 items together, with inter-dependent versions, some specified in configuration elements?
Thank you for your responses :-).
There are two ideas here:
1) have the configuration pick the right version, using
${project.parent.version}
2) refactor the parent into two parts, to avoid duplication.
1) is like the previous suggestion, but gets around the issue of having children
at different version levels. But 1) requires that you do 2), so that when you
build new sub-parent containing the reference to the build-resources-bundle, it
has now a parent at the proper version level to make that reference work.
This feels to me to be very clever, but perhaps brittle with respect to future
maintenance... but that could be fixed with some careful comments, I suppose.
1) also requires that all build parent-poms be at the same level, which I think
is fine, but is, again, somewhat brittle in the sense above.
I guess this brittleness can be avoided by not doing the 1) part, and instead,
hard-coding the version (maybe in just one place, using a property) in the
parent-pom with the configuration(s) referring to it.
-Marshall
On 10/28/2010 2:29 AM, Vincent Latombe wrote:
I thought of that as well, but if it is a parent pom, children will most
likely redefine ${project.version} to have their own.
Marshall, I think you can refine your scenario by doing the following :
- remove the configuration part from your parent pom
- release it together with your build-resources-bundle project
- create a new artifact that declares as parent your parent pom, and add the
configuration for build-resources-bundle (you can even use
${project.parent.version} to reference it)
- make your project artifacts inherit from this new pom.
This way, you avoid duplication of configuration.
2010/10/28 Anders Hammar and...@hammar.net
I think by using ${project.version}.
/Anders
On Wed, Oct 27, 2010 at 20:57, Marshall Schor m...@schor.com wrote:
We have a common project parent-pom, and a build-resources-bundle project
containing various build resources, bundled into a Jar artifact. One
of
these
resources is used in configuring the maven remote-resources-plugin, for
instance.
We start with the configuration where both the parent-pom and
build-resources-bundle are at version 1-SNAPSHOT.
The parent-pom is set up as an aggregator pom, with one child: the
build-resources-bundle project.
Executing mvn release:prepare on the parent-pom causes the prepare phase
to
go
and update the versions of these from 1-SNAPSHOT to 1 for the tag.
However,
this process does not notice that the remote-resource-plugin's
configuration in
the parent-pom is specifying the build-resources-bundle at version
1-SNAPSHOT -
so that version is *not* updated.
If a release:perform were to be done, it would build from the tag
checkout,
and
configure the remote-resources-plugin to use the 1-SNAPSHOT version of
the
build-resources-bundle; I want it to be using the 1 version of the
bundle.
To work around this, I could run the release:prepare, and then update
manually,
the tag, to update the reference from 1-SNAPSHOT to 1.
The other thing I could imagine doing is uncoupling these two artifacts,
and
releasing the build-resources-bundle separately. This would require that
I
duplicate a bunch of things from the common project parent-pom, into the
build-resources-bundle, and do a separate release cycle, just for it, and
then
have the parent-pom depend on the released version.
What is the maven way for doing this kind of thing?
-Marshall Schor
-
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: maven-eclipse-plugin Does not resolve workspace project name
On 28/10/2010 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. I guess that you could take a copy and continue to maintain it. If you want to build a team to maintain it and share it, then you probably want to get the Maven group to cooperate. If you are the only user/developer, you are off to the races. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Ron Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Faywayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - 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
Error received while using instrumentationPaths
Hi All, I am receiving the below exception while using instrumentationPaths. Please advise. [INFO] Failed to configure plugin parameters for: org.codehaus.mojo:emma-maven-p lugin:1.0-alpha-2 (found static expression: 'C:/maven.repo/test/TestProject1/0.0.1-SNAPSHOT/*. jar' which may act as a default value). Cause: Cannot assign configuration entry 'instrumentationPaths' to 'class [Ljava .io.File;' from 'C:/maven.repo/test/TestProject1/0.0.1-SNAPSHOT/*.jar', which is of type class java.lang.String [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Thu Oct 28 18:30:24 IST 2010 [INFO] Final Memory: 15M/60M plugin groupIdorg.codehaus.mojo/groupId artifactIdemma-maven-plugin/artifactId version1.0-alpha-2/version inheritedtrue/inherited executions execution phaseprocess-classes/phase goals goalinstrument/goal /goals configuration instrumentationPathsC:/maven.repo/test/TestProject1/0.0.1-SNAPSHOT/*.jar/instrumentationPaths /configuration /execution /executions /plugin Regards, Pradeep
Re: maven-eclipse-plugin Does not resolve workspace project name
On Thu, Oct 28, 2010 at 2:54 PM, Ron Wheeler rwhee...@artifact-software.com wrote: It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. maven-eclipse-plugin works roughly 100% of the time here, but the m2eclipse plugin fails miserably with our maven project setup. And yes we tried the latest version. It always results in having to download and install vanilla eclipse. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. Meh. sounds like having a commercial stake in the project. I happen to like commandline mvn eclipse:eclipse without having to bloat my eclipse installation with unnecessary plugins—eclipse has trouble enough keeping up with the size of our projects. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Why is it older? Because you don't like command line tools? Happening to like command line tools make someone a dinosaur? Is the maven-eclipse-plugin old because it is not given any resources by sonatype which happens to maintain the m2eclipse plugin? Why bother with building a release for maven at all? Doesn't m2eclipse supplant that too? Martijn - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
Ron, m-e-p works better than M2ECLIPSE in many cases. Further, you have no proof here that I can see that the m-e-p is dead. To quote the plugin site: Last Published: 2010-02-25 | Version: 2.8 If someone posts a patch, I don't think there/s much evidence that it will be ignored. --benson On Thu, Oct 28, 2010 at 8:54 AM, Ron Wheeder rwhee...@artifact-software.com wrote: On 28/10/2010 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. I guess that you could take a copy and continue to maintain it. If you want to build a team to maintain it and share it, then you probably want to get the Maven group to cooperate. If you are the only user/developer, you are off to the races. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Ron Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Faywayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
We're not stopping you from taking it. Put it in Github and hack away. On Oct 28, 2010, at 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Fay wayne...@gmail.com wrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectName to override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Multiple time-stamped snapshot artifacts appearing in local repo
Hello, I recently discovered some confusing Maven behavior related to snapshots. I'm not sure whether this is expected behavior of Maven or Artifactory or a bug in one of them. Setup: - Maven 2.2.1 - Artifactory 2.2.5 - Artifactory snapshot repo is libs-snapshots-local. Maven Snapshot Version Behavior set to non-unique. My project consists of multiple components. componentA produces artifact core-0.83.2-SNAPSHOT.jar. componentB has a dependency on this snapshot artifact. Our CI server builds the project and deploys the snapshot artifacts to Artifactory. Since we want to ensure that we build against the latest snapshot artifacts, we add the '-U' command-line argument. The snapshot updatePolicy in the parent POM is set to 'never.' The behavior that concerns me is that snapshot artifacts with timestamps in the name are building up in the local repo on the CI machine. After a few build/deploy cycles, I see the snapshot artifacts named as I would expect, but also copies of those artifacts with SNAPSHOT replaced by a time stamp. For example, in the local repo right now I have: core-0.83.2-20101026.145529-2.jar core-0.83.2-20101026.163520-2.jar core-0.83.2-20101027.194945-2.jar --- latest core-0.83.2-SNAPSHOT.jar The latest jar and the SNAPSHOT jar are identical. There are actually more artifacts than shown above and this pattern is repeated for each of them. Could someone explain to me why this is happening and whether there is something I can do about it? Thanks. -brian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
Wrong person. I was not the person claiming that patches were not being deployed. Ron On 28/10/2010 9:36 AM, Benson Margulies wrote: Ron, m-e-p works better than M2ECLIPSE in many cases. Further, you have no proof here that I can see that the m-e-p is dead. To quote the plugin site: Last Published: 2010-02-25 | Version: 2.8 If someone posts a patch, I don't think there/s much evidence that it will be ignored. --benson On Thu, Oct 28, 2010 at 8:54 AM, Ron Wheeder rwhee...@artifact-software.com wrote: On 28/10/2010 5:13 AM, Martijn Dashorst wrote: So how does one get ownership of the plugin? I've contributed 2 patches with an implied promise that they would be included when the failing ITs on Barrie's workspace were resolved. Unfortunately that is the last of it. I guess that you could take a copy and continue to maintain it. If you want to build a team to maintain it and share it, then you probably want to get the Maven group to cooperate. If you are the only user/developer, you are off to the races. Why the constant commercials for the m2eclipse plugin? Instead why not ask for some interested developer to take over the maven-eclipse-plugin? Isn't this an open source community? It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Ron Martijn On Wed, Oct 27, 2010 at 7:28 PM, Wayne Faywayne...@gmail.comwrote: When I run eclipse:eclipse the project name in the .project file will be the artifactId (by default) despite the eclipse project name being something different. Yes, this is how m-e-p works. The .project file is overwritten by m-e-p and so you will lose all settings that you set up in Eclipse unless you also set them up in your pom via configuration: http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html This causes a problem when eclipse tries to build new projects workspace because the eclipse workspace project is one thing and the .project's project is something completely different. This is not m-e-p's problem. Stop renaming your projects if you want to use m-e-p and use it to regenerate the .project files. Keep the name as the artifactId, or change the artifactId in the pom to meet your needs. How come the maven-eclipse-plugin will never resolve the workspace project name to the .project project name. Or even offer a flag like useEclipseProjectNametrue/useEclipseProjectNameto override the original functionality? In the last 180 days, there have been zero issues in MECLIPSE resolved. At the same time, 40 have been updated and 20 were created. http://jira.codehaus.org/browse/MECLIPSE For all intents, m-e-p is dead. If you require this functionality, feel free to hack the plugin to add it and donate your changes back to be included in a future release -- but bear in mind there may never be another release. The last release was Feb 23, 2010 and before that was June 13, 2009. I suggest upgrading to m2eclipse: http://m2eclipse.sonatype.org/ Wayne - 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 - 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: maven-eclipse-plugin Does not resolve workspace project name
m-e-p works better than M2ECLIPSE in many cases. Further, you have no proof here that I can see that the m-e-p is dead. To quote the plugin I am the one who said for all intents, m-e-p is dead based entirely on JIRA activity and releases, as well as the existence of newer (and largely perceived as superior) tooling that is now available if you are using Maven and Eclipse. If someone posts a patch, I don't think there/s much evidence that it will be ignored. I'm also the one who said to go ahead and hack it to add this functionality and submit a patch. You may also end up supporting your own internal release of this plugin indefinitely, so realize that right up front. So how does one get ownership of the plugin? I've contributed 2 This is open source so no one is stopping you from creating a fork. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with maven-war-plugin
Hi, I have a problem with maven-war-plugin version 2.1. Below, I paste build section fragment from my pom.xml: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration !-- http://maven.apache.org/plugins/maven-compiler-plugin/ -- source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1/version /plugin /plugins /build Unfotunetly, generated artifact (war) contains two web.xml. When I use maven-war-plugin version 2.0.1 all works fine (generated war archive contains one web.xml). How can I solve this problem. Cheers, Marcin
Re: maven-eclipse-plugin Does not resolve workspace project name
2010/10/28 Wayne Fay wayne...@gmail.com: So how does one get ownership of the plugin? I've contributed 2 This is open source so no one is stopping you from creating a fork. Sorry to jump in but, in the Apache Committers' FAQ I read: http://www.apache.org/dev/committers.html#committer-responsibilities snip Applying patches In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into ASF repositories. /snip If you don't want to apply patches to m.e.p, please deprecate it, move it to archive, and abandon it *explicitly*. Or, if you don't want it, you have the responsibility *at least* to discuss them. Otherwise, contributors and committers are simply wasting time. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Sonar 2.3 released
The Sonar Team is pleased to announce the release of Sonar 2.2. This version ships with several new features : it is now possible to activate several times the Checkstyle rule Illegal Regular Expression with different parameters and priority or the PMD rule XPath with different XPath expressions. This feature was a requirement to start working on a architecture rule engine (don't access the **.db.** packages from the **.client.** packages, don't use java.util.Vector, don't access **.web.** packages from **.dao.** packages, ...) backup and restore quality profiles ability to activate at once all the rules returned by a search new rules API ability to add static resources to plugins support for quality models ( http://en.wikipedia.org/wiki/ISO/IEC_9126 ISO 9126 for example) through a new meta-model and a new API new Findbugs rules To find out more on those features, you can explore them in screenshots [1]. On top of those features, this release contains more than 70 improvements and bug-fixes [2]. To enjoy the new version, you can download it straight away [3]. - The Sonar Team Links [1] Sonar 2.2 in screenshots : http://www.sonarsource.org/sonar-2-3-in-screenshots/ [2] Release notes : http://www.sonarsource.org/downloads/#2.3 [3] Download : http://sonar.codehaus.org/downloads -- View this message in context: http://maven.40175.n5.nabble.com/ANN-Sonar-2-3-released-tp3240711p3240711.html Sent from the Maven - Users mailing list archive at Nabble.com.
Re: maven-eclipse-plugin Does not resolve workspace project name
I agree, there are many plugins that Maven developers just don't look after and they should be ejected and taken out of the org.maven.plugins name space. Anything there people assume are maintained which simply is not the case. On Oct 28, 2010, at 10:58 AM, Antonio Petrelli wrote: 2010/10/28 Wayne Fay wayne...@gmail.com: So how does one get ownership of the plugin? I've contributed 2 This is open source so no one is stopping you from creating a fork. Sorry to jump in but, in the Apache Committers' FAQ I read: http://www.apache.org/dev/committers.html#committer-responsibilities snip Applying patches In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into ASF repositories. /snip If you don't want to apply patches to m.e.p, please deprecate it, move it to archive, and abandon it *explicitly*. Or, if you don't want it, you have the responsibility *at least* to discuss them. Otherwise, contributors and committers are simply wasting time. Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
Help! Mojo development Issue
I'm not sure if this is the right forum for this, but I thought I would try
here first.
I have a plugin that I am trying to develop that wants to resolve a set of
groupId/artifactId pairs to resolved artifacts in the MavenProject it is
executing from. I have annotated the dependent field in the following way:
/*
@required
@parameter default-value=${project}
*/
public MavenProject project;
When I try and run my unit test (extending from the AbstractMojoTestCase) I
get a NPE when I try and access the project class variable. When I look at
this in the debugger, I can see that the project field was never set; although
all other custom fields that have been set in the test pom are showing up
correctly.
Any ideas?
I'm also seeing this issue when I attempt to use the @component tag.
Thanks!
best wishes,
Andrew
Re: Problem with maven-war-plugin
2010/10/28 Marcin Trościańczyk mtros...@gmail.com: Unfotunetly, generated artifact (war) contains two web.xml. When I use maven-war-plugin version 2.0.1 all works fine (generated war archive contains one web.xml). How can I solve this problem. This is strange, do you see two WEB-INF/web.xml entries in the war file? If it is so, I think it's a bug and you can file an issue: http://jira.codehaus.org/browse/MWAR Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-eclipse-plugin Does not resolve workspace project name
On 28/10/2010 9:35 AM, Martijn Dashorst wrote: On Thu, Oct 28, 2010 at 2:54 PM, Ron Wheeler rwhee...@artifact-software.com wrote: It is hard to get enthusiastic about maintaining old software that has been replaced by better stuff that is free. maven-eclipse-plugin works roughly 100% of the time here, but the m2eclipse plugin fails miserably with our maven project setup. And yes we tried the latest version. It always results in having to download and install vanilla eclipse. Get Eclipse/STS and you have a much more current supported set of code and everything that you need to develop with Maven. Meh. sounds like having a commercial stake in the project. I happen to like commandline mvn eclipse:eclipse without having to bloat my eclipse installation with unnecessary plugins—eclipse has trouble enough keeping up with the size of our projects. No commercial interest. It is free and I love getting everything I need installed in one download. Just add Hibernate plug-in and I am set to go. We used vanilla Eclipse for a few years but every time we installed a new version we lost a day. Now we are done in1/2 an hour or less. I will not say that it is a small download or does not include stuff that I do not use. I love the Maven tools. You can also get training and commercial level support if you want it. Why would anyone want to invest in older technology? Why is it older? Because you don't like command line tools? Happening to like command line tools make someone a dinosaur? I am too old to be enamoured with command line tools. I first started editing with Teco (after abandoning punched cards in the 60s). I can still get around in vi. I like editing XML by hand but prefer to use the POM GUI editor. I like pointing and clicking and checking off some buttons to get Maven to do what I want. I guess that I regard liking command line tools as eccentric at most. I am old enough to be careful with the word dinosaur in a forum that caters to a younger high-tech crowd. :-) Is the maven-eclipse-plugin old because it is not given any resources by sonatype which happens to maintain the m2eclipse plugin? Why bother with building a release for maven at all? Doesn't m2eclipse supplant that too? Martijn - 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: maven-eclipse-plugin Does not resolve workspace project name
Yup, it's in ASF svn, and if the project isn't willing to own it, they should attic it. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Help! Mojo development Issue
IIRC, you need to declare the project field and provide an implementation class.
See, for example,
http://github.com/justinedelson/maven-hudson-plugin/blob/master/src/test/resources/unit/pom-with-local-ci.xml
That code worked at some point...
HTH,
Justin
On Oct 28, 2010, at 11:19 AM, Andrew Waterman wrote:
I'm not sure if this is the right forum for this, but I thought I would try
here first.
I have a plugin that I am trying to develop that wants to resolve a set of
groupId/artifactId pairs to resolved artifacts in the MavenProject it is
executing from. I have annotated the dependent field in the following way:
/*
@required
@parameter default-value=${project}
*/
public MavenProject project;
When I try and run my unit test (extending from the AbstractMojoTestCase) I
get a NPE when I try and access the project class variable. When I look at
this in the debugger, I can see that the project field was never set;
although all other custom fields that have been set in the test pom are
showing up correctly.
Any ideas?
I'm also seeing this issue when I attempt to use the @component tag.
Thanks!
best wishes,
Andrew
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with maven-war-plugin
It appears this was fixed in version 2.2 of m-w-p, try updating. http://jira.codehaus.org/browse/MWAR-235 Cheers, John 2010/10/28 Marcin Trościańczyk mtros...@gmail.com Hi, I have a problem with maven-war-plugin version 2.1. Below, I paste build section fragment from my pom.xml: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration !-- http://maven.apache.org/plugins/maven-compiler-plugin/ -- source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1/version /plugin /plugins /build Unfotunetly, generated artifact (war) contains two web.xml. When I use maven-war-plugin version 2.0.1 all works fine (generated war archive contains one web.xml). How can I solve this problem. Cheers, Marcin
Re: Including scope:provided dependencies in a shaded jar ?
Hi Jörg, Did you see this: http://maven.apache.org/plugins/maven-shade-plugin/shade- mojo.html#keepDependenciesWithProvidedScope I did, but it doesn't do what I need; my understanding is that it changes the scope of the compile-scoped deps to :provided in the shaded jar's pom. Antonio, Wayne, The multi-module path is the best. Why do you say that they share the same source? The shaded project must have a dependency on the original project, so it takes the compiled version, not the source. Yeah. Not something I like to do in a minor release though. The shaded artifact will be a pom-only project, which always seems a little silly. Oh well. Thanks ;) -g I have a project for which I'd like to create a shaded jar. It has a bunch of dependencies in scope:provided, because they really are, in the normal use-case of this artifact; it's meant to be deployed as a plugin in another app, so, for example, myapp-api really is provided. The project also has an assembly, which depends on these deps to be scope:provided (so they're not included in the assembly) If a webapp project is made and depends on this project, the scope:provided also helps avoiding duplicated dependencies in some cases. (I might have to double-check what I'm saying here ...) .. but yes, this project now also needs a standalone/executable jar; some of the provided dependencies are needed at runtime for this. As far as I can tell, the shade plugin currently does not propose any solution for this. Is there any way this could be considered for the plugin ? Or am I looking at it the wrong way ? Are there any alternatives ? I suppose I could split my project and have 2 modules, one simply being the standalone/shaded version of the other, but it seems overkill, since they're really the same source. I've also looked at the assembly plugin, but as far as I can tell it doesn't have a minify feature yet. (and we're talking 12mb vs 500k when minified) I reported this as http://jira.codehaus.org/browse/MSHADE-89 yesterday, before figuring it might be better discussed here beforehand. Thanks for any tip or hint, - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with maven-war-plugin
I don't think 2.2 is out yet, however he can try snapshots, as described in the issue. 2010/10/28 John Singleton john.te...@gmail.com It appears this was fixed in version 2.2 of m-w-p, try updating. http://jira.codehaus.org/browse/MWAR-235 Cheers, John 2010/10/28 Marcin Trościańczyk mtros...@gmail.com Hi, I have a problem with maven-war-plugin version 2.1. Below, I paste build section fragment from my pom.xml: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration !-- http://maven.apache.org/plugins/maven-compiler-plugin/ -- source1.6/source target1.6/target /configuration /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-war-plugin/artifactId version2.1/version /plugin /plugins /build Unfotunetly, generated artifact (war) contains two web.xml. When I use maven-war-plugin version 2.0.1 all works fine (generated war archive contains one web.xml). How can I solve this problem. Cheers, Marcin -- Vincent
Re: [ANN] Sonar 2.3 released
On Oct 28, 2010, at 5:04 PM, Olivier Gaudin wrote: The Sonar Team is pleased to announce the release of Sonar 2.2. This version ships with several new features : ^^ 2.3 release :-) it is now possible to activate several times the Checkstyle rule Illegal Regular Expression with different parameters and priority or the PMD rule XPath with different XPath expressions. This feature was a requirement to start working on a architecture rule engine (don't access the **.db.** packages from the **.client.** packages, don't use java.util.Vector, don't access **.web.** packages from **.dao.** packages, ...) backup and restore quality profiles ability to activate at once all the rules returned by a search new rules API ability to add static resources to plugins support for quality models ( http://en.wikipedia.org/wiki/ISO/IEC_9126 ISO 9126 for example) through a new meta-model and a new API new Findbugs rules To find out more on those features, you can explore them in screenshots [1]. On top of those features, this release contains more than 70 improvements and bug-fixes [2]. To enjoy the new version, you can download it straight away [3]. - The Sonar Team Links [1] Sonar 2.2 in screenshots : ^^ 2.2 :-) http://www.sonarsource.org/sonar-2-3-in-screenshots/ [2] Release notes : http://www.sonarsource.org/downloads/#2.3 [3] Download : http://sonar.codehaus.org/downloads Copy/Paste is dangerous :-) Arnaud - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: how to configure maven-test-plugin
hello all, i want to mock a final class, for that i need to use jdave to do so i need to launch your tests with the following vm parameter: -javaagent:/path/to/workspace/jdave-unfinalizer/target/jdave-unfinalizer-jar-name.jar i did a search and the maven-test-plugin can do this ( i dont understand why it is a dependency not a plugin !) how to configure this plugin in the pom.xml to modify properties lik maven.junit.jvmand maven.junit.jvmargs thanks in advance -- -- الله المعين منير الصبور -- -- الله المعين منير الصبور
Re: Help! Mojo development Issue
Thank you so very much for the reply Justin.
I'll go ahead and provide an implementation stub in the project tab to a class
that extends MavenProjectStub; following your example for Hudson. This setup
is just for the AbstractMojoTestCase, right? Presumably, normal poms don't
need this stub for the plugin to function, I hope.
Do you know of anymore documentation around that project? For example, my
jUnit tests are runnable, but do not execute as part of the build cycle, which
I'd love to know how to fix.
best wishes,
Andrew
On Oct 28, 2010, at 10:58 AM, Justin Edelson wrote:
IIRC, you need to declare the project field and provide an implementation
class.
See, for example,
http://github.com/justinedelson/maven-hudson-plugin/blob/master/src/test/resources/unit/pom-with-local-ci.xml
That code worked at some point...
HTH,
Justin
On Oct 28, 2010, at 11:19 AM, Andrew Waterman wrote:
I'm not sure if this is the right forum for this, but I thought I would try
here first.
I have a plugin that I am trying to develop that wants to resolve a set of
groupId/artifactId pairs to resolved artifacts in the MavenProject it is
executing from. I have annotated the dependent field in the following way:
/*
@required
@parameter default-value=${project}
*/
public MavenProject project;
When I try and run my unit test (extending from the AbstractMojoTestCase)
I get a NPE when I try and access the project class variable. When I look
at this in the debugger, I can see that the project field was never set;
although all other custom fields that have been set in the test pom are
showing up correctly.
Any ideas?
I'm also seeing this issue when I attempt to use the @component tag.
Thanks!
best wishes,
Andrew
-
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: Help! Mojo development Issue
All I can suggest is to look at the source of that maven-hudson-project. I've
written a number of Maven plugins, but I believe that's the case where I used
AbstractMojoTestCase the most.
It's been a while, but I seem to remember figuring out AbstractMojoTestCase by
looking at other plugins which used it, although I can't remember which ones.
That's generally what I do with Maven plugin development anyway - find a plugin
which does something comparable to what I'm trying to do.
Justin
On Oct 28, 2010, at 4:25 PM, Andrew Waterman wrote:
Thank you so very much for the reply Justin.
I'll go ahead and provide an implementation stub in the project tab to a
class that extends MavenProjectStub; following your example for Hudson.
This setup is just for the AbstractMojoTestCase, right? Presumably, normal
poms don't need this stub for the plugin to function, I hope.
Do you know of anymore documentation around that project? For example, my
jUnit tests are runnable, but do not execute as part of the build cycle,
which I'd love to know how to fix.
best wishes,
Andrew
On Oct 28, 2010, at 10:58 AM, Justin Edelson wrote:
IIRC, you need to declare the project field and provide an implementation
class.
See, for example,
http://github.com/justinedelson/maven-hudson-plugin/blob/master/src/test/resources/unit/pom-with-local-ci.xml
That code worked at some point...
HTH,
Justin
On Oct 28, 2010, at 11:19 AM, Andrew Waterman wrote:
I'm not sure if this is the right forum for this, but I thought I would try
here first.
I have a plugin that I am trying to develop that wants to resolve a set of
groupId/artifactId pairs to resolved artifacts in the MavenProject it is
executing from. I have annotated the dependent field in the following way:
/*
@required
@parameter default-value=${project}
*/
public MavenProject project;
When I try and run my unit test (extending from the AbstractMojoTestCase)
I get a NPE when I try and access the project class variable. When I
look at this in the debugger, I can see that the project field was never
set; although all other custom fields that have been set in the test pom
are showing up correctly.
Any ideas?
I'm also seeing this issue when I attempt to use the @component tag.
Thanks!
best wishes,
Andrew
-
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Guice Injector appears to be version-unaware
Folks originally i was using 2.5 version of maven-surefire-plugin as seen here groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.5/version this caused massive grief by DefaultPlexusContainer lookup which incorrectly parsed the roleHint so i backed all my dependencies of maven-surefire-plugin down to v 2.4.2 to rid myself of the guice injector anomaly here is the debug error listing: note that the org.codehaus.plexus.DefaultPlexusContainer roleHint is incorrectly assigned org.apache.maven.plugins:maven-surefire-plugin:2.5:test it should be org.apache.maven.plugins:maven-surefire-plugin:2.5 for the lookup to work [ERROR] 1 error [ERROR] role: org.apache.maven.plugin.Mojo [ERROR] roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test: Guice provision errors: [ERROR] [ERROR] 1) No implementation for org.apache.maven.artifact.resolver.ArtifactResolver was bound. [ERROR] while locating org.apache.maven.plugin.surefire.SurefirePlugin [ERROR] [ERROR] 1 error [ERROR] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test (default-test) on project maven-checkstyle-plugin: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to load the mojo 'test' (or one of its required components) from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5' at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) 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:314) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) 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:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to load the mojo 'test' (or one of its required components) from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5' at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: Unable to load the mojo 'test' (or one of its required components) from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5' at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:426) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:96) ... 20 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Guice provision errors: 1) Error injecting: org.apache.maven.plugin.surefire.SurefirePlugin at ClassRealm[pluginorg.apache.maven.plugins:maven-surefire-plugin:2.5, parent: ClassRealm[maven.api, parent: null]] while locating org.apache.maven.plugin.Mojo annotated with @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-surefire-plugin:2.5:test) 1 error role: org.apache.maven.plugin.Mojo roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:253) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:241) at
Re: Guice Injector appears to be version-unaware
On 28 October 2010 23:20, Martin Gainty mgai...@hotmail.com wrote: Folks originally i was using 2.5 version of maven-surefire-plugin as seen here groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.5/version this caused massive grief by DefaultPlexusContainer lookup which incorrectly parsed the roleHint so i backed all my dependencies of maven-surefire-plugin down to v 2.4.2 to rid myself of the guice injector anomaly here is the debug error listing: note that the org.codehaus.plexus.DefaultPlexusContainer roleHint is incorrectly assigned org.apache.maven.plugins:maven-surefire-plugin:2.5:test it should be org.apache.maven.plugins:maven-surefire-plugin:2.5 for the lookup to work [ERROR] 1 error [ERROR] role: org.apache.maven.plugin.Mojo [ERROR] roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test: Guice provision errors: [ERROR] [ERROR] 1) No implementation for org.apache.maven.artifact.resolver.ArtifactResolver was bound. [ERROR] while locating org.apache.maven.plugin.surefire.SurefirePlugin [ERROR] [ERROR] 1 error [ERROR] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test (default-test) on project maven-checkstyle-plugin: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to load the mojo 'test' (or one of its required components) from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5' at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:211) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) 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:314) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:151) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) 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:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.5:test failed: Unable to load the mojo 'test' (or one of its required components) from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5' at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:121) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195) ... 19 more Caused by: org.apache.maven.plugin.PluginContainerException: Unable to load the mojo 'test' (or one of its required components) from the plugin 'org.apache.maven.plugins:maven-surefire-plugin:2.5' at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:426) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:96) ... 20 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: com.google.inject.ProvisionException: Guice provision errors: 1) Error injecting: org.apache.maven.plugin.surefire.SurefirePlugin at ClassRealm[pluginorg.apache.maven.plugins:maven-surefire-plugin:2.5, parent: ClassRealm[maven.api, parent: null]] while locating org.apache.maven.plugin.Mojo annotated with @com.google.inject.name.Named(value=org.apache.maven.plugins:maven-surefire-plugin:2.5:test) 1 error role: org.apache.maven.plugin.Mojo roleHint: org.apache.maven.plugins:maven-surefire-plugin:2.5:test at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:253) at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:241) at
how to configure maven-test-plugin
hello all, i want to mock a final class, for that i need to use jdave to do so i need to launch your tests with the following vm parameter: -javaagent:/path/to/workspace/jdave-unfinalizer/target/jdave-unfinalizer-jar-name.jar i did a search and the maven-test-plugin can do this ( i dont understand why it is a dependency not a plugin !) how to configure this plugin in the pom.xml to modify properties lik maven.junit.jvmand maven.junit.jvmargs thanks in advance -- -- الله المعين منير الصبور
