maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Casey" <>
Subject Re: [vote] Allowing Ant-based plugins to use file-based resources
Date Wed, 11 Oct 2006 03:01:35 GMT
Tentative +1...

There should be a metadata XML file that accompanies the build.xml file for
the plugin, which allows you to use normal mojo expressions to
declare/define parameters to be injected. I think you should be able to use
things like ${plugin} to get at the PluginDescriptor, and ${project} to get
the maven project instance. As for the plugin's own jar, I'm not sure...

Of course, if you're doing this BEFORE the mojo runs, then I don't know how
you'd retrieve those things without putting some sort of component lookup
(and dependency) into the ant plugin support...not sure. I'd have to see
some concrete examples of what you're trying to accomplish, I guess, and
when those things need to be available.

While I think this sounds interesting, I also wonder why you wouldn't just
expand the entire plugin jar, and reference the resulting directory somehow.
But, maybe I'm not understanding...


On 10/9/06, Jason van Zyl <> wrote:
> On 6 Oct 06, at 8:24 PM 6 Oct 06, Kenney Westerhof wrote:
> > +1, and i'm really curious how you would fit that into 10 lines.. ;)
> >
> After I worked on Plexus Archiver it's now 12 lines :-)
> > Btw, IIRC the current ant plugin tools already unpack the jar to /
> > tmp/someplace
> > so they can specify the location to the build.xml in the archive; I
> > seem to remember
> > that you couldn't just present an InputStream or URL to Ant to
> > parse a build.xml.
> >
> Yah, this is in the AntScriptInvoker which is cool. But I need a
> modification so that resources are unpacked before the build.xml file
> is executed. So I'm making an addition to the AntMojoWrapper but I
> need to add a few things:
> 1) the plugin JAR from the repository
> 2) the plugin id
> 3) the MavenProject so I can get the target directory
> I was hoping I could get these from the plugin context, which is just
> a Map, but there's nothing in there. So I can populate it in the
> DefautPluginManager which is what I would like to do. John, is there
> any other way to push values in the plugin context. I see the code in
> the ReactorManager, and MavenSession but I'm not sure how you have
> been using the context.
> Anyway, I would like to make this change in the trunk and then in
> branch as I don't think this is a huge change and highly useful.
> > If this is the case, you may want to re-use that unpack location
> > instead of copying
> > to target/.../.
> >
> > But you probably know the code better than me :)
> >
> > Jason van Zyl wrote:
> >> Hi,
> >> I chatted with Kenney briefly about allowing ant-based plugins to
> >> unpack resources from a known location to a known location so they
> >> things like shell scripts can be executed.
> >> So, in a nutshell I would like to add some capability to unpack
> >> the resources in an ant-based plugin JAR to ${basedir}/target/
> >> <artifact-id> and from there if the ant scripts want to reference
> >> file based resources they can. My particular use case is a user
> >> that wants to leverage all the bash and perl they have already use
> >> with their ant builds but they want them to be reusable.
> >> If no one objects I'll do the work on trunk and then merge it to
> >> the branch. It's a new feature but it's super simple (10 lines)
> >> and it would certainly be useful in 2.0.5.
> >> Jason
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> For additional commands, e-mail:
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message