Daniel Kulp wrote:
Personally, I was thinking of just doing $$ -> $.
Yah, that's already in place for plugin parameters.
Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.
Yup.
My original idea was to use both by default but allow them to be configurable,
so you could use @foo@ for filtering and leave ${foo} alone or vice versa.
Doesn't cover the case where you want both @foo@ and ${foo} to be left
alone, but @bar@ and ${bar} interpolated, though.
So:
$${foo} -> ${foo}
${foo} -> value_of_foo
@@ -> @@ (or @?)
@@foo@ -> @foo@ (or @@foo@@ -> @foo@ ?)
@foo@ -> value_of_foo
@foo@@ -> value_of_foo@, or @foo@, or @foo@@ ?
Maybe it's better if we leave the @foo@ interpretation as-is. ;)
-- Kenney
Dan
On Tuesday 10 July 2007 12:05, John Casey wrote:
Yeah, escaping makes more sense to me, too. IMO it's a bit of a duct-
tape solution to say this is only applicable in {archetype,
appserver, other-limited-effect-plugins...} when those are the
examples given... People can use filtering for just about anything,
and they may use the '${...}' format for their own expression
handling, which has nothing to do with Maven at all.
The question is: what escape sequence/character is safe to use?
-john
On Jul 10, 2007, at 9:17 AM, Andrew Williams wrote:
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]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
