Re: "conditional" parent POM?
In this case I actually want to add something, or to be precise, I want my
Jenkins job to add something on the fly with each build.
So I can build an open source project deploying to my organization's repository
manager.
The property approach Manfred pointed out earlier seems to be the most straight
forward.
-Max
On 03/10/2016 06:03 PM, Robert Patrick wrote:
The flatten plugin can remove sections of the POM that are not needed by
consumers of your software binaries, such as the repositories and
pluginRepositories sections. Isn't that what you are trying to achieve?
Robert Patrick
Sent from my iDevice
On Mar 10, 2016, at 4:29 PM, Manfred Moser wrote:
How so? The flatten plugin just flattens the poms right. If they point to an
internal repo manager .. its still wrong..
Manfred
Robert Patrick wrote on 2016-03-10 14:43:
Take a look at the flatten plugin...this is a much simpler way to solve that
problem!
Robert Patrick
Sent from my iDevice
On Mar 10, 2016, at 2:38 PM, Max Spring wrote:
Hi Curtis,
I don't want to have the URL of my in-house Maven repository manager out in
the open.
Regards,
-Max
On 03/10/2016 12:29 PM, Curtis Rueden wrote:
Hi Max,
Why do you need two different parents? What configuration is different
between your "wild" parent and your internal one?
Would it be sufficient to enclose the internal-specific configuration
(e.g., distributionManagement) in a profile? This technique is what my OSS
projects do [1].
Regards,
Curtis
[1]
https://github.com/scijava/pom-scijava/blob/pom-scijava-9.6.0/pom.xml#L1686-L1701
On Thu, Mar 10, 2016 at 2:20 PM, Max Spring wrote:
What's the best structure for a (multi-module) Maven project which should
build "in the wild" without any Maven repository manager and can easily
build within my organization where deployments should happen to my Maven
repository manager?
Ideally, I would have two different paren POMs for each situation. But
unfortunately, I can't use a Maven property to pass the correct value for
each situation, because the property expression in the parent POM reference
doesn't get interpolated, if I try something like
org.example
${root.pom}
1.0-SNAPSHOT
...
wild-parent
Added a minimalistic project which shows a crude approach to solve this by
patching the parent POM via sed:
https://github.com/m2spring/wild-inhouse-hybrid-example
-Max
-
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
-
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: "conditional" parent POM?
Hi Manfred,
you're right, "property-injection" is what I want.
I updated my example:
https://github.com/m2spring/wild-inhouse-hybrid-example/tree/property-approach
Thank you!
Regards,
-Max
On 03/10/2016 12:40 PM, Manfred Moser wrote:
You should not use different rool poms. The whole upstream parents for your
open source project should be open source as well.
And if you want to deploy to a different repo manager you can make the URLs
configurable as a property that you set in the pom and e.g. override in your
internal setup via settings.xml.
Manfred
Max Spring wrote on 2016-03-10 12:20:
What's the best structure for a (multi-module) Maven project which should build
"in the wild" without any Maven repository manager and can easily build within
my organization where deployments should happen to my Maven repository manager?
Ideally, I would have two different paren POMs for each situation. But
unfortunately, I can't use a Maven property to pass the correct value for each
situation, because the property expression in the parent POM reference doesn't
get interpolated, if I try something like
org.example
${root.pom}
1.0-SNAPSHOT
...
wild-parent
Added a minimalistic project which shows a crude approach to solve this by
patching the parent POM via sed:
https://github.com/m2spring/wild-inhouse-hybrid-example
-Max
-
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: "conditional" parent POM?
Hi Curtis,
I don't want to have the URL of my in-house Maven repository manager out in the
open.
Regards,
-Max
On 03/10/2016 12:29 PM, Curtis Rueden wrote:
Hi Max,
Why do you need two different parents? What configuration is different
between your "wild" parent and your internal one?
Would it be sufficient to enclose the internal-specific configuration
(e.g., distributionManagement) in a profile? This technique is what my OSS
projects do [1].
Regards,
Curtis
[1]
https://github.com/scijava/pom-scijava/blob/pom-scijava-9.6.0/pom.xml#L1686-L1701
On Thu, Mar 10, 2016 at 2:20 PM, Max Spring wrote:
What's the best structure for a (multi-module) Maven project which should
build "in the wild" without any Maven repository manager and can easily
build within my organization where deployments should happen to my Maven
repository manager?
Ideally, I would have two different paren POMs for each situation. But
unfortunately, I can't use a Maven property to pass the correct value for
each situation, because the property expression in the parent POM reference
doesn't get interpolated, if I try something like
org.example
${root.pom}
1.0-SNAPSHOT
...
wild-parent
Added a minimalistic project which shows a crude approach to solve this by
patching the parent POM via sed:
https://github.com/m2spring/wild-inhouse-hybrid-example
-Max
-
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
"conditional" parent POM?
What's the best structure for a (multi-module) Maven project which should build "in
the wild" without any Maven repository manager and can easily build within my
organization where deployments should happen to my Maven repository manager?
Ideally, I would have two different paren POMs for each situation. But
unfortunately, I can't use a Maven property to pass the correct value for each
situation, because the property expression in the parent POM reference doesn't
get interpolated, if I try something like
org.example
${root.pom}
1.0-SNAPSHOT
...
wild-parent
Added a minimalistic project which shows a crude approach to solve this by
patching the parent POM via sed:
https://github.com/m2spring/wild-inhouse-hybrid-example
-Max
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: alternative deploy strategy
Indeed, this sounds like a promising approach. Thanks! -Max On 08/28/2012 11:47 PM, Manfred Moser wrote: Hm.. if you are using Nexus Pro with the 2.1 release and the nexus staging maven plugin you get local creation of a staging bundle in the target folder and atomic upload to the repo .. which only happens after successful build including on multi module projects. I think this does what you want.. manfred PS: You might want to move this discussion to the Nexus mailing list.. On Tue, August 28, 2012 9:17 pm, Max Spring wrote: I do use Nexus for the group repositories. Using Nexus also locally defeats the purpose. The deploy to a file://... repo gives me the performance I'm looking for. Nexus Pro's staging feature would give me what I want, but I'd still have to transport via HTTP. -Max On 08/28/2012 09:05 PM, Manfred Moser wrote: On Tue, August 28, 2012 4:26 pm, Max Spring wrote: To speed up my large Maven build I'm thinking of using a "local-remote" repository sitting on the local file system. 1) build would start with a wiped local-remote repository 2) build's deploys into the local-remote repository 3) if build finished successfully, artifacts in the local-remote repository get deployed into the real remote group repository. (The benefits would be that nothing gets deployed until the build succeeds and the build result is available sooner.) Are there tools which would help with 3) ? I've looked into the Nexus Command Line Tools [1], but they don't do what I want. Alternatively I could write my own using the Maven API, I suppose. Why not just use a local deployment of Nexus? manfred - 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: alternative deploy strategy
I'm thinking of rsync'ing the "local-remote" repository to the machine running Nexus. Then I'd do the deploy via HTTP (localhost) which would avoid the wire. So, I'd preserve the auth. Keeping the copy of the "local-remote" repository around on the Nexus machine would improve the next build's rsync. -Max On 08/28/2012 11:52 PM, Anders Hammar wrote: If you want to bypass the Repo manager (normally what happens if you don't deploy through HTTP) you will also bypass authentication, authorization, and other good stuff that a repo manager helps you with. Don't do that! /Anders On Wed, Aug 29, 2012 at 6:17 AM, Max Spring wrote: I do use Nexus for the group repositories. Using Nexus also locally defeats the purpose. The deploy to a file://... repo gives me the performance I'm looking for. Nexus Pro's staging feature would give me what I want, but I'd still have to transport via HTTP. -Max On 08/28/2012 09:05 PM, Manfred Moser wrote: On Tue, August 28, 2012 4:26 pm, Max Spring wrote: To speed up my large Maven build I'm thinking of using a "local-remote" repository sitting on the local file system. 1) build would start with a wiped local-remote repository 2) build's deploys into the local-remote repository 3) if build finished successfully, artifacts in the local-remote repository get deployed into the real remote group repository. (The benefits would be that nothing gets deployed until the build succeeds and the build result is available sooner.) Are there tools which would help with 3) ? I've looked into the Nexus Command Line Tools [1], but they don't do what I want. Alternatively I could write my own using the Maven API, I suppose. Why not just use a local deployment of Nexus? manfred - 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: alternative deploy strategy
I do use Nexus for the group repositories. Using Nexus also locally defeats the purpose. The deploy to a file://... repo gives me the performance I'm looking for. Nexus Pro's staging feature would give me what I want, but I'd still have to transport via HTTP. -Max On 08/28/2012 09:05 PM, Manfred Moser wrote: On Tue, August 28, 2012 4:26 pm, Max Spring wrote: To speed up my large Maven build I'm thinking of using a "local-remote" repository sitting on the local file system. 1) build would start with a wiped local-remote repository 2) build's deploys into the local-remote repository 3) if build finished successfully, artifacts in the local-remote repository get deployed into the real remote group repository. (The benefits would be that nothing gets deployed until the build succeeds and the build result is available sooner.) Are there tools which would help with 3) ? I've looked into the Nexus Command Line Tools [1], but they don't do what I want. Alternatively I could write my own using the Maven API, I suppose. Why not just use a local deployment of Nexus? manfred - 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
alternative deploy strategy
To speed up my large Maven build I'm thinking of using a "local-remote" repository sitting on the local file system. 1) build would start with a wiped local-remote repository 2) build's deploys into the local-remote repository 3) if build finished successfully, artifacts in the local-remote repository get deployed into the real remote group repository. (The benefits would be that nothing gets deployed until the build succeeds and the build result is available sooner.) Are there tools which would help with 3) ? I've looked into the Nexus Command Line Tools [1], but they don't do what I want. Alternatively I could write my own using the Maven API, I suppose. -Max [1] https://docs.sonatype.com/display/SPRTNXOSS/Nexus+Command+Line+Tools - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
using per-branch group repo [Was: Is it possible to tie current git branch to project version?]
Has someone tried to approach this problem by using different group
repositories, one for each branch?
In particular when using a repository manager like Nexus, one could have for
each SCM branch a snapshot repo, a release repo and a repo group combining them
(plus other third party repos).
I could imagine a Maven plugin setting the repository URLs accordingly.
In a CI build one would have a private local repository, of course.
Developers would need to be careful, though, when working with multiple
branches on the same local repository. Or maybe the local repo would be
per-branch, too?
When pulling a new branch, the repositories on the repository manager could be
created automatically.
Thoughts?
-Max
On 03/06/2012 08:01 PM, Seth Call wrote:
Hi there,
I've seen indication when searching the internet that it isn't possible to
put variables in of a project (unless those variables are
hardcoded or provided at the command line), but I thought I'd
ask the list ...
Say there was a plugin that would invoke 'git branch' to determine the
current branch, and to then make that available to the project as a
variable; call it ${branch}. I'd like to use this variable then in the
version tag:
blah
blah
${branch}-SNAPSHOT
The reason I want to do this is that I'm realizing, for our internal-only
code projects, that a branch is always synonymous with a version of a
project, and ideally the act of being of switching branches would be all it
takes to switch your maven project's version.
Is this possible if I were to make a maven plugin?
Thanks!
Seth
--
View this message in context:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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: DefaultProjectBuilder ... mavenTools: null [Was: Re: Programmatically get maven properties]
Yes, having a projectBuilder in the Mojo did the trick.
Thank you!
The complete working example is down below.
-Max
package org.example;
import java.io.File;
import org.apache.maven.model.Model;
import org.apache.maven.model.building.ModelBuildingRequest;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.project.DefaultProjectBuildingRequest;
import org.apache.maven.project.MavenProject;
import org.apache.maven.project.ProjectBuilder;
import org.apache.maven.project.ProjectBuildingResult;
import org.sonatype.aether.RepositorySystemSession;
/**
* run with: mvn $groupId:$artifactId:$version:fetch-pom -DpomFile=$pomFile
*
* @goal fetch-pom
*/
public class FetchModelMojo extends AbstractMojo{
/**
* Current repository/network configuration of Maven.
* @parameter default-value="${repositorySystemSession}"
* @readonly
*/
private RepositorySystemSession repoSession;
/**
* @component
*/
private ProjectBuilder projectBuilder;
/**
* @parameter expression="${pomFile}" default-value=""
*/
private String pomFile;
public void execute() throws MojoExecutionException {
try {
DefaultProjectBuildingRequest req = new DefaultProjectBuildingRequest();
req.setRepositorySession(repoSession);
req.setValidationLevel(ModelBuildingRequest.VALIDATION_LEVEL_STRICT);
ProjectBuildingResult res = projectBuilder.build(new File(pomFile),req);
// do something with the project
MavenProject prj = res.getProject();
System.out.println("prj=" + prj);
Model model = prj.getModel();
System.out.println("id="+model.getId());
} catch (Exception e) {
throw new MojoExecutionException(e.getMessage(), e);
}
}
}
On 02/10/2012 01:19 PM, Olivier Lamy wrote:
Hello,
You must probably use:
/**
* @component
*/
private ProjectBuilder projectBuilder;
2012/2/10 Max Spring:
I'm running into the same "mavenTools: null" problem, but my code sits in a
Maven 3.0.3 mojo:
public class MyMojo extends AbstractMojo{
/** @parameter default-value="${repositorySystemSession}" */
private RepositorySystemSession repoSession;
public void execute() throws MojoExecutionException{
DefaultProjectBuilder builder = new DefaultProjectBuilder();
DefaultProjectBuildingRequest req = new
DefaultProjectBuildingRequest();
req.setRepositorySession(repoSession);
builder.build(new File("my-pom.xml"),req);
MavenProject prj = req.getProject();
Model model = prj.getModel();
}
}
It barfs with
Caused by: java.lang.IllegalArgumentException: mavenTools: null
at org.apache.maven.project.MavenProject.(MavenProject.java:249)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:128)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:102)
at MyMojo.execute(MyMojo.java:59)
This is because repositorySystem in DefaultProjectBuilder is null, i.e.
hasn't been injected:
@Requirement
private RepositorySystem repositorySystem;
How can I get the right repositorySystem injected?
Context:
I'm essentially trying to do the M2E "Import Project" use case, but
completely outside of Eclipse.
I want to populate a workspace using the SCM pointer given by a POM fetched
from the group repository.
Thanks!
-Max
On 10/18/2011 04:59 AM, Barrie Treloar wrote:
On Tue, Oct 18, 2011 at 10:02 PM, deusaquilus
wrote:
Here's what I'm doing:
File pom = new File("pom.xml");
DefaultProjectBuildingRequest request = new
DefaultProjectBuildingRequest();
DefaultProjectBuilder builder = new DefaultProjectBuilder();
String mavenHome = System.getenv("M2_HOME");
ArtifactRepository localRepository = new MavenArtifactRepository(
"local",
new File(mavenHome + "/repository").toURI().toURL().toString(),
new DefaultRepositoryLayout(),
new ArtifactRepositoryPolicy(),
new ArtifactRepositoryPolicy());
request.setLocalRepository(localRepository);
MavenProject project = builder.build(pom, request).getProject();
Properties properties = project.getProperties();
Trouble is it's giving me errors with "mavenTools: null"
I'd be surprised if that worked.
Maven makes heavy use of dependency injection via Plexus and chances
are you haven't set up some component that is being used.
What is your actual use case. I dont see why you would want to expose
Maven properties as a Java properties object...
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
DefaultProjectBuilder ... mavenTools: null [Was: Re: Programmatically get maven properties]
I'm running into the same "mavenTools: null" problem, but my code sits in a
Maven 3.0.3 mojo:
public class MyMojo extends AbstractMojo{
/** @parameter default-value="${repositorySystemSession}" */
private RepositorySystemSession repoSession;
public void execute() throws MojoExecutionException{
DefaultProjectBuilder builder = new DefaultProjectBuilder();
DefaultProjectBuildingRequest req = new DefaultProjectBuildingRequest();
req.setRepositorySession(repoSession);
builder.build(new File("my-pom.xml"),req);
MavenProject prj = req.getProject();
Model model = prj.getModel();
}
}
It barfs with
Caused by: java.lang.IllegalArgumentException: mavenTools: null
at org.apache.maven.project.MavenProject.(MavenProject.java:249)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:128)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:102)
at MyMojo.execute(MyMojo.java:59)
This is because repositorySystem in DefaultProjectBuilder is null, i.e. hasn't
been injected:
@Requirement
private RepositorySystem repositorySystem;
How can I get the right repositorySystem injected?
Context:
I'm essentially trying to do the M2E "Import Project" use case, but completely
outside of Eclipse.
I want to populate a workspace using the SCM pointer given by a POM fetched
from the group repository.
Thanks!
-Max
On 10/18/2011 04:59 AM, Barrie Treloar wrote:
On Tue, Oct 18, 2011 at 10:02 PM, deusaquilus wrote:
Here's what I'm doing:
File pom = new File("pom.xml");
DefaultProjectBuildingRequest request = new DefaultProjectBuildingRequest();
DefaultProjectBuilder builder = new DefaultProjectBuilder();
String mavenHome = System.getenv("M2_HOME");
ArtifactRepository localRepository = new MavenArtifactRepository(
"local",
new File(mavenHome + "/repository").toURI().toURL().toString(),
new DefaultRepositoryLayout(),
new ArtifactRepositoryPolicy(),
new ArtifactRepositoryPolicy());
request.setLocalRepository(localRepository);
MavenProject project = builder.build(pom, request).getProject();
Properties properties = project.getProperties();
Trouble is it's giving me errors with "mavenTools: null"
I'd be surprised if that worked.
Maven makes heavy use of dependency injection via Plexus and chances
are you haven't set up some component that is being used.
What is your actual use case. I dont see why you would want to expose
Maven properties as a Java properties object...
-
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
non-deterministic problem with Sonar plugin (Removing a detached instance org.sonar.api.batch.Event)
Using Maven 3.0.3 and sonar-maven3-plugin:2.12 I run into SONAR-2579 [1], but in an non-deterministic manner. In my multi-module project I have modules A, B, C, D, and I run mvn clean install mvn org.codehaus.sonar:sonar-maven3-plugin:2.12:sonar and it fails with the given error (see below [2]). Now, I comment-out modules one by one, until Sonar succeeds, and then add them back one by one. I see this strange pattern: 1: A B C D --> error 2: A B C --> error 3: A B --> error 4: A --> success 5: A B --> success 6: A B C --> error Why would 5 succeed where 3 failed and both having the same module set? Running Sonar against the same module set multiple times has never flipped from failure to success or vice versa. The failure is always reported at the top-level aggregator POM. What could be the reason for this strange behavior? Thanks! -Max [1] http://jira.codehaus.org/browse/SONAR-2579 [2] ... [INFO] arti-release.aggregator ... FAILURE [2:12.550s] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 2:52.072s [INFO] Finished at: Thu Jan 05 17:01:28 PST 2012 [INFO] Final Memory: 187M/400M [INFO] [ERROR] Failed to execute goal org.codehaus.sonar:sonar-maven3-plugin:2.12:sonar (default-cli) on project arti-release.aggregator: Execution default-cli of goal org.codehaus.sonar:sonar-maven3-plugin:2.12:sonar failed: Removing a detached instance org.sonar.api.batch.Event#14820 -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.sonar:sonar-maven3-plugin:2.12:sonar (default-cli) on project arti-release.aggregator: Execution default-cli of goal org.codehaus.sonar:sonar-maven3-plugin:2.12:sonar failed: Removing a detached instance org.sonar.api.batch.Event#14820 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) 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: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:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) 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:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.codehaus.sonar:sonar-maven3-plugin:2.12:sonar failed: Removing a detached instance org.sonar.api.batch.Event#14820 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: java.lang.IllegalArgumentException: Removing a detached instance org.sonar.api.batch.Event#14820 at org.hibernate.ejb.event.EJB3DeleteEventListener.performDetachedEntityDeletionCheck(EJB3DeleteEventListener.java:45) at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:108) at org.hibernate.event.def.DefaultDeleteEventListener.onDelete(DefaultDeleteEventListener.java:74) at org.hibernate.impl.SessionImpl.fireDelete(SessionImpl.java:794) at org.hibernate.impl.SessionImpl.delete(SessionImpl.java:772) at org.hibernate.ejb.AbstractEntityManagerImpl.remove(AbstractEntityManagerImpl.java:253) at org.sonar.jpa.session.JpaDatabaseSession.removeWithoutFlush(JpaDatabaseS
Re: maven-nar-plugin (http://duns.github.com/maven-nar-plugin)
Hi Karl Heinz, I'm trying to mavenize the QEMU (0.12.2) with the Maven NAR plugin, as an evaluation/demonstration of the NAR plugin's usefulness. Following the it0013-gnu-executable example, I'm running into a very basic problem: The QEMU's configure script doesn't like the '--disable-ccache' parameter. [DEBUG] RunCommand: ./configure [DEBUG] '--disable-ccache' [DEBUG] '--prefix=/nobackup/mspring/nar/qemu-0.12.2/target/nar/gnu/i386-Linux-g++/target' [DEBUG] in: /nobackup/mspring/nar/qemu-0.12.2/target/nar/gnu/i386-Linux-g++/src [INFO] ERROR: unknown option --disable-ccache This lead me to inspect the NAR plugin's sources. It didn't look that the 'configure' parameters are configurable at the moment. I'm unclear at the moment how to proceed best here. The other question I have in this context: What would be a good strategy for mavenizing subprojects of this codebase, so that they can be built individually from source, their binaries then deployed into the group repository, which in turn would be consumed by an overall build which no longer has to build the subprojects from source. I assume I should run the configure as part of a subproject's build. At the moment I feel if there were a few good examples, I might get some more ideas. -Max On 2/10/2010 11:49 PM, Karl Heinz Marbaise wrote: Hi to all, my first question: Is someone else using the above plugin ? I've started to examine the nar plugin, cause i have a large nunber of modules (ca. 150) which comprise of C++ code...I'm already using the rpm-maven-plugin which works very good...but under the hood i'm currently using cmake but i would like to get rid of cmake... ... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
parent pom reference generation [Was: Re: unit testing archetypes]
On 2/12/2010 5:20 PM, lukewpatterson wrote: ... Problem 2: Max Spring wrote: We have a parent POM design where the multi-module POM in the parent directory != parent POM. This is a capability/configurability problem with the archetype plugin, not with the testing methods, right? Yes, it is. I have not found anything yet to configure this. -Max - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: unit testing archetypes
On 2/12/2010 8:14 AM, Stephen Connolly wrote:
On 12 February 2010 14:34, lukewpatterson wrote:
Max Spring wrote:
One missing piece: If the instantiated archetype fails to build, I want
the integration test to fail.
So far a failure result is not getting propagated to the "outer" Maven
execution.
Hmm, I didn't know archetype would ignore failures, I pasted another
solution below.
Stephen Connolly-2 wrote:
in invoker.properties you will need to specify multiple executions, eg
invoker.goals.1=archetype:generate
invoker.goals.2=verify
the first one generates your project, the second builds it
I think that setup will be "off by one". It will run "verify" on the
folders that just have "test.properties" in them, not one more level deep
which contains the generated projects.
however, when you create from an archetype in a directory which
conatins a pom, the created module gets added as a new child module,
so that the build will build the parent and the newly created child
;-)
Yes, I learned about this behavior just this morning.
We have a parent POM design where the multi-module POM in the parent
directory != parent POM.
I'm now looking for a way to suppress this.
-Max
But a setup like this should work:
org.apache.maven.plugins
maven-invoker-plugin
generate-projects
install
run
${project.build.directory}/it/projects
org.apache.maven.plugins:maven-archetype-plugin:generate
*
${basedir}/src/it/projects
${project.artifactId}
${project.groupId}
local
${project.version}
false
verify-projects
run
verify
*/*/pom.xml
${project.build.directory}/it/projects
${project.build.directory}/it/repo
true
--
View this message in context:
http://old.nabble.com/unit-testing-archetypes-tp27544824p27564451.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
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: unit testing archetypes
This is exactly what I was looking for. Great!
One missing piece: If the instantiated archetype fails to build, I want
the integration test to fail.
So far a failure result is not getting propagated to the "outer" Maven
execution.
I assume this would need to be done as a postBuildHookScript?
Thank you!
-Max
On 2/11/2010 6:13 AM, Luke Patterson wrote:
On Wed, Feb 10, 2010 at 5:37 PM, Max Spring wrote:
What would be a good approach to test an archetype project?
...
A minimal test would be to "instantiate" the archetype and to build the
resulting project.
Here's some cut-and-paste that I'm using:
org.apache.maven.plugins
maven-invoker-plugin
integration-test
install
run
${project.build.directory}/it/projects
org.apache.maven.plugins:maven-archetype-plugin:generate
${project.build.directory}/it/repo
*
${basedir}/src/it/projects
${project.artifactId}
${project.groupId}
local
${project.version}
verify
false
true
then, your archetype will be run during integration-test phase for all
subdirectories of, a test.properties file will
contain the inputs to the archetype:generate goal, and the verify
phase will be run on each newly generated project
to add a new test, add another directory under
with a test.properties file
--
e.g.
src/it/projects/firsttest/test.properties with contents:
groupId=com.foo
artifactId=firsttest
version=1.0.0
package=com.foo.firsttest
that will create a "firsttest" directory under
${project.build.directory}/it/projects/firsttest with the stuff
generated by your archetype, and then run the verify phase on the
newly generated "com.foo.firsttest" project
--
-
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
unit testing archetypes
What would be a good approach to test an archetype project? I'd like to have the test attached as a "unit" test to the archetype project itself. A minimal test would be to "instantiate" the archetype and to build the resulting project. So far I have been playing with the exec-maven-plugin to invoke Maven recursively, in the install phase. I have to do this in the install phase in order for the archetype to be visible. It doesn't look very elegant to me. Is there a better way to do this? Thanks! -Max - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
