Personally, I was thinking of just doing $$ -> $.
Thus, if you want ${pom.version} outputted, it would be $${pom.version}.
I think @@ also needs to be done.
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
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
[EMAIL PROTECTED]
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
