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 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
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 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 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/ - 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: 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: org.apache.maven.plugins maven-failsafe-plugin 2.17 default-integration-test integration-test default-verify verify and later on in your pom release-run-failsafe performRelease true org.apache.maven.plugins maven-failsafe-plugin 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 wrote: > I am looking for some way to force my integration tests before a release, > without explicitly using a profile. > > For example, > > > maven-release-plugin > > clean verify site > > > > But that doesn't work because unless the failsafe plugin is defined, it > won't run the tests. > > I thought of doing something like > > > > run-it > > > target/failsafe-reports > > > > > > org.apache.maven.plugins > maven-failsafe-plugin > 2.17 > > > > integration-test > verify > > > > > > > > > > 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
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 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/ >> >> >> > > > - > 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 : > > 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 MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: Forcing Integration Tests Before a Release
On 21 March 2014 06:02, Eric Kolotyluk 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
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, maven-release-plugin clean verify site But that doesn't work because unless the failsafe plugin is defined, it won't run the tests. I thought of doing something like run-it target/failsafe-reports org.apache.maven.plugins maven-failsafe-plugin 2.17 integration-test verify 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
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/ - 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: github kolotyluk /secret/ 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 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-mai
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 > 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: 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: org.apache.maven.plugins maven-ear-plugin 2.9 fuseim xstreamline3-webservice /data / 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: 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
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
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: > > > > > org.apache.maven.plugins > maven-ear-plugin > 2.9 > > . > > > fuseim > xstreamline3-webservice > /data > / > > > 5 > > > > > > And this is a piece of code in the EAR's parent pom: > > > > jboss6 > > 6 > **/*.jar > > > > > org.apache.maven.plugins > maven-ear-plugin > 2.9 > > > > fuseim > xstreamline3-webservice > /data > / > > > > > > > > > > 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
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: org.apache.maven.plugins maven-ear-plugin 2.9 . fuseim xstreamline3-webservice /data / 5 And this is a piece of code in the EAR's parent pom: jboss6 6 **/*.jar org.apache.maven.plugins maven-ear-plugin 2.9 fuseim xstreamline3-webservice /data / 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: 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 wrote: > > 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
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 wrote: > 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
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
