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.
> 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.
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]
--
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]
