Re: maven-dependency-tree reactor resolution
maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-tree reactor resolution
Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.frwrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-dependency-tree reactor resolution
I don't really know: that's a precise feature that I didn't sudy dependency-tree is used in Maven plugins in contexts where components are already installed: so there is not much difference between reactor resolution and local repository resolution you're probably right: if reactor resolution is not done, it should be added, since that can be something generally expected from the component Regards, Hervé Le jeudi 20 mars 2014 17:30:38 William Ferguson a écrit : Herve, I didn't think I was asking for any extra flexibility out of dependency-tree that it didn't already give. Are you saying that it doesn't support resolution of projects in the current reactor? William On Thu, Mar 20, 2014 at 5:16 PM, Hervé BOUTEMY herve.bout...@free.frwrote: maven-dependency-tree offers a really simple API: that's its objective. The drawback is that it is not very flexible The value is that it hides Maven 2, Maven 3.0.x and Maven 3.1.x+ implementations, which are completely different (initial Maven 2 is made of listeners, Maven 3 uses Aether and Maven provider, with package changes from Maven 3.0 and 3.1) If you need more features, I think you'd better use Aether with Maven Provider: you can look both at maven-dependency-tree source to start and Aether examples to better understand Aether API, which is a lot more flexible- rich-complex Notice that your initial code will use latest Aether, then your plugin will require Maven 3.1.x minimum. If you want compatibility with Maven 3.0.x and 3.1.x+, you'll have to add some reflection magic which might add complexity (it was not so easy to do it in maven-dependency-tree) If you want Maven 2 compatibility, I would personnally not really think it is reasonably feasible Regards, Hervé Le jeudi 20 mars 2014 09:55:31 William Ferguson a écrit : Hi, I have a plugin that uses the maven-dependency-tree component to resolve project dependencies in a LifeCycleParticipant. (We need early access to deps because we need to modify the compile classpath). But I'm finding that with a clean repository, in a multi-module project with modules X and Y-depends-on-X that the DependencyGraphBuilder is throwing a DependencyGraphBuilderException when trying to resolve Y-depends-on-X. It says that it cannot find X. So it appears that the maven-dependency-tree is only using information from the repository and not the reactor. Is that expected? Is there anyway that I can get MDT to resolve from the reactor? Is there another approach that I should be taking to ensure that resolution looks in the reactor? NB I need to support both maven 3.0 and 3.1 which is why we are using MDT to provide a level of abstraction above the 2 differing Aether implementations. William - 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
contextRoot is set by default when specified in profile
Using the EAR plugin, if I specify the context root in the EAR's pom it works. But if I specify the contextRoot in a profile (in its parent pom), it sets the contextRoot by default (articleId). Am I doing something wrong? This is a piece of code for the EAR's pom: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.9/version configuration . modules webModule groupIdfuseim/groupId artifactIdxstreamline3-webservice/artifactId contextRoot/data/contextRoot bundleDir//bundleDir /webModule /modules version5/version /configuration /plugin And this is a piece of code in the EAR's parent pom: profile idjboss6/id properties jboss.version6/jboss.version packagingExcludes.data**/*.jar/packagingExcludes.data /properties build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.9/version configuration modules webModule groupIdfuseim/groupId artifactIdxstreamline3-webservice/artifactId contextRoot/data/contextRoot bundleDir//bundleDir /webModule /modules /configuration /plugin /plugins /build /profile Please help me. Thx -- View this message in context: http://maven.40175.n5.nabble.com/contextRoot-is-set-by-default-when-specified-in-profile-tp5788934.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
Re: contextRoot is set by default when specified in profile
Hi, poroto20 wrote: Using the EAR plugin, if I specify the context root in the EAR's pom it works. But if I specify the contextRoot in a profile (in its parent pom), it sets the contextRoot by default (articleId). Am I doing something wrong? And what do you do to activate the profile? This is a piece of code for the EAR's pom: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.9/version configuration . modules webModule groupIdfuseim/groupId artifactIdxstreamline3-webservice/artifactId contextRoot/data/contextRoot bundleDir//bundleDir /webModule /modules version5/version /configuration /plugin And this is a piece of code in the EAR's parent pom: profile idjboss6/id properties jboss.version6/jboss.version packagingExcludes.data**/*.jar/packagingExcludes.data /properties build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.9/version configuration modules webModule groupIdfuseim/groupId artifactIdxstreamline3-webservice/artifactId contextRoot/data/contextRoot bundleDir//bundleDir /webModule /modules /configuration /plugin /plugins /build /profile Please help me. Thx -- View this message in context: http://maven.40175.n5.nabble.com/contextRoot-is-set-by-default-when-specified-in-profile-tp5788934.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
The par packaging not working
The par packaging is not working. It is dependent on the org.apache.maven.plugins:maven-par-plugin, but this plugin does not exist. Is it deprecated? I am using the latest maven 3.2.1. How should I make the par package these days? I know this thing is relatively simple: just a collection of jars plus manifest with a few special entries. But I don't want to re-invent the wheel. -- View this message in context: http://maven.40175.n5.nabble.com/The-par-packaging-not-working-tp5788937.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
Re: contextRoot is set by default when specified in profile
I am running: mvn clean install -P jboss6 I think tt is using the correct profile because it is adding the web module to application.xml, only that it is using the wrong contextRoot -- View this message in context: http://maven.40175.n5.nabble.com/contextRoot-is-set-by-default-when-specified-in-profile-tp5788934p5788943.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
Re: contextRoot is set by default when specified in profile
It was my mistake. I wanted to exclude a web module by using a profile and it did not work. But I could fix it using combine.children=append. So I basically I added an extra web module in my profile using: plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ear-plugin/artifactId version2.9/version configuration modules combine.children=append webModule groupIdfuseim/groupId artifactIdxstreamline3-webservice/artifactId contextRoot/data/contextRoot bundleDir//bundleDir /webModule /modules /configuration /plugin /plugins Thank you for your help -- View this message in context: http://maven.40175.n5.nabble.com/contextRoot-is-set-by-default-when-specified-in-profile-tp5788934p5788947.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
Re: Problems with com.github.github:site-maven-plugin:0.9:site
I got a working setup for the release profile in the android maven plugin code. Check it out https://github.com/jayway/maven-android-plugin Benson Margulies wrote on 19.03.2014 19:20: Best ask them. This is a product of github, not the Apache Maven Project. On Wed, Mar 19, 2014 at 7:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I configured things according to https://github.com/github/maven-plugins But when I try to run 'mvn site' I get the following errors. Does the gh-pages branch need to be created manually first, or should the plug-in do that automatically? Or am I chasing some other type of error. Cheers, Eric [ERROR] Failed to execute goal com.github.github:site-maven-plugin:0.9:site (default) on project java-file-utilities: Error creating blob: Not Found (404) - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.github:site-maven-plugin:0.9:site (default) on project java-file-utilities: Error creating blob: Not Found (404) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216) 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:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating blob: Not Found (404) at com.github.maven.plugins.site.SiteMojo.createBlob(SiteMojo.java:289) at com.github.maven.plugins.site.SiteMojo.execute(SiteMojo.java:352) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: org.eclipse.egit.github.core.client.RequestException: Not Found (404) at org.eclipse.egit.github.core.client.GitHubClient.createException(GitHubClient.java:552) at org.eclipse.egit.github.core.client.GitHubClient.sendJson(GitHubClient.java:643) at org.eclipse.egit.github.core.client.GitHubClient.post(GitHubClient.java:757) at org.eclipse.egit.github.core.service.DataService.createBlob(DataService.java:115) at com.github.maven.plugins.site.SiteMojo.createBlob(SiteMojo.java:285) ... 22 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException D:\Users\Eric\Software\Project\Repositories\java-file-utilities - 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: Problems with com.github.github:site-maven-plugin:0.9:site
I copied what you had in your pom.xml, but I still get the same error. [ERROR] Failed to execute goal com.github.github:site-maven-plugin:0.9:site (default) on project java-file-utilities: Error creating blob: Not Found (404) - [Help 1] What does your settings.xml look like? Mine is: server idgithub/id usernamekolotyluk/username password/secret//password /server Is there some other configuration/setup that needs to be done. Does the gh-pages branch need to be created manually first, or should the plug-in do that automatically? Cheers, Eric On 3/20/2014 9:48 AM, Manfred Moser wrote: I got a working setup for the release profile in the android maven plugin code. Check it out https://github.com/jayway/maven-android-plugin Benson Margulies wrote on 19.03.2014 19:20: Best ask them. This is a product of github, not the Apache Maven Project. On Wed, Mar 19, 2014 at 7:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I configured things according to https://github.com/github/maven-plugins But when I try to run 'mvn site' I get the following errors. Does the gh-pages branch need to be created manually first, or should the plug-in do that automatically? Or am I chasing some other type of error. Cheers, Eric [ERROR] Failed to execute goal com.github.github:site-maven-plugin:0.9:site (default) on project java-file-utilities: Error creating blob: Not Found (404) - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.github.github:site-maven-plugin:0.9:site (default) on project java-file-utilities: Error creating blob: Not Found (404) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:216) 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:317) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214) at org.apache.maven.cli.MavenCli.main(MavenCli.java:158) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating blob: Not Found (404) at com.github.maven.plugins.site.SiteMojo.createBlob(SiteMojo.java:289) at com.github.maven.plugins.site.SiteMojo.execute(SiteMojo.java:352) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) ... 19 more Caused by: org.eclipse.egit.github.core.client.RequestException: Not Found (404) at org.eclipse.egit.github.core.client.GitHubClient.createException(GitHubClient.java:552) at org.eclipse.egit.github.core.client.GitHubClient.sendJson(GitHubClient.java:643) at org.eclipse.egit.github.core.client.GitHubClient.post(GitHubClient.java:757) at org.eclipse.egit.github.core.service.DataService.createBlob(DataService.java:115) at com.github.maven.plugins.site.SiteMojo.createBlob(SiteMojo.java:285) ... 22 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException D:\Users\Eric\Software\Project\Repositories\java-file-utilities - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Site Repository Property was: Open Source Best Practices with Maven - distributionManagement
So is there an equivalent to altReleaseDeploymentRepository and altSnapshotDeploymentRepository for the Site Deployment information also? Since all three are in the Distribution Management directive, I was hoping I could define this last one in the settings.xml also. Robert Kuropkat On 03/19/2014 05:15 PM, Mirko Friedenhagen wrote: Hello Eric, as outlined in https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html in your settings.xml you might define properties altReleaseDeploymentRepository and altSnapshotDeploymentRepository in a profile internal-repository which is activated by default while you do not define any repository at all in your pom. Now while developing you just invoke mvn deploy and everything should go to your local Nexus. When invoking mvn -P!internal-repository everything should go to central. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ snip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Forcing Integration Tests Before a Release
I am looking for some way to force my integration tests before a release, without explicitly using a profile. For example, plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like profiles profile idrun-it/id activation file missingtarget/failsafe-reports/missing /file /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build /profile /profiles But that will cause the integration tests to be run after every clean. Is there some way I can trigger the integration tests when doing a release mvn release:prepare without having to do mvn release:prepare -P run-it Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Forcing Integration Tests Before a Release
On 21 March 2014 06:02, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am looking for some way to force my integration tests before a release, without explicitly using a profile. [del] Is there some way I can trigger the integration tests when doing a release mvn release:prepare without having to do mvn release:prepare -P run-it Have a look at the apache parent pom chain. There is some activation stuff in there that gets run when you do a release - I can't recall how it does it. e.g. always generating source jars
Re: Site Repository Property was: Open Source Best Practices with Maven - distributionManagement
Hello Robert, reading the information at https://maven.apache.org/plugins/maven-site-plugin/deploy-mojo.html I do not think there is an easy way to do this and probably never will be. 1) AFAIK there is no (central) server available which hosts sites by default. 2) As stated on above page, there are a lot of different means to deploy the site via wagon (ftp, http, ssh) 3) As a workaround you might think about using the site:stage-deploy goal instead for your local builds. Regards Mirko Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:29 PM, Robert Kuropkat rkurop...@t-sciences.com wrote: So is there an equivalent to altReleaseDeploymentRepository and altSnapshotDeploymentRepository for the Site Deployment information also? Since all three are in the Distribution Management directive, I was hoping I could define this last one in the settings.xml also. Robert Kuropkat On 03/19/2014 05:15 PM, Mirko Friedenhagen wrote: Hello Eric, as outlined in https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html in your settings.xml you might define properties altReleaseDeploymentRepository and altSnapshotDeploymentRepository in a profile internal-repository which is activated by default while you do not define any repository at all in your pom. Now while developing you just invoke mvn deploy and everything should go to your local Nexus. When invoking mvn -P!internal-repository everything should go to central. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ snip - 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: The par packaging not working
Hi, Out of curiosity, what's a par packaging? The only links I found on the Web talks about perl, are they perl archive or so? Just had a quick at https://maven.apache.org/plugins/ and didn't find anything related to par. I've personnally never heard of it. Can you provide us with more details? Cheers 2014-03-20 14:30 GMT+01:00 lilyevsky leonidilyev...@yahoo.com: The par packaging is not working. It is dependent on the org.apache.maven.plugins:maven-par-plugin, but this plugin does not exist. Is it deprecated? I am using the latest maven 3.2.1. How should I make the par package these days? I know this thing is relatively simple: just a collection of jars plus manifest with a few special entries. But I don't want to re-invent the wheel. -- View this message in context: http://maven.40175.n5.nabble.com/The-par-packaging-not-working-tp5788937.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 -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Forcing Integration Tests Before a Release
Eric, when you use the maven-release-plugin a property performRelease is set during release:perform. So define in the pluginManagement section a definition for the maven-failsafe-plugin in your build section: build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution iddefault-integration-test/id goals goalintegration-test/goal /goals /execution execution iddefault-verify/id goals goalverify/goal /goals /execution /executions /plugin /plugins /pluginManagement /build and later on in your pom profile idrelease-run-failsafe/id activation property nameperformRelease/name valuetrue/value /property /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId /plugin /plugins /build profile So only during release:perform your integration tests will be executed and success is verified. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:32 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am looking for some way to force my integration tests before a release, without explicitly using a profile. For example, plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean verify site/preparationGoals /configuration /plugin But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like profiles profile idrun-it/id activation file missingtarget/failsafe-reports/missing /file /activation build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.17/version executions execution goals goalintegration-test/goal goalverify/goal /goals /execution /executions /plugin /plugins /build /profile /profiles But that will cause the integration tests to be run after every clean. Is there some way I can trigger the integration tests when doing a release mvn release:prepare without having to do mvn release:prepare -P run-it Cheers, Eric - 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: Site Repository Property was: Open Source Best Practices with Maven - distributionManagement
Yep, that is one of the many pages I had looked at also. I was also considering the stage-deploy target as I think that actually does have a property for URL, but was not sure what other side affects it would have since it might be deemed a mis-use of that feature. I need to understand it a little better and its original intent and how that maps to our local process. I also tried setting just a named property in settings.xml and referencing that property in the siteurl tag but since the URL tag behavior is to append in a parent-child pom setup, it gets confused. Disappointingly, when I look at the effective POM in Eclipse, it looks exactly they way I want. When it actually runs though, it fails. Robert Kuropkat P.S. I am currently using the jackrabbit webdav wagon, but that's just because it was the first one I got to work. On 03/20/2014 04:42 PM, Mirko Friedenhagen wrote: Hello Robert, reading the information at https://maven.apache.org/plugins/maven-site-plugin/deploy-mojo.html I do not think there is an easy way to do this and probably never will be. 1) AFAIK there is no (central) server available which hosts sites by default. 2) As stated on above page, there are a lot of different means to deploy the site via wagon (ftp, http, ssh) 3) As a workaround you might think about using the site:stage-deploy goal instead for your local builds. Regards Mirko Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 20, 2014 at 8:29 PM, Robert Kuropkat rkurop...@t-sciences.com wrote: So is there an equivalent to altReleaseDeploymentRepository and altSnapshotDeploymentRepository for the Site Deployment information also? Since all three are in the Distribution Management directive, I was hoping I could define this last one in the settings.xml also. Robert Kuropkat On 03/19/2014 05:15 PM, Mirko Friedenhagen wrote: Hello Eric, as outlined in https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html in your settings.xml you might define properties altReleaseDeploymentRepository and altSnapshotDeploymentRepository in a profile internal-repository which is activated by default while you do not define any repository at all in your pom. Now while developing you just invoke mvn deploy and everything should go to your local Nexus. When invoking mvn -P!internal-repository everything should go to central. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ snip - 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: The par packaging not working
Google has more information on the par plugin if you look there. From what I can see, the Apache Maven dev team has nothing to do with this plugin. Instead I think you should look at the Codehaus Mojo project, specifically: http://mojo.codehaus.org/jboss-packaging-maven-plugin/par-mojo.html I also found some Github links. Most likely you are going to have to build it yourself and mvn install it locally to use. Wayne On Thu, Mar 20, 2014 at 8:30 AM, lilyevsky leonidilyev...@yahoo.com wrote: The par packaging is not working. It is dependent on the org.apache.maven.plugins:maven-par-plugin, but this plugin does not exist. Is it deprecated? I am using the latest maven 3.2.1. How should I make the par package these days? I know this thing is relatively simple: just a collection of jars plus manifest with a few special entries. But I don't want to re-invent the wheel. -- View this message in context: http://maven.40175.n5.nabble.com/The-par-packaging-not-working-tp5788937.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
