It's not just archetype - this has come up in appserver too, where
you need some properties in a file escaped and others left.
I suspect adding escape handling to the InterpolationFilterReader
might be a good way to go.
Andy
On 10 Jul 2007, at 11:35, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 19:08, Kenney Westerhof wrote:
Daniel Kulp wrote:
On Monday 09 July 2007 14:42, Kenney Westerhof wrote:
Daniel Kulp wrote:
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?
It has to do with creating an archtype. The pom.xml that we want
the archtype to create needs to have certain versions pushed in,
but other things in the pom should be left as is (or allow us to
escape it).
The other thing we want to do is push some values INTO a resource
that eventually is a velocity template. (actually, that's what an
archtype is anyway). For those, we need the ability to not have
some thing substituted in.
Ok, so it's archetype stuff. Well, the archetype resources
should be velocity templates anyway, and processed with velocity.
It should -not- use filtering, just pure velocity. Then you can use
the velocity escaping mechanisms to leave certain expressions
untouched.
So for the short run I think updating archetype itself is the safest..
Maybe just adding escaping to interpolationfilterreader is much
simpler than all of this, wdyt?
Probably yes, but would you consider that backwords compatible?
I have no problems with going that route if people don't think it
would seriously impact people.
Depends on how we'll be escaping I guess..
-- Kenney
Dan
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]
---------------------------------------------------------------------
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]
