On Thu, 25 Aug 2005, Carsten Ziegeler wrote:
There sure is.
I suggest you create a JIRA issue for this, and describe the final
solution there so we have a central place for the design.
Also you can attach the patches you make there.
Some comments:
> c) The POM gets the filtering tags at the resource element:
Ok.
> in this filtering element you can specify which tokens are replaced.
subtle change: which tokens have to be defined in the property files. ?
> In addition we provide a way to say: replace all tokens.
> This is to make it more user friendly.
Replace all seems like a default to me..
Thinking about this, I'm not really sure anymore what the correct solution
would be. We have the following features/demands:
1) being able to split resources up into two groups: the filtered-on-copy
group and the 'just-copy' group.
This requires a change in the pom, just a boolean indicating
wheter to filter or not. <filtering>true</fitlering> as a child
to <resources>. (read on before commenting!)
2) being able to specify different filter properties using profiles
This is already possible: specify a different config for the
resources plugin in multiple profiles. Could' even include
settings.xml profiles for that, where some common properties
like j2ee environment are defined as <properties>.
3) (?) being able to split filtered resources up into more groups (not
just the one group as said in 1), so each group can have a different filter
property files.
I'm not sure wheter we need this. Anyone got a usecase for
this? (so: 2 resource dirs/files, with overlapping token names,
and 2 different property files with values for those tokens).
Seems to me this is only needed if 2 resource files use the same
tokenname but the value should be different.
Requires change to the pom: specifying an 'id' for a <resource>
section (or is it already in there?), and:
a change to the resources-plugin, where you can specify filter
files for each resource set.
4) being able to specify multiple properties files / having a default file
so users can override. Much like project.properties/build.properties
in maven1.
Could be useful for splitting up settings over multiple files,
to keep a better overview, or to allow users to override
default settings.
Requires a change in the maven-resources-plugin: adding a
File [] parameter or something more complicated to specify
override/inheritance. Could also be done by specifying
a special token in the property file itself, like
maven.resources.tokens.inheritfrom=propertyfile, but that's
ugly++.
5) Nice to have: defining the tokens in the pom so the plugin
could check which ones are missing and you have an overview of
all the configuration settings used in all the resource files
(the latter being more important).
Ofcourse, all the resource file could be scanned for token names..
and the plugin can always barf when it encounters null for a token
value.
Requires modification to the pom.
More ideas? Comments?
I think it's best to go back after a while, look at
what you originally _needed_ in the first place, and then fill in the
blanks with solutions. ;)
-- Kenney
> Trygve Laugst�l wrote:
> > On Thu, Aug 25, 2005 at 03:18:45PM +0200, Carsten Ziegeler wrote:
> >
> >>From the plan below, I'm able to address a) and b), but currently I
> >>don't know how to enhance the POM (Item c)). So if anyone could
> >>implement c) I'm willing to provide a patch for the resource plugin.
> >
> >
> > You can change the POM model in maven-model/maven.mdo
> >
> Yes, I know - but I'm not sure how to add a nested structure to it, but
> perhaps I can figure it out somehow...
>
> But before I start working on a patch, I would like to know if there is
> general interest in it. I don't want to work for the trashcan :)
>
> Carsten
>
> --
> Carsten Ziegeler - Open Source Group, S&N AG
> http://www.s-und-n.de
> http://www.osoco.org/weblogs/rael/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
