On Sunday 16 March 2008, EJ Ciramella wrote:
> Hmmm - maybe there's a disconnect then. I think this plugin
> perfectly suits my needs (if it worked or was better documented).
>
> What I need:
>
> 1 - pull down a dependency
> 2 - extract said dependency outside of the target directory (or to
> some other settings.xml specified location).
Right. But remote-resources will then add that directory to the build
such that any subsequent "jar" call will pick them up anyway.
remote-resources is designed to make everything it outputs get sucked
into the jars. The "jar" jar, the sources jar, the test jar, the
javadoc jar, etc.... Thus, you might as well just use
dependency:unpack to unpack to a resources dir that then gets filtered.
> 3 - process a list of files on the way out.
remote-resources only processes files ending in ".vm" (and it strips
the .vm off). Basically, they are just treated as velocity templates
and fed into velocity. Anything else is just copied directly, no
processing.
Also, the "properties" that are fed into the velocity context are NOT the
entire list of of project properties. (although you might be able to
do ${project.properties.get('...')} or similar) Generally, the stuff
that is filtered in is configured on the plugin itself. This is
pretty much as designed cause when you are dealing with legal junk like
the NOTICE files and stuff, you REALLY need complete control over what
is happening.
Dan
>
>
>
> -----Original Message-----
> From: Daniel Kulp [mailto:[EMAIL PROTECTED]
> Sent: Sat 3/15/2008 1:01 PM
> To: users@maven.apache.org
> Cc: EJ Ciramella
> Subject: Re: Copy:unpack
>
>
>
> My gut feeling is that remote-resources is NOT the plugin to be used
> for this. remote-resources will only process specific files in the
> bundle and only if the bundle is properly created with the
> remote-resources:bundle goal. It also only fills in
> properties/values that are specifically set in the plugins
> configuration, not everything in the pom. remote-resources targets a
> specific need, and this really doesn't sound like it.
>
> Most likely, you should add a feature request to the dependency plugin
> to allow filtering of stuff that is unpacked. I think a new filtering
> component was created recently that could make it pretty easy to do.
> Not really sure though.
>
> Dan
>
> On Saturday 15 March 2008, EJ Ciramella wrote:
> > Well these questions are directed at the entire mailing list.
> >
> > I do appreciate all the energy you've put into this.
> >
> > We started work on a series of plugins because of how little is
> > known about this particular one (can I submit changes to the
> > documentation that helped me?), but I'd hate to manage a plugin that
> > is pretty much a duplicate of what is offered out of the box (but we
> > just can't figure out how to use it).
> >
> >
> > -----Original Message-----
> > From: Brian E. Fox [mailto:[EMAIL PROTECTED]
> > Sent: Fri 3/14/2008 8:54 PM
> > To: Maven Users List
> > Subject: RE: Copy:unpack
> >
> > The maven build is using it, as are lots of other builds at apache
> > to handle the NOTICE and LICENSE files, so I know it works a little
> > bit...but alas I haven't actually used it to filter anything myself.
> >
> > -----Original Message-----
> > From: EJ Ciramella [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 14, 2008 8:41 PM
> > To: Maven Users List
> > Subject: RE: Copy:unpack
> >
> > Done:
> >
> > http://jira.codehaus.org/browse/MRRESOURCES-33
> >
> >
> > No suggestions or pointers on getting this bugger working? I could
> > live with the duplicated version number. What I can't deal with is
> > this NOT processing resources like it says it's supposed to.
> >
> > When run with -X -e, btw, the output shows the resources like this:
> >
> > (f) resources = [EMAIL PROTECTED],
> > [EMAIL PROTECTED]
> >
> > I'm guessing this could have been something more like
> > resources.getName() or getPath() or something. Not the memory
> > address or w/e...
> >
> > -----Original Message-----
> > From: Brian E. Fox [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 14, 2008 8:17 PM
> > To: Maven Users List
> > Subject: RE: Copy:unpack
> >
> > >2 - verified that I can pull it down (still not thrilled about
> > > listing version twice in the same pom). The plugin should look up
> > > the version like dependency:unpack
> >
> > Can you file a jira?
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
