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
