Re: Invoking a plugin programmatically using maven 3 and scala
Benjamin Bentmann wrote: > Jörg Schaible wrote: > >> Is it save now in M3 to declare a different plugin artifact as >> dependency? > > You mean plugin A having a dependency on plugin B? This shouldn't cause > an issue for Maven 3 when running the plugin (it should also work in > recent Maven 2.x releases IIRC). No, it does not really work in M2, since the plugin is loaded only once and this can break your build in unexpected ways. Imagine B is the assembly plugin and A depends on version 2.1 of it that allows the id/classifier to be empty. The user however uses the assembly plugin in the latest version 2.2. If at build time version 2.1 is active, the project may fail simply because that version cannot read the latest assemblies. If at build time version 2.2 is active, it will fail because of empty id/classifier. M3 was supposed to use separate classloaders for its plugins. In that case A would use assembly plugin version 2.1 while the build itself would use 2.2. Does this work now? > That inheriting from other plugins isn't really recommended and not > supported by the plugin tooling, is a different story. Until now (M2) for a very good reason. Sadly there has been never any emphasis on that recommendation (better: requirement?). We've been bitten by this (xmlbeans plugin depending on antrun plugin) and we currently do not allow the usage of any plugin that uses another one as dependency. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Invoking a plugin programmatically using maven 3 and scala
Jörg Schaible wrote: Is it save now in M3 to declare a different plugin artifact as dependency? You mean plugin A having a dependency on plugin B? This shouldn't cause an issue for Maven 3 when running the plugin (it should also work in recent Maven 2.x releases IIRC). That inheriting from other plugins isn't really recommended and not supported by the plugin tooling, is a different story. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Invoking a plugin programmatically using maven 3 and scala
Benjamin, Benjamin Bentmann wrote: > Andreas Gies wrote: > >> [INFO] org.scala-tools:scala-mojo-support:jar:0.3-SNAPSHOT >> ... >> [INFO] | +- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile >> [INFO] | | \- org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile >> [INFO] | | \- org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile >> ... >> [INFO] +- org.sonatype.spice:spice-inject-plexus:jar:1.3.4.1:compile >> [INFO] | \- org.sonatype.spice:spice-inject-bean:jar:1.3.4:compile >> [INFO] | \- >> [org.sonatype.spice.inject:guice-patches:jar:noaop:2.1.6:compile > > Those are duplicates/conflicts, sisu:1.4.2 should be used. No idea > whether that causes your linkage error but it definitely isn't a clean > class path. Is it save now in M3 to declare a different plugin artifact as dependency? In M2 this was a no-no. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Invoking a plugin programmatically using maven 3 and scala
Andreas Gies wrote: [INFO] org.scala-tools:scala-mojo-support:jar:0.3-SNAPSHOT ... [INFO] | +- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile ... [INFO] +- org.sonatype.spice:spice-inject-plexus:jar:1.3.4.1:compile [INFO] | \- org.sonatype.spice:spice-inject-bean:jar:1.3.4:compile [INFO] | \- org.sonatype.spice.inject:guice-patches:jar:noaop:2.1.6:compile Those are duplicates/conflicts, sisu:1.4.2 should be used. No idea whether that causes your linkage error but it definitely isn't a clean class path. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Invoking a plugin programmatically using maven 3 and scala
Hi Mike I posting my dependency tree below. Perhaps you can double check against the output of a mvn dependency:tree on your side; also perhaps you can post a build log. I was banging my head for weeks on this one; perhaps I can spot something. Best regards Andreas [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ scala-mojo-support --- [INFO] org.scala-tools:scala-mojo-support:jar:0.3-SNAPSHOT [INFO] +- org.apache.maven:maven-core:jar:3.0:compile [INFO] | +- org.apache.maven:maven-model:jar:3.0:compile [INFO] | +- org.apache.maven:maven-settings:jar:3.0:compile [INFO] | +- org.apache.maven:maven-settings-builder:jar:3.0:compile [INFO] | +- org.apache.maven:maven-repository-metadata:jar:3.0:compile [INFO] | +- org.apache.maven:maven-artifact:jar:3.0:compile [INFO] | +- org.apache.maven:maven-model-builder:jar:3.0:compile [INFO] | +- org.apache.maven:maven-aether-provider:jar:3.0:runtime [INFO] | +- org.sonatype.aether:aether-impl:jar:1.7:compile [INFO] | | \- org.sonatype.aether:aether-spi:jar:1.7:compile [INFO] | +- org.sonatype.aether:aether-api:jar:1.7:compile [INFO] | +- org.sonatype.aether:aether-util:jar:1.7:compile [INFO] | +- org.sonatype.sisu:sisu-inject-plexus:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-inject-bean:jar:1.4.2:compile [INFO] | | \- org.sonatype.sisu:sisu-guice:jar:noaop:2.1.7:compile [INFO] | +- org.codehaus.plexus:plexus-interpolation:jar:1.14:compile [INFO] | +- org.codehaus.plexus:plexus-utils:jar:2.0.4:compile [INFO] | +- org.codehaus.plexus:plexus-classworlds:jar:2.2.3:compile [INFO] | +- org.codehaus.plexus:plexus-component-annotations:jar:1.5.5:compile [INFO] | \- org.sonatype.plexus:plexus-sec-dispatcher:jar:1.3:compile [INFO] | \- org.sonatype.plexus:plexus-cipher:jar:1.4:compile [INFO] +- org.apache.maven:maven-plugin-api:jar:3.0:compile [INFO] +- org.apache.maven.plugin-tools:maven-plugin-tools-api:jar:2.5.1:compile [INFO] | +- org.apache.maven.reporting:maven-reporting-api:jar:2.0.6:compile [INFO] | | \- org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-7:compile [INFO] | +- org.apache.maven:maven-plugin-descriptor:jar:2.0.6:compile [INFO] | +- org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile [INFO] | | \- classworlds:classworlds:jar:1.1-alpha-2:compile [INFO] | \- jtidy:jtidy:jar:4aug2000r7-dev:compile [INFO] +- org.sonatype.spice:spice-inject-plexus:jar:1.3.4.1:compile [INFO] | \- org.sonatype.spice:spice-inject-bean:jar:1.3.4:compile [INFO] | \- org.sonatype.spice.inject:guice-patches:jar:noaop:2.1.6:compile [INFO] +- jline:jline:jar:0.9.94:compile [INFO] +- org.scala-lang:scala-library:jar:2.8.0:compile [INFO] +- org.scala-lang:scala-compiler:jar:2.8.0:compile [INFO] \- junit:junit:jar:4.8.1:test (scope not updated to compile) [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 21.298s [INFO] Finished at: Tue Oct 26 08:09:12 CEST 2010 [INFO] Final Memory: 9M/81M [INFO] Am 10/26/10 12:10 AM, schrieb Andreas Gies: Hi mike I believe that might be related to a wrong dependency and I seem to believe that I have seen this. You could post a dependency tree of your pluton and I will double check against my own pluton. Andreas Sent from my iPhone On Oct 26, 2010, at 12:03 AM, Mike Lenner wrote: Andreas - Thanks - this works for me with one huge caveat (perhaps not experienced by you since you're using scala?). When the DefaultMavenPluginManager is loaded, it's loaded as part of an org.apache.maven:maven-core specific classloader. One of the classes loaded in the PlexusConfiguration. When my plugin is loaded, it uses it's own classloader (as all plugins do I believe). This class loader also gets PlexusConfiguration loaded because I'm referencing it via the getMojoConfiguration call. What I end up with is the dreaded java.lang.LinkageError. Not sure how to move forward. Seems like PlexusConfiguration would have to be loaded into a parent classloader instead Caused by: java.lang.LinkageError: loader constraints violated when linking org/codehaus/plexus/configuration/PlexusConfiguration class On Sat, Oct 23, 2010 at 7:49 AM, Andreas Gies wrote: Hi there i *think* the key point was to call getMojoConfiguration on the Mojodescriptor I had resolved. In my case that gives me all the default configurations as I would have expected. I need only to set configs that differ from the default settings. I am attaching the latest code for my "play" plugin again. It is in scala, but you should get the idea of using the API's. Best regards Andreas Am 10/22/10 6:24 PM, schrieb Mike Lenner: Thanks very much for this thread. I'm trying to write a plugin with maven 3.0 (simply in Java) that executes another plugin as well - this
Re: Invoking a plugin programmatically using maven 3 and scala
Really? Should I not be indicating a dependency on maven-core? Seems like I'd have to though to compile against the DefaultMavenPluginManager. What do you have? Here are the dependencies for my plugin (I'm calling the assembly plugin from within my plugin - that's the reason for the final dependency): org.apache.maven maven-plugin-api 3.0 compile org.apache.maven maven-core 3.0 compile junit junit 4.8.1 test org.codehaus.plexus plexus-utils 2.0.5 compile org.apache.maven.plugins maven-assembly-plugin 2.2 compile On Mon, Oct 25, 2010 at 6:10 PM, Andreas Gies wrote: > Hi mike > > I believe that might be related to a wrong dependency and I seem to believe > that I have seen this. You could post a dependency tree of your pluton and I > will double check against my own pluton. > > Andreas > > Sent from my iPhone > > On Oct 26, 2010, at 12:03 AM, Mike Lenner wrote: > >> Andreas - >> >> Thanks - this works for me with one huge caveat (perhaps not >> experienced by you since you're using scala?). >> >> When the DefaultMavenPluginManager is loaded, it's loaded as part of >> an org.apache.maven:maven-core specific classloader. One of the >> classes loaded in the PlexusConfiguration. When my plugin is loaded, >> it uses it's own classloader (as all plugins do I believe). This >> class loader also gets PlexusConfiguration loaded because I'm >> referencing it via the getMojoConfiguration call. >> >> What I end up with is the dreaded java.lang.LinkageError. Not sure >> how to move forward. Seems like PlexusConfiguration would have to be >> loaded into a parent classloader instead >> >> Caused by: java.lang.LinkageError: loader constraints violated when >> linking org/codehaus/plexus/configuration/PlexusConfiguration class >> >> On Sat, Oct 23, 2010 at 7:49 AM, Andreas Gies >> wrote: >>> Hi there >>> >>> i *think* the key point was to call getMojoConfiguration on the >>> Mojodescriptor >>> I had resolved. In my case that gives me all the default configurations as I >>> would have >>> expected. I need only to set configs that differ from the default settings. >>> >>> I am attaching the latest code for my "play" plugin again. It is in scala, >>> but you should get >>> the idea of using the API's. >>> >>> Best regards >>> Andreas >>> >>> >>> >>> Am 10/22/10 6:24 PM, schrieb Mike Lenner: Thanks very much for this thread. I'm trying to write a plugin with maven 3.0 (simply in Java) that executes another plugin as well - this has been very helpful. Just to clear up what you've discovered, were you able to use mojoDescriptor.getMojoConfiguration to build the default configuration for the called plugin or do you still need to manually set all the default configs yourself? Right now I'm only able to get it working doing the later. Thanks, Mike On Thu, Oct 21, 2010 at 2:52 AM, Andreas Gies wrote: > > Hi all, > > just to finish up the thread, I have fixed this by adding a > @RequiresDependencyResolution("test") > to the mojo calling the dependency plugin. > > Thanks and best regards > Andreas > > Am 10/21/10 3:10 AM, schrieb Andreas Gies: >> >> Hello, >> >> a last update for today. I have compared a debug session of >> >> mvn dependency:resolve >> >> with what happens in my code. It seems, that when calling the plugin >> from >> the command line, at the end of the day >> a class named >> >> org.apache.maven.lifecycle.internal.MojoExecutor >> >> kind of controlls he execution and also takes initiates the desired >> dependency resolution before the plugin code is called. >> Therefore the dependency plugin finds the dependencies and all is good. >> >> However, when i invoke >> >> BuildPluginManager.executeMojo >> >> the dependency resolution does not happen and the dependency plugin >> doesnt >> find them. >> >> >> I have now the options to use a non-public API and reuse the >> MojoExecutor >> code or kinfd of Mimick that behavior. >> I kind of have the feeling that I am missing something very obvious in >> the >> API. A pointer to a correct call triggering >> dependency resolution would be great. Perhaps I have selected the wrong >> entrypoint into the API ? >> >> Thanks and best regards >> Andreas >> >> Am 10/21/10 2:12 AM, schrieb Andreas Gies: >>> >>> Hello, >>> >>> another update on this. From studying the source code I was under the >>> impression that mojoDescriptor.getConfiguration >>> would give me the default configuration, but it is >>> mojoDescriptor.getMojoConfiguration. >>> >>> A debug session has shown, that
Re: Invoking a plugin programmatically using maven 3 and scala
Hi mike I believe that might be related to a wrong dependency and I seem to believe that I have seen this. You could post a dependency tree of your pluton and I will double check against my own pluton. Andreas Sent from my iPhone On Oct 26, 2010, at 12:03 AM, Mike Lenner wrote: > Andreas - > > Thanks - this works for me with one huge caveat (perhaps not > experienced by you since you're using scala?). > > When the DefaultMavenPluginManager is loaded, it's loaded as part of > an org.apache.maven:maven-core specific classloader. One of the > classes loaded in the PlexusConfiguration. When my plugin is loaded, > it uses it's own classloader (as all plugins do I believe). This > class loader also gets PlexusConfiguration loaded because I'm > referencing it via the getMojoConfiguration call. > > What I end up with is the dreaded java.lang.LinkageError. Not sure > how to move forward. Seems like PlexusConfiguration would have to be > loaded into a parent classloader instead > > Caused by: java.lang.LinkageError: loader constraints violated when > linking org/codehaus/plexus/configuration/PlexusConfiguration class > > On Sat, Oct 23, 2010 at 7:49 AM, Andreas Gies wrote: >> Hi there >> >> i *think* the key point was to call getMojoConfiguration on the >> Mojodescriptor >> I had resolved. In my case that gives me all the default configurations as I >> would have >> expected. I need only to set configs that differ from the default settings. >> >> I am attaching the latest code for my "play" plugin again. It is in scala, >> but you should get >> the idea of using the API's. >> >> Best regards >> Andreas >> >> >> >> Am 10/22/10 6:24 PM, schrieb Mike Lenner: >>> >>> Thanks very much for this thread. I'm trying to write a plugin with >>> maven 3.0 (simply in Java) that executes another plugin as well - this >>> has been very helpful. >>> >>> Just to clear up what you've discovered, were you able to use >>> mojoDescriptor.getMojoConfiguration to build the default configuration >>> for the called plugin or do you still need to manually set all the >>> default configs yourself? Right now I'm only able to get it working >>> doing the later. >>> >>> Thanks, >>> Mike >>> >>> On Thu, Oct 21, 2010 at 2:52 AM, Andreas Gies >>> wrote: Hi all, just to finish up the thread, I have fixed this by adding a @RequiresDependencyResolution("test") to the mojo calling the dependency plugin. Thanks and best regards Andreas Am 10/21/10 3:10 AM, schrieb Andreas Gies: > > Hello, > > a last update for today. I have compared a debug session of > > mvn dependency:resolve > > with what happens in my code. It seems, that when calling the plugin > from > the command line, at the end of the day > a class named > > org.apache.maven.lifecycle.internal.MojoExecutor > > kind of controlls he execution and also takes initiates the desired > dependency resolution before the plugin code is called. > Therefore the dependency plugin finds the dependencies and all is good. > > However, when i invoke > > BuildPluginManager.executeMojo > > the dependency resolution does not happen and the dependency plugin > doesnt > find them. > > > I have now the options to use a non-public API and reuse the > MojoExecutor > code or kinfd of Mimick that behavior. > I kind of have the feeling that I am missing something very obvious in > the > API. A pointer to a correct call triggering > dependency resolution would be great. Perhaps I have selected the wrong > entrypoint into the API ? > > Thanks and best regards > Andreas > > Am 10/21/10 2:12 AM, schrieb Andreas Gies: >> >> Hello, >> >> another update on this. From studying the source code I was under the >> impression that mojoDescriptor.getConfiguration >> would give me the default configuration, but it is >> mojoDescriptor.getMojoConfiguration. >> >> A debug session has shown, that the dependency plugin actually >> executes, >> but somehow doesn't recognize the dependencies >> of the project. >> >> Best regards >> Andreas >> >> Am 10/20/10 8:28 PM, schrieb Andreas Gies: >>> >>> Hello, >>> >>> I forgot to mention that the output from the scala plugin is embedded >>> in >>> the build.log produced by the mavan invoker plugin. >>> >>> Best regards >>> Andreas >>> >>> Am 10/20/10 8:22 PM, schrieb Andreas Gies: Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for
Re: Invoking a plugin programmatically using maven 3 and scala
Andreas - Thanks - this works for me with one huge caveat (perhaps not experienced by you since you're using scala?). When the DefaultMavenPluginManager is loaded, it's loaded as part of an org.apache.maven:maven-core specific classloader. One of the classes loaded in the PlexusConfiguration. When my plugin is loaded, it uses it's own classloader (as all plugins do I believe). This class loader also gets PlexusConfiguration loaded because I'm referencing it via the getMojoConfiguration call. What I end up with is the dreaded java.lang.LinkageError. Not sure how to move forward. Seems like PlexusConfiguration would have to be loaded into a parent classloader instead Caused by: java.lang.LinkageError: loader constraints violated when linking org/codehaus/plexus/configuration/PlexusConfiguration class On Sat, Oct 23, 2010 at 7:49 AM, Andreas Gies wrote: > Hi there > > i *think* the key point was to call getMojoConfiguration on the > Mojodescriptor > I had resolved. In my case that gives me all the default configurations as I > would have > expected. I need only to set configs that differ from the default settings. > > I am attaching the latest code for my "play" plugin again. It is in scala, > but you should get > the idea of using the API's. > > Best regards > Andreas > > > > Am 10/22/10 6:24 PM, schrieb Mike Lenner: >> >> Thanks very much for this thread. I'm trying to write a plugin with >> maven 3.0 (simply in Java) that executes another plugin as well - this >> has been very helpful. >> >> Just to clear up what you've discovered, were you able to use >> mojoDescriptor.getMojoConfiguration to build the default configuration >> for the called plugin or do you still need to manually set all the >> default configs yourself? Right now I'm only able to get it working >> doing the later. >> >> Thanks, >> Mike >> >> On Thu, Oct 21, 2010 at 2:52 AM, Andreas Gies >> wrote: >>> >>> Hi all, >>> >>> just to finish up the thread, I have fixed this by adding a >>> @RequiresDependencyResolution("test") >>> to the mojo calling the dependency plugin. >>> >>> Thanks and best regards >>> Andreas >>> >>> Am 10/21/10 3:10 AM, schrieb Andreas Gies: Hello, a last update for today. I have compared a debug session of mvn dependency:resolve with what happens in my code. It seems, that when calling the plugin from the command line, at the end of the day a class named org.apache.maven.lifecycle.internal.MojoExecutor kind of controlls he execution and also takes initiates the desired dependency resolution before the plugin code is called. Therefore the dependency plugin finds the dependencies and all is good. However, when i invoke BuildPluginManager.executeMojo the dependency resolution does not happen and the dependency plugin doesnt find them. I have now the options to use a non-public API and reuse the MojoExecutor code or kinfd of Mimick that behavior. I kind of have the feeling that I am missing something very obvious in the API. A pointer to a correct call triggering dependency resolution would be great. Perhaps I have selected the wrong entrypoint into the API ? Thanks and best regards Andreas Am 10/21/10 2:12 AM, schrieb Andreas Gies: > > Hello, > > another update on this. From studying the source code I was under the > impression that mojoDescriptor.getConfiguration > would give me the default configuration, but it is > mojoDescriptor.getMojoConfiguration. > > A debug session has shown, that the dependency plugin actually > executes, > but somehow doesn't recognize the dependencies > of the project. > > Best regards > Andreas > > Am 10/20/10 8:28 PM, schrieb Andreas Gies: >> >> Hello, >> >> I forgot to mention that the output from the scala plugin is embedded >> in >> the build.log produced by the mavan invoker plugin. >> >> Best regards >> Andreas >> >> Am 10/20/10 8:22 PM, schrieb Andreas Gies: >>> >>> Hello, >>> >>> I am still banging my head on this problem, though I got a bit >>> farther. >>> I found a link via Google pointing to the maven site plugin and there >>> to the >>> DefaultMavenReportExecutor. I have tried to mimick the behavior in my >>> special >>> case and for testing I want to invoke the maven dependency plugin, >>> namely >>> the unpack dependencies goal. >>> >>> It seems to work if I provide all the missing paramters (like project >>> etc.) into >>> the configuration as expressions as follows >>> >>> val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( >>> buildConfiguration( >>> Map( >>> "outputDirectory" -> "test", >>> "project" -> "${project}", >>>
Re: Invoking a plugin programmatically using maven 3 and scala
Hi there i *think* the key point was to call getMojoConfiguration on the Mojodescriptor I had resolved. In my case that gives me all the default configurations as I would have expected. I need only to set configs that differ from the default settings. I am attaching the latest code for my "play" plugin again. It is in scala, but you should get the idea of using the API's. Best regards Andreas Am 10/22/10 6:24 PM, schrieb Mike Lenner: Thanks very much for this thread. I'm trying to write a plugin with maven 3.0 (simply in Java) that executes another plugin as well - this has been very helpful. Just to clear up what you've discovered, were you able to use mojoDescriptor.getMojoConfiguration to build the default configuration for the called plugin or do you still need to manually set all the default configs yourself? Right now I'm only able to get it working doing the later. Thanks, Mike On Thu, Oct 21, 2010 at 2:52 AM, Andreas Gies wrote: Hi all, just to finish up the thread, I have fixed this by adding a @RequiresDependencyResolution("test") to the mojo calling the dependency plugin. Thanks and best regards Andreas Am 10/21/10 3:10 AM, schrieb Andreas Gies: Hello, a last update for today. I have compared a debug session of mvn dependency:resolve with what happens in my code. It seems, that when calling the plugin from the command line, at the end of the day a class named org.apache.maven.lifecycle.internal.MojoExecutor kind of controlls he execution and also takes initiates the desired dependency resolution before the plugin code is called. Therefore the dependency plugin finds the dependencies and all is good. However, when i invoke BuildPluginManager.executeMojo the dependency resolution does not happen and the dependency plugin doesnt find them. I have now the options to use a non-public API and reuse the MojoExecutor code or kinfd of Mimick that behavior. I kind of have the feeling that I am missing something very obvious in the API. A pointer to a correct call triggering dependency resolution would be great. Perhaps I have selected the wrong entrypoint into the API ? Thanks and best regards Andreas Am 10/21/10 2:12 AM, schrieb Andreas Gies: Hello, another update on this. From studying the source code I was under the impression that mojoDescriptor.getConfiguration would give me the default configuration, but it is mojoDescriptor.getMojoConfiguration. A debug session has shown, that the dependency plugin actually executes, but somehow doesn't recognize the dependencies of the project. Best regards Andreas Am 10/20/10 8:28 PM, schrieb Andreas Gies: Hello, I forgot to mention that the output from the scala plugin is embedded in the build.log produced by the mavan invoker plugin. Best regards Andreas Am 10/20/10 8:22 PM, schrieb Andreas Gies: Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for testing I want to invoke the maven dependency plugin, namely the unpack dependencies goal. It seems to work if I provide all the missing paramters (like project etc.) into the configuration as expressions as follows val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( buildConfiguration( Map( "outputDirectory" -> "test", "project" -> "${project}", "local" -> "${localRepository}", "reactorProjects" -> "${reactorProjects}" , "remoteRepos" -> "${project.remoteArtifactRepositories}" ) ), convert(md) ) That approach doesn't give me any Exceptions. I would have expected that all parameters except the non-default output directory would be resolved as the dependency plugin gives default expressions for them. However, this approach removes the parameter exceptions from before, but calling it doesn't unpack the dependencies (nothing happens really). I have tried to use the LifecycleExecutor.executeForkedExecutions BuildPluginManager.executeMojo and even tried to call execute on the configured Mojo (which I probably shouldn't do ?) I have attached a sample build output and also the code of my scala based mojo. Apart from studying the source code of the API and some sample plugins, is there documentation how the new plugin API is supposed to work ? Am I trying to do something out of the ordinary here ? (I know I could configure the dependency plugin in the pom but as this is *such* an essential step in the final mojo I don't want to give the user the option of leaving it out ... and I wanted to learn some more maven internals). Has anyone an example of initializing and calling a mojo from within a mojo using the new API ? - Java is fine as well, I can adopt it to scala as a learning exercise. I think I might be missing something in terms of hooking up or registering the p
Re: Invoking a plugin programmatically using maven 3 and scala
Thanks very much for this thread. I'm trying to write a plugin with maven 3.0 (simply in Java) that executes another plugin as well - this has been very helpful. Just to clear up what you've discovered, were you able to use mojoDescriptor.getMojoConfiguration to build the default configuration for the called plugin or do you still need to manually set all the default configs yourself? Right now I'm only able to get it working doing the later. Thanks, Mike On Thu, Oct 21, 2010 at 2:52 AM, Andreas Gies wrote: > Hi all, > > just to finish up the thread, I have fixed this by adding a > @RequiresDependencyResolution("test") > to the mojo calling the dependency plugin. > > Thanks and best regards > Andreas > > Am 10/21/10 3:10 AM, schrieb Andreas Gies: >> >> Hello, >> >> a last update for today. I have compared a debug session of >> >> mvn dependency:resolve >> >> with what happens in my code. It seems, that when calling the plugin from >> the command line, at the end of the day >> a class named >> >> org.apache.maven.lifecycle.internal.MojoExecutor >> >> kind of controlls he execution and also takes initiates the desired >> dependency resolution before the plugin code is called. >> Therefore the dependency plugin finds the dependencies and all is good. >> >> However, when i invoke >> >> BuildPluginManager.executeMojo >> >> the dependency resolution does not happen and the dependency plugin doesnt >> find them. >> >> >> I have now the options to use a non-public API and reuse the MojoExecutor >> code or kinfd of Mimick that behavior. >> I kind of have the feeling that I am missing something very obvious in the >> API. A pointer to a correct call triggering >> dependency resolution would be great. Perhaps I have selected the wrong >> entrypoint into the API ? >> >> Thanks and best regards >> Andreas >> >> Am 10/21/10 2:12 AM, schrieb Andreas Gies: >>> >>> Hello, >>> >>> another update on this. From studying the source code I was under the >>> impression that mojoDescriptor.getConfiguration >>> would give me the default configuration, but it is >>> mojoDescriptor.getMojoConfiguration. >>> >>> A debug session has shown, that the dependency plugin actually executes, >>> but somehow doesn't recognize the dependencies >>> of the project. >>> >>> Best regards >>> Andreas >>> >>> Am 10/20/10 8:28 PM, schrieb Andreas Gies: Hello, I forgot to mention that the output from the scala plugin is embedded in the build.log produced by the mavan invoker plugin. Best regards Andreas Am 10/20/10 8:22 PM, schrieb Andreas Gies: > > Hello, > > I am still banging my head on this problem, though I got a bit farther. > I found a link via Google pointing to the maven site plugin and there > to the > DefaultMavenReportExecutor. I have tried to mimick the behavior in my > special > case and for testing I want to invoke the maven dependency plugin, > namely > the unpack dependencies goal. > > It seems to work if I provide all the missing paramters (like project > etc.) into > the configuration as expressions as follows > > val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( > buildConfiguration( > Map( > "outputDirectory" -> "test", > "project" -> "${project}", > "local" -> "${localRepository}", > "reactorProjects" -> "${reactorProjects}" , > "remoteRepos" -> "${project.remoteArtifactRepositories}" > ) > ), > convert(md) > ) > > That approach doesn't give me any Exceptions. I would have expected > that all parameters except the non-default output directory > would be resolved as the dependency plugin gives default expressions > for them. > > > However, this approach removes the parameter exceptions from before, > but calling it doesn't unpack the dependencies (nothing happens really). > > I have tried to use the > > LifecycleExecutor.executeForkedExecutions > BuildPluginManager.executeMojo > > and even tried to call execute on the configured Mojo (which I probably > shouldn't do ?) > > I have attached a sample build output and also the code of my scala > based mojo. > > Apart from studying the source code of the API and some sample plugins, > is there documentation how the > new plugin API is supposed to work ? > > Am I trying to do something out of the ordinary here ? (I know I could > configure the dependency plugin in the > pom but as this is *such* an essential step in the final mojo I don't > want to give the user the option of leaving it > out ... and I wanted to learn some more maven internals). > > Has anyone an example of initializing and calling a mojo from within a > mojo using the new API ? - Java is fine as > well, I can adopt it to scala as a
Re: Invoking a plugin programmatically using maven 3 and scala
Hi all, just to finish up the thread, I have fixed this by adding a @RequiresDependencyResolution("test") to the mojo calling the dependency plugin. Thanks and best regards Andreas Am 10/21/10 3:10 AM, schrieb Andreas Gies: Hello, a last update for today. I have compared a debug session of mvn dependency:resolve with what happens in my code. It seems, that when calling the plugin from the command line, at the end of the day a class named org.apache.maven.lifecycle.internal.MojoExecutor kind of controlls he execution and also takes initiates the desired dependency resolution before the plugin code is called. Therefore the dependency plugin finds the dependencies and all is good. However, when i invoke BuildPluginManager.executeMojo the dependency resolution does not happen and the dependency plugin doesnt find them. I have now the options to use a non-public API and reuse the MojoExecutor code or kinfd of Mimick that behavior. I kind of have the feeling that I am missing something very obvious in the API. A pointer to a correct call triggering dependency resolution would be great. Perhaps I have selected the wrong entrypoint into the API ? Thanks and best regards Andreas Am 10/21/10 2:12 AM, schrieb Andreas Gies: Hello, another update on this. From studying the source code I was under the impression that mojoDescriptor.getConfiguration would give me the default configuration, but it is mojoDescriptor.getMojoConfiguration. A debug session has shown, that the dependency plugin actually executes, but somehow doesn't recognize the dependencies of the project. Best regards Andreas Am 10/20/10 8:28 PM, schrieb Andreas Gies: Hello, I forgot to mention that the output from the scala plugin is embedded in the build.log produced by the mavan invoker plugin. Best regards Andreas Am 10/20/10 8:22 PM, schrieb Andreas Gies: Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for testing I want to invoke the maven dependency plugin, namely the unpack dependencies goal. It seems to work if I provide all the missing paramters (like project etc.) into the configuration as expressions as follows val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( buildConfiguration( Map( "outputDirectory" -> "test", "project" -> "${project}", "local" -> "${localRepository}", "reactorProjects" -> "${reactorProjects}" , "remoteRepos" -> "${project.remoteArtifactRepositories}" ) ), convert(md) ) That approach doesn't give me any Exceptions. I would have expected that all parameters except the non-default output directory would be resolved as the dependency plugin gives default expressions for them. However, this approach removes the parameter exceptions from before, but calling it doesn't unpack the dependencies (nothing happens really). I have tried to use the LifecycleExecutor.executeForkedExecutions BuildPluginManager.executeMojo and even tried to call execute on the configured Mojo (which I probably shouldn't do ?) I have attached a sample build output and also the code of my scala based mojo. Apart from studying the source code of the API and some sample plugins, is there documentation how the new plugin API is supposed to work ? Am I trying to do something out of the ordinary here ? (I know I could configure the dependency plugin in the pom but as this is *such* an essential step in the final mojo I don't want to give the user the option of leaving it out ... and I wanted to learn some more maven internals). Has anyone an example of initializing and calling a mojo from within a mojo using the new API ? - Java is fine as well, I can adopt it to scala as a learning exercise. I think I might be missing something in terms of hooking up or registering the project with the dependency plugin though the build output indicates that the project is referenced correctly. Any hints would be really appreciated; if I am hitting the wrong list, please let me know. Thanks in advance Andreas Am 10/13/10 9:27 AM, schrieb Andreas Gies: Hello Maveners , mainly for self learning purposes I am trying to build some plugins for Maven 3 using the Scala language. One of the things I had going before (Maven 2 & Java based) is to invoke another plugin programmatically. Now I am trying to invoke the dependency plugin, namely the unpack-dependencies goal and am running into a rather cryptic error message: [ERROR] Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cli) on project test-plugin: The parameters 'proje ct', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependenci
Re: Invoking a plugin programmatically using maven 3 and scala
Hello, a last update for today. I have compared a debug session of mvn dependency:resolve with what happens in my code. It seems, that when calling the plugin from the command line, at the end of the day a class named org.apache.maven.lifecycle.internal.MojoExecutor kind of controlls he execution and also takes initiates the desired dependency resolution before the plugin code is called. Therefore the dependency plugin finds the dependencies and all is good. However, when i invoke BuildPluginManager.executeMojo the dependency resolution does not happen and the dependency plugin doesnt find them. I have now the options to use a non-public API and reuse the MojoExecutor code or kinfd of Mimick that behavior. I kind of have the feeling that I am missing something very obvious in the API. A pointer to a correct call triggering dependency resolution would be great. Perhaps I have selected the wrong entrypoint into the API ? Thanks and best regards Andreas Am 10/21/10 2:12 AM, schrieb Andreas Gies: Hello, another update on this. From studying the source code I was under the impression that mojoDescriptor.getConfiguration would give me the default configuration, but it is mojoDescriptor.getMojoConfiguration. A debug session has shown, that the dependency plugin actually executes, but somehow doesn't recognize the dependencies of the project. Best regards Andreas Am 10/20/10 8:28 PM, schrieb Andreas Gies: Hello, I forgot to mention that the output from the scala plugin is embedded in the build.log produced by the mavan invoker plugin. Best regards Andreas Am 10/20/10 8:22 PM, schrieb Andreas Gies: Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for testing I want to invoke the maven dependency plugin, namely the unpack dependencies goal. It seems to work if I provide all the missing paramters (like project etc.) into the configuration as expressions as follows val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( buildConfiguration( Map( "outputDirectory" -> "test", "project" -> "${project}", "local" -> "${localRepository}", "reactorProjects" -> "${reactorProjects}" , "remoteRepos" -> "${project.remoteArtifactRepositories}" ) ), convert(md) ) That approach doesn't give me any Exceptions. I would have expected that all parameters except the non-default output directory would be resolved as the dependency plugin gives default expressions for them. However, this approach removes the parameter exceptions from before, but calling it doesn't unpack the dependencies (nothing happens really). I have tried to use the LifecycleExecutor.executeForkedExecutions BuildPluginManager.executeMojo and even tried to call execute on the configured Mojo (which I probably shouldn't do ?) I have attached a sample build output and also the code of my scala based mojo. Apart from studying the source code of the API and some sample plugins, is there documentation how the new plugin API is supposed to work ? Am I trying to do something out of the ordinary here ? (I know I could configure the dependency plugin in the pom but as this is *such* an essential step in the final mojo I don't want to give the user the option of leaving it out ... and I wanted to learn some more maven internals). Has anyone an example of initializing and calling a mojo from within a mojo using the new API ? - Java is fine as well, I can adopt it to scala as a learning exercise. I think I might be missing something in terms of hooking up or registering the project with the dependency plugin though the build output indicates that the project is referenced correctly. Any hints would be really appreciated; if I am hitting the wrong list, please let me know. Thanks in advance Andreas Am 10/13/10 9:27 AM, schrieb Andreas Gies: Hello Maveners , mainly for self learning purposes I am trying to build some plugins for Maven 3 using the Scala language. One of the things I had going before (Maven 2 & Java based) is to invoke another plugin programmatically. Now I am trying to invoke the dependency plugin, namely the unpack-dependencies goal and am running into a rather cryptic error message: [ERROR] Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cli) on project test-plugin: The parameters 'proje ct', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invali d -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cl i) on project test-plugin: The para
Re: Invoking a plugin programmatically using maven 3 and scala
Hello, another update on this. From studying the source code I was under the impression that mojoDescriptor.getConfiguration would give me the default configuration, but it is mojoDescriptor.getMojoConfiguration. A debug session has shown, that the dependency plugin actually executes, but somehow doesn't recognize the dependencies of the project. Best regards Andreas Am 10/20/10 8:28 PM, schrieb Andreas Gies: Hello, I forgot to mention that the output from the scala plugin is embedded in the build.log produced by the mavan invoker plugin. Best regards Andreas Am 10/20/10 8:22 PM, schrieb Andreas Gies: Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for testing I want to invoke the maven dependency plugin, namely the unpack dependencies goal. It seems to work if I provide all the missing paramters (like project etc.) into the configuration as expressions as follows val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( buildConfiguration( Map( "outputDirectory" -> "test", "project" -> "${project}", "local" -> "${localRepository}", "reactorProjects" -> "${reactorProjects}" , "remoteRepos" -> "${project.remoteArtifactRepositories}" ) ), convert(md) ) That approach doesn't give me any Exceptions. I would have expected that all parameters except the non-default output directory would be resolved as the dependency plugin gives default expressions for them. However, this approach removes the parameter exceptions from before, but calling it doesn't unpack the dependencies (nothing happens really). I have tried to use the LifecycleExecutor.executeForkedExecutions BuildPluginManager.executeMojo and even tried to call execute on the configured Mojo (which I probably shouldn't do ?) I have attached a sample build output and also the code of my scala based mojo. Apart from studying the source code of the API and some sample plugins, is there documentation how the new plugin API is supposed to work ? Am I trying to do something out of the ordinary here ? (I know I could configure the dependency plugin in the pom but as this is *such* an essential step in the final mojo I don't want to give the user the option of leaving it out ... and I wanted to learn some more maven internals). Has anyone an example of initializing and calling a mojo from within a mojo using the new API ? - Java is fine as well, I can adopt it to scala as a learning exercise. I think I might be missing something in terms of hooking up or registering the project with the dependency plugin though the build output indicates that the project is referenced correctly. Any hints would be really appreciated; if I am hitting the wrong list, please let me know. Thanks in advance Andreas Am 10/13/10 9:27 AM, schrieb Andreas Gies: Hello Maveners , mainly for self learning purposes I am trying to build some plugins for Maven 3 using the Scala language. One of the things I had going before (Maven 2 & Java based) is to invoke another plugin programmatically. Now I am trying to invoke the dependency plugin, namely the unpack-dependencies goal and am running into a rather cryptic error message: [ERROR] Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cli) on project test-plugin: The parameters 'proje ct', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invali d -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cl i) on project test-plugin: The parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invalid at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:88) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:80) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:87) 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:315) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
Re: Invoking a plugin programmatically using maven 3 and scala
Hello, I forgot to mention that the output from the scala plugin is embedded in the build.log produced by the mavan invoker plugin. Best regards Andreas Am 10/20/10 8:22 PM, schrieb Andreas Gies: Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for testing I want to invoke the maven dependency plugin, namely the unpack dependencies goal. It seems to work if I provide all the missing paramters (like project etc.) into the configuration as expressions as follows val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( buildConfiguration( Map( "outputDirectory" -> "test", "project" -> "${project}", "local" -> "${localRepository}", "reactorProjects" -> "${reactorProjects}" , "remoteRepos" -> "${project.remoteArtifactRepositories}" ) ), convert(md) ) That approach doesn't give me any Exceptions. I would have expected that all parameters except the non-default output directory would be resolved as the dependency plugin gives default expressions for them. However, this approach removes the parameter exceptions from before, but calling it doesn't unpack the dependencies (nothing happens really). I have tried to use the LifecycleExecutor.executeForkedExecutions BuildPluginManager.executeMojo and even tried to call execute on the configured Mojo (which I probably shouldn't do ?) I have attached a sample build output and also the code of my scala based mojo. Apart from studying the source code of the API and some sample plugins, is there documentation how the new plugin API is supposed to work ? Am I trying to do something out of the ordinary here ? (I know I could configure the dependency plugin in the pom but as this is *such* an essential step in the final mojo I don't want to give the user the option of leaving it out ... and I wanted to learn some more maven internals). Has anyone an example of initializing and calling a mojo from within a mojo using the new API ? - Java is fine as well, I can adopt it to scala as a learning exercise. I think I might be missing something in terms of hooking up or registering the project with the dependency plugin though the build output indicates that the project is referenced correctly. Any hints would be really appreciated; if I am hitting the wrong list, please let me know. Thanks in advance Andreas Am 10/13/10 9:27 AM, schrieb Andreas Gies: Hello Maveners , mainly for self learning purposes I am trying to build some plugins for Maven 3 using the Scala language. One of the things I had going before (Maven 2 & Java based) is to invoke another plugin programmatically. Now I am trying to invoke the dependency plugin, namely the unpack-dependencies goal and am running into a rather cryptic error message: [ERROR] Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cli) on project test-plugin: The parameters 'proje ct', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invali d -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cl i) on project test-plugin: The parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invalid at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:88) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:80) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:87) 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:315) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Dele
Re: Invoking a plugin programmatically using maven 3 and scala
Hello, I am still banging my head on this problem, though I got a bit farther. I found a link via Google pointing to the maven site plugin and there to the DefaultMavenReportExecutor. I have tried to mimick the behavior in my special case and for testing I want to invoke the maven dependency plugin, namely the unpack dependencies goal. It seems to work if I provide all the missing paramters (like project etc.) into the configuration as expressions as follows val config : Xpp3Dom = Xpp3DomUtils.mergeXpp3Dom( buildConfiguration( Map( "outputDirectory" -> "test", "project" -> "${project}", "local" -> "${localRepository}", "reactorProjects" -> "${reactorProjects}" , "remoteRepos" -> "${project.remoteArtifactRepositories}" ) ), convert(md) ) That approach doesn't give me any Exceptions. I would have expected that all parameters except the non-default output directory would be resolved as the dependency plugin gives default expressions for them. However, this approach removes the parameter exceptions from before, but calling it doesn't unpack the dependencies (nothing happens really). I have tried to use the LifecycleExecutor.executeForkedExecutions BuildPluginManager.executeMojo and even tried to call execute on the configured Mojo (which I probably shouldn't do ?) I have attached a sample build output and also the code of my scala based mojo. Apart from studying the source code of the API and some sample plugins, is there documentation how the new plugin API is supposed to work ? Am I trying to do something out of the ordinary here ? (I know I could configure the dependency plugin in the pom but as this is *such* an essential step in the final mojo I don't want to give the user the option of leaving it out ... and I wanted to learn some more maven internals). Has anyone an example of initializing and calling a mojo from within a mojo using the new API ? - Java is fine as well, I can adopt it to scala as a learning exercise. I think I might be missing something in terms of hooking up or registering the project with the dependency plugin though the build output indicates that the project is referenced correctly. Any hints would be really appreciated; if I am hitting the wrong list, please let me know. Thanks in advance Andreas Am 10/13/10 9:27 AM, schrieb Andreas Gies: Hello Maveners , mainly for self learning purposes I am trying to build some plugins for Maven 3 using the Scala language. One of the things I had going before (Maven 2 & Java based) is to invoke another plugin programmatically. Now I am trying to invoke the dependency plugin, namely the unpack-dependencies goal and am running into a rather cryptic error message: [ERROR] Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cli) on project test-plugin: The parameters 'proje ct', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invali d -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cl i) on project test-plugin: The parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invalid at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:88) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:80) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:87) 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:315) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at or
Invoking a plugin programmatically using maven 3 and scala
Hello Maveners , mainly for self learning purposes I am trying to build some plugins for Maven 3 using the Scala language. One of the things I had going before (Maven 2 & Java based) is to invoke another plugin programmatically. Now I am trying to invoke the dependency plugin, namely the unpack-dependencies goal and am running into a rather cryptic error message: [ERROR] Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cli) on project test-plugin: The parameters 'proje ct', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invali d -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.progress.maven.plugins:plugin-sandbox:8.0-SNAPSHOT:echo (default-cl i) on project test-plugin: The parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invalid at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:157) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:88) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:80) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:87) 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:315) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:445) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:168) at org.apache.maven.cli.MavenCli.main(MavenCli.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginParameterException: The parameters 'project', 'local', 'remoteRepos', 'reactorProjects' for goal org.apache.maven.plugins:maven-dependency-plugin:2.1:unpack-dependencies are missing or invalid at org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:514) at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:467) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:96) at de.woq.maven.plugins.TestMojo.execute(TestMojo.scala:109) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) ... 19 more It seems that the current project is not passed correctly to the plugin. I have noticed that the API for invoking plugins has slightly changed, but was unable to get more information. Any hints where to dig deeper would be greatly appreciated. For completeness here is the code of my plugin so far (As I said its a learning exercise :)) /* * Copyright (C) 2010, Way of Quality * All rights reserved. * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package de.woq.maven.plugins import org.apache.maven.plugin._ import descriptor.MojoDescriptor import org.scala_tools.maven.mojo.annotations._ import org.apache.maven.project.MavenProject import org.apache.maven.execution.MavenSession import org.apache.maven.model.Plugin import scala.collection.JavaConversions._ import