Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
After battling with the braindead resource filtering once again for
the ump-teenth time, I've decided I need to do something about
it....
You dissin' my code huh? :)
The main thing I'd like to do is allow use of a better filter engine
(like velocity) that would provide much more flexibility. The
issue is how to do it without breaking all the existing builds that
are out there. Here are my thoughts....
I'd very much like to know what the problems are. Probably the fact
that escaping is missing?
Yep. That's the #1 issue. I've completely given up on trying to get
the string "${pom.version}" outputted into the file.
Ok, but why are you filtering a file with that in there? Do you need filtering
at all, or do you only want some things filtered?
You can exclude specific files from filtering; doesn't that solve your problem?
Maybe just adding escaping to interpolationfilterreader is much simpler
than all of this, wdyt?
The other thing I'd like to do is conditional filtering based on whether
the version is a SNAPSHOT or not. Kind of like: (pseudocode, not sure
on the velocity syntax)
#if ${pom.version}.indexOf("SNAPSHOT") != -1
version.message=Version ${pom.version} - Use at your own risk.
#else
version.message=Version ${pom.version}
#fi
Why would you want that? :)
-- Kenney
2) The next option would be to add a filterType configuration
property onto the resources plugin itself. You would need to
configure the plugin to use it. Also, it would apply to all
resources with filtering=true. We could combine this with (1) and
instead of making "simple" the default if not specified in the
resource, whatever this option is set to is the default.
This is a better option. the plugin can be configured with resource
sets, which are just initialized from the pom itself.
perhaps 'src/main/velocity/' could be checked by default and
velocity-copied.
The problem is the "Resource" object that the resources plugin uses is
maven-model defined. Not something that's extensible as that requires
a schema change. I suppose what COULD work well is to add:
velocityResources = List<Resource>
configuration to the resources plugin (and if list is empty, look for the
default of src/main/velocity) and use that. In that case, "regular"
resources can be configured just in build/resources and
build/testResources, but the velocity based ones would need a full
plugin configuration. A bit inconsistent, but acceptable.
After thinking about this a bit more, I wonder if it makes more sense to
just create a "maven-velocity-plugin" and ignore resources all-together?
That would be super quick to write. (I'd still like to see the
escaping issue fixed. :-) We already have the plexus
VelocityComponent. Would take very little work to wire it into a
plugin.
Anyway, what are peoples thoughts on this? Any other options?
What direction do people feel is the best way to proceed? I
personally would like to go with Option #1 and require Maven 2.0.8
if you want to use the advanced filtering, but I know some people
are totally against schema changes.
Well, if there's a good reason to change the schema then I'm all for
it. Maybe we should just add <properties> again to dependencies and
resource sets, so the resource plugin can look at the resourceset
property 'filterType' or something, if it's set.
Either way, changes to the model won't happen until 2.1.
So, what's the problem with the filtering?
Getting any of the normal pom properties outputted to the target file
seems to be impossible.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
