You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Daniel Kulp <dk...@apache.org> on 2008/03/15 18:01:52 UTC
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:brianf@reply.infinity.nu]
> 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:ejciramella@upromise.com]
> 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 = [org.apache.maven.model.Resource@b4be3d,
> org.apache.maven.model.Resource@257f1b]
>
> 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:brianf@reply.infinity.nu]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Copy:unpack
Posted by EJ Ciramella <ej...@upromise.com>.
This plugin should either be altered to process other files OR be
renamed to "velocity-file-processor".
It's very confusing and in this case a massive time sink, trying to
learn the particulars of a plugin that in the end didn't suit our
purposes.
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
Sent: Sunday, March 16, 2008 1:10 PM
To: users@maven.apache.org
Cc: EJ Ciramella
Subject: Re: Copy:unpack
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:dkulp@apache.org]
> 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:brianf@reply.infinity.nu]
> > 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:ejciramella@upromise.com]
> > 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 = [org.apache.maven.model.Resource@b4be3d,
> > org.apache.maven.model.Resource@257f1b]
> >
> > 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:brianf@reply.infinity.nu]
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Copy:unpack
Posted by Daniel Kulp <dk...@apache.org>.
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:dkulp@apache.org]
> 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:brianf@reply.infinity.nu]
> > 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:ejciramella@upromise.com]
> > 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 = [org.apache.maven.model.Resource@b4be3d,
> > org.apache.maven.model.Resource@257f1b]
> >
> > 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:brianf@reply.infinity.nu]
> > 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: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > --------------------------------------------------------------------
> >- To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Copy:unpack
Posted by EJ Ciramella <ej...@upromise.com>.
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).
3 - process a list of files on the way out.
-----Original Message-----
From: Daniel Kulp [mailto:dkulp@apache.org]
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:brianf@reply.infinity.nu]
> 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:ejciramella@upromise.com]
> 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 = [org.apache.maven.model.Resource@b4be3d,
> org.apache.maven.model.Resource@257f1b]
>
> 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:brianf@reply.infinity.nu]
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
--
J. Daniel Kulp
Principal Engineer, IONA
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org