So in the end, I just separated my wrapper utility into a small maven
project upon which the plugin depends. I was hoping not to do it,
since it's basically two classes, but it's likely the right way to
handle it anyway. Thanks for the suggestions.
Incidentally, the plugin expression is broken, as you described it
(you can use ${plugin.artifacts} etc. though), and ironically the list
of artifacts and plugins accessible using the above workaround don't
include the actual artifact of the plugin you're executing.
It's probably a really small edge-case, but it would be good to get at
the actual artifact of the currently executing mojo. You can get at
most of its metadata, just not the artifact object itself, nor
(therefore) its file.
Christian.
On 6-Sep-07, at 1:14 AM, John Casey wrote:
I thought that was available under the parameter expression $
{plugin}, which returns the current plugin's PluginDescriptor
instance...from there, I thought there was an accessor method that
exposed the artifacts used to create that plugin's classpath...
Maybe I'm dreaming, or maybe it's changed...but it might be a place
to start looking.
-john
On Sep 5, 2007, at 6:34 PM, Christian Gruber wrote:
Hey,
I'm trying to use pluginArtifacts to include the current plugin's
jar as a classpath for an external call, as I have created a crazy
but necessary wrapper. When I go to find the plugin in
pluginArtifacts, I find that I cannot, and that pluginArtifacts is
not populated on MavenProject. Is there metadata I'm missing that
I have to set that causes maven to populate this on this.project?
you know, the equivalent of @resolveDependencies.
Christian.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
