You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/08/24 08:17:07 UTC

[M2] Proposal for filtering of resources

In my opinion the current configuration of resources wrt filtering is a
little bit too complicated and not as user friendly as it could be :)
I think the most natural way is to configure the filters directly on the
resources. This allows to easily configure different resource sets with
different filtering behaviour:

<!-- XML Files filtered -->
<resource>
  <directory>src/resources</directory>
  <includes>
    <include>**/*.xml</include>
    <exclude>**/description.xml</exclude>
  </includes>
  <filtering>true</filtering>
 <filteringPropertiesFile>myfilters.properties</filteringPropertiesFile>
</resource>
<!-- XML description files are filtered differently -->
<resource>
  <directory>src/resources</directory>
  <includes>
    <include>**/description.xml</include>
  </includes>
  <filtering>true</filtering>
 <filteringPropertiesFile>descfilter.properties</filteringPropertiesFile>
</resource>
<!-- Binary stuff, not filtered: -->
<resource>
  <directory>src/resources</directory>
  <includes>
    <excludes>**/*.xml</excludes>
  </includes>
</resource>

WDYT?

Attached is a patch that should provide this feature - but I don't have
tested it yet and I'm not sure if the properties file is resolved in the
correct location. But it would be a start :) (At least it compiles and
the resource plugin still works the way it is today.)

-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Re: [M2] Proposal for filtering of resources

Posted by Kenney Westerhof <fo...@neonics.com>.
On Wed, 24 Aug 2005, Incze Lajos wrote:

> And what if you use something like this (in resource):
> <resource>
>   ...
>   <filtering>profile-reference</filtering>
> </resource>
>
> where the profile id references a filter specification
> along the above line augmented with an context name,
> which can be referenced. E.g.
>
>   <filtering>WAS-5.1</filtering>

That's the part you want to specify USING profiles. You don't want to
specify which profile to use in the common resource section!

Btw, it's currently possible to do this using profiles: specify the
resources plugin in each profile, each having a different properties file.

Sorry if I misunderstood! :)

-- Kenney

>
> incze
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Incze Lajos <in...@axelero.hu>.
On Wed, Aug 24, 2005 at 04:21:58PM +1000, Brett Porter wrote:
> I think this is reasonable, but I'd like to allow multiple sources
> (properties, and multiple files). The existence of the filtering element
> can be used to trigger it.
> 
> <filtering>
>   <filterTokens>
>     <token>value</token>
>   </filterTokens>
>   <filterFiles>
>     <filterFile>foo.properties</filterFile>
>     <filterFile>bar.properties</filterFile>
>   </filterFiles>
> </filtering>

And what if you use something like this (in resource):
<resource>
  ...
  <filtering>profile-reference</filtering>
</resource>

where the profile id references a filter specification
along the above line augmented with an context name,
which can be referenced. E.g.

  <filtering>WAS-5.1</filtering>

incze

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
I added an issue to JIRA for this: MNG-788. I described a slightly
different (imho better :) ) solution.

If noone objects I'll come up with a patch in the next days.

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
Kenney Westerhof wrote:

> Thinking about this, I'm not really sure anymore what the correct solution
> would be. We have the following features/demands:

I had the same feeling yesterday when I wrote the last proposal :)

> 
> 1) being able to split resources up into two groups: the filtered-on-copy
>   group and the 'just-copy' group.
> 
> 2) being able to specify different filter properties using profiles
> 
> 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.
> 
> 
> 4) being able to specify multiple properties files / having a default file
>   so users can override. Much like project.properties/build.properties
>   in maven1.
> 
> 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).
> 
> 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. ;)
> 
Hehe, now, actually the more I think about it the more I agree with your
list, meaning we don't need 3) and 5) is nice to have but not important.
I could imagine that most users would not use 5) anyway and would use
the default.

I'll start filing a JIRA entry soon with a proposal and as soon as we
agree on something there, I will try to implement it.

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Kenney Westerhof <fo...@neonics.com>.
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Kenney Westerhof <fo...@neonics.com>.
On Thu, 25 Aug 2005, Thomas Van de Velde wrote:

> I am wondering if M2 could have something like:
>
> <filtering>
> <filterTokens>
> <token>value</token>
> </filterTokens>
> <filterFiles>
> <filterFile env="foodev">foo.properties</filterFile>
> <filterFile>bar.properties</filterFile>
> </filterFiles>
> </filtering>
>
> Filters are applied in the order they are defined in the pom. Fileterfile
> foo.properties is only loaded when -Denv=foodev is passed. bar.properties is
> always loaded and overridden with what's define in the user's home
> build.properties.

Something like that, yes. But if we would use this approach, we would get
'conditional tags' scattered all over the pom in a while, and coherence is
lost. After all, you would specify -Denv=foodev solely for the resources
plugin. Other plugins could ofcourse use this property, but then you'd
specify it multiple times in the pom, losing coherence.
It's better to use a profile, so more plugins could benefit from this
'environment setting'. And the best thing is, it's already functional ;)


-- Kenney

>
> On 8/25/05, Brett Porter <br...@apache.org> wrote:
> >
> >
> > >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 :)
> > >
> > >
> > I think we're all interested, but I'd like to see the POM tags restated
> > to be sure we know where it is going. I lost it a bit in the thread.
> >
> > - Brett
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Cheers,
> Thomas
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Thomas Van de Velde <th...@gmail.com>.
I agree with Kenney on the need for environment specific filter files. I 
have used such an approach for M1 as follows:

 <goal name="filter:init"> 

<!-- Check if an environment has been passed --> 
<maven:paramCheck value="${maven.filter.env}" fail="true" message="You have 
to define a filter environment with -Dmaven.filter.env"/> 

<!-- Validate that the environment is corectly configured for filtering --> 
<u:tokenize var="envs" delim=",">${maven.filter.env.list}</u:tokenize> 
<j:forEach var="env" items="${envs}"> 
<j:if test="${context.getVariable('maven.filter.env').toString().trim().equalsIgnoreCase(env)}">

<j:set var="env.prop" value="maven.filter.env.${maven.filter.env}"/> 
<j:set var="filter.file" value="${context.getVariable(context.getVariable('
env.prop'))}"/> 
<echo>Using environment filter ${filter.file}</echo> 
</j:if> 
</j:forEach> 
<maven:paramCheck value="${filter.file}" fail="true" message="No filter file 
has been defined for this environment"/> 

</goal> 

 <goal name="filter:filter" description="Loads a hierarchy of properties for 
filtering" prereqs="filter:init"> 

 <!-- Loading global filter --> 
<j:set var="filter.src" value="build.properties"/> 
<u:available file="${filter.src}"> 
<echo>Loading filter ${filter.src}</echo> 
<ant:filter filtersfile="${filter.src}"/> 
</u:available> 

<!--Loading environment specific filter --> 
<j:set var="filter.src" value="${filter.file}"/> 
<u:available file="${filter.src}"> 
<echo>Loading filter ${filter.src}</echo> 
<ant:filter filtersfile="${filter.src}"/> 
</u:available> 

<!-- Loading user defined filter --> 
<j:set var="filter.src" value="${user.home}/build.properties"/> 
<u:available file="${filter.src}"> 
<echo>Loading filter ${filter.src}</echo> 
<ant:filter filtersfile="${filter.src}"/> 
</u:available> 

</goal>

I am wondering if M2 could have something like:

<filtering>
<filterTokens>
<token>value</token>
</filterTokens>
<filterFiles>
<filterFile env="foodev">foo.properties</filterFile>
<filterFile>bar.properties</filterFile>
</filterFiles>
</filtering>

Filters are applied in the order they are defined in the pom. Fileterfile 
foo.properties is only loaded when -Denv=foodev is passed. bar.properties is 
always loaded and overridden with what's define in the user's home 
build.properties.



On 8/25/05, Brett Porter <br...@apache.org> wrote:
> 
> 
> >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 :)
> >
> >
> I think we're all interested, but I'd like to see the POM tags restated
> to be sure we know where it is going. I lost it a bit in the thread.
> 
> - Brett
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


-- 
Cheers,
Thomas

Re: [M2] Proposal for filtering of resources

Posted by Brett Porter <br...@apache.org>.
>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 :)
>  
>
I think we're all interested, but I'd like to see the POM tags restated
to be sure we know where it is going. I lost it a bit in the thread.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Trygve Laugstøl <tr...@codehaus.org>.
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

--
Trygve

Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
>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.

Carsten

Carsten Ziegeler wrote:

> Now, what do you think of the following:
> a) the resource plugin by default uses a filters.properties file (if
> present) - we can of course use a different name/location.
> 
> b) You can specify additional property files on the resource plugin. If
> two property files contain the same property, the last one wins (or the
> first one?) You can specify for each property file if the absence of the
> file is an error. This allows to simply specify a "property.samples" and
> the "property" file and it's not an error if the "property" file is
> missing and the "property" file has precedence over the
> "property.samples" file.
> 
> c) The POM gets the filtering tags at the resource element: in this
> filtering element you can specify which tokens are replaced. In addition
> we provide a way to say: replace all tokens. This is to make it more
> user friendly.
> 
> WDYT?


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
Kenney Westerhof wrote:
> On Wed, 24 Aug 2005, Carsten Ziegeler wrote:
> 
> 
> The difference is that you only define the _tokens_ in the pom, not their
> values. This indicates which tokens are used by the resource files.
Ah, sorry, I didn't notice this detail in your previous post. Ok, now I
get it.

> 
> Specifying both key and value pairs in the pom doesn't allow for users of
> the project to specify their own values without modifying the pom itself.
True.

> You could specify a 'src/main/conf/config.properties' in the pom,
> and supply a sample file 'src/main/conf/config.properties.sample' (or even
> in the current dir) that users have copy & edit to fill in their specific
> settings (smtp servers, hostname, port, location of tomcat/j2ee containers
> etc..)
> 
> That way even in a big team each teammember should configure their
> test/build environment using the sample file (if this is needed).
> 
> I used to work on projects using this mechanism (using ant), having
> a build-dev.properties, build-live.properties, build-test.properties
> for different environments, running and with -Dbuild=dev would load
> that set of properties.
> 
> (as you can see, my main concern in specifying properties file is for use
> in different environments, not centralizing the token data per se).
> 
Ok, I see now and partially agree :) I think you have two different
kinds of property files: one for the project maintenance (or whatever
you call this) and one for user settings. The first one is not intended
to be changed by a user, it contains important settings for the project
at a central place.
Now, what do you think of the following:
a) the resource plugin by default uses a filters.properties file (if
present) - we can of course use a different name/location.

b) You can specify additional property files on the resource plugin. If
two property files contain the same property, the last one wins (or the
first one?) You can specify for each property file if the absence of the
file is an error. This allows to simply specify a "property.samples" and
the "property" file and it's not an error if the "property" file is
missing and the "property" file has precedence over the
"property.samples" file.

c) The POM gets the filtering tags at the resource element: in this
filtering element you can specify which tokens are replaced. In addition
we provide a way to say: replace all tokens. This is to make it more
user friendly.

WDYT?
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Kenney Westerhof <fo...@neonics.com>.
On Wed, 24 Aug 2005, Carsten Ziegeler wrote:


The difference is that you only define the _tokens_ in the pom, not their
values. This indicates which tokens are used by the resource files.

Specifying both key and value pairs in the pom doesn't allow for users of
the project to specify their own values without modifying the pom itself.
You could specify a 'src/main/conf/config.properties' in the pom,
and supply a sample file 'src/main/conf/config.properties.sample' (or even
in the current dir) that users have copy & edit to fill in their specific
settings (smtp servers, hostname, port, location of tomcat/j2ee containers
etc..)

That way even in a big team each teammember should configure their
test/build environment using the sample file (if this is needed).

I used to work on projects using this mechanism (using ant), having
a build-dev.properties, build-live.properties, build-test.properties
for different environments, running and with -Dbuild=dev would load
that set of properties.

(as you can see, my main concern in specifying properties file is for use
in different environments, not centralizing the token data per se).

-- Kenney

> Kenney Westerhof wrote:
> > On Wed, 24 Aug 2005, Brett Porter wrote:
> >
> >>I think this is reasonable, but I'd like to allow multiple sources
> >>(properties, and multiple files). The existence of the filtering element
> >>can be used to trigger it.
> >
> >
> > I don't think it's a good idea to specify the filter files at the
> > resource level (assuming the <filtering> below is a child element of
> > <resource>).
> Yes, the filtering is a child of the resource.
>
> > Specifying tokens however is a good idea.
> Hmm, actually, I don't see a real difference between specifying tokens
> directly or "externalizing" them into a properties file. Why do you
> think that tokens are a good idea while files not?
> >
> > I think you should be able to use different filter properties files using
> > profiles. The resources plugin can check for the presence of all tokens
> > and bail if some are missing. So:
> >
> > <resource>
> >   <filtering>
> >     <filterTokens>
> >       <token>tokenname</token>
> >       <token>anothertokenname</token>
> >     </filtertokens>
> >   </filtering>
> >    ....
> > </resource>
> >
> > Specifying the filter files themselves above is only nice if you use
> > the same token values in different resource files. However, that's not
> > the most common usecase for using filters: it's for building for different
> > environments. According to the m2 philosphy you should have different
> > projects, but it's not possible to filter resources from another project
> > (unless you use relative paths to resource dirs). So having profiles
> > with different filter files should solve this (that's what profiles
> > are for anyway).
> >
> Hmm, I agree with the profiles handling, but I think there are use cases
> where you want to use different property files for a single profile. As
> I said, using tokens directly in the pom or putting them in a properties
> file is the same thing, it's just a different location. Therefore I
> think it makes sense to directly specify property files for the
> resources in addition to possible tokens.
> But I don't insists on this, for now I'm happy if I can specify tokens
> for the filtering.
>
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
Kenney Westerhof wrote:
> On Wed, 24 Aug 2005, Brett Porter wrote:
> 
>>I think this is reasonable, but I'd like to allow multiple sources
>>(properties, and multiple files). The existence of the filtering element
>>can be used to trigger it.
> 
> 
> I don't think it's a good idea to specify the filter files at the
> resource level (assuming the <filtering> below is a child element of
> <resource>).
Yes, the filtering is a child of the resource.

> Specifying tokens however is a good idea.
Hmm, actually, I don't see a real difference between specifying tokens
directly or "externalizing" them into a properties file. Why do you
think that tokens are a good idea while files not?
> 
> I think you should be able to use different filter properties files using
> profiles. The resources plugin can check for the presence of all tokens
> and bail if some are missing. So:
> 
> <resource>
>   <filtering>
>     <filterTokens>
>       <token>tokenname</token>
>       <token>anothertokenname</token>
>     </filtertokens>
>   </filtering>
>    ....
> </resource>
> 
> Specifying the filter files themselves above is only nice if you use
> the same token values in different resource files. However, that's not
> the most common usecase for using filters: it's for building for different
> environments. According to the m2 philosphy you should have different
> projects, but it's not possible to filter resources from another project
> (unless you use relative paths to resource dirs). So having profiles
> with different filter files should solve this (that's what profiles
> are for anyway).
> 
Hmm, I agree with the profiles handling, but I think there are use cases
where you want to use different property files for a single profile. As
I said, using tokens directly in the pom or putting them in a properties
file is the same thing, it's just a different location. Therefore I
think it makes sense to directly specify property files for the
resources in addition to possible tokens.
But I don't insists on this, for now I'm happy if I can specify tokens
for the filtering.

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Kenney Westerhof <fo...@neonics.com>.
On Wed, 24 Aug 2005, Brett Porter wrote:

> I think this is reasonable, but I'd like to allow multiple sources
> (properties, and multiple files). The existence of the filtering element
> can be used to trigger it.

I don't think it's a good idea to specify the filter files at the
resource level (assuming the <filtering> below is a child element of
<resource>). Specifying tokens however is a good idea.

I think you should be able to use different filter properties files using
profiles. The resources plugin can check for the presence of all tokens
and bail if some are missing. So:

<resource>
  <filtering>
    <filterTokens>
      <token>tokenname</token>
      <token>anothertokenname</token>
    </filtertokens>
  </filtering>
   ....
</resource>

Specifying the filter files themselves above is only nice if you use
the same token values in different resource files. However, that's not
the most common usecase for using filters: it's for building for different
environments. According to the m2 philosphy you should have different
projects, but it's not possible to filter resources from another project
(unless you use relative paths to resource dirs). So having profiles
with different filter files should solve this (that's what profiles
are for anyway).

That leaves one thing open: where to specify the filter filenames?
I suggest we supply it in the maven-resources-plugin configuration.

WDYT?

-- Kenney

 >
> <filtering>
>   <filterTokens>
>     <token>value</token>
>   </filterTokens>
>   <filterFiles>
>     <filterFile>foo.properties</filterFile>
>     <filterFile>bar.properties</filterFile>
>   </filterFiles>
> </filtering>
>
> Dowside is that for a single file it is quite verbose.
>
> Any other suggestions? Any problems with having filtering here in the
> first place?
>
> - Brett
>
> Carsten Ziegeler wrote:
>
> >In my opinion the current configuration of resources wrt filtering is a
> >little bit too complicated and not as user friendly as it could be :)
> >I think the most natural way is to configure the filters directly on the
> >resources. This allows to easily configure different resource sets with
> >different filtering behaviour:
> >
> ><!-- XML Files filtered -->
> ><resource>
> >  <directory>src/resources</directory>
> >  <includes>
> >    <include>**/*.xml</include>
> >    <exclude>**/description.xml</exclude>
> >  </includes>
> >  <filtering>true</filtering>
> > <filteringPropertiesFile>myfilters.properties</filteringPropertiesFile>
> ></resource>
> ><!-- XML description files are filtered differently -->
> ><resource>
> >  <directory>src/resources</directory>
> >  <includes>
> >    <include>**/description.xml</include>
> >  </includes>
> >  <filtering>true</filtering>
> > <filteringPropertiesFile>descfilter.properties</filteringPropertiesFile>
> ></resource>
> ><!-- Binary stuff, not filtered: -->
> ><resource>
> >  <directory>src/resources</directory>
> >  <includes>
> >    <excludes>**/*.xml</excludes>
> >  </includes>
> ></resource>
> >
> >WDYT?
> >
> >Attached is a patch that should provide this feature - but I don't have
> >tested it yet and I'm not sure if the properties file is resolved in the
> >correct location. But it would be a start :) (At least it compiles and
> >the resource plugin still works the way it is today.)
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >Index: D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java
> >===================================================================
> >--- D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java	(revision 239437)
> >+++ D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java	(working copy)
> >@@ -97,7 +97,7 @@
> >     public void execute()
> >         throws MojoExecutionException
> >     {
> >-        initializeFiltering();
> >+        filterProperties = initializeFiltering(filtering, filterPropertiesFile);
> >         copyResources( resources, outputDirectory );
> >     }
> >
> >@@ -110,7 +110,8 @@
> >             {
> >                 Map.Entry entry = (Map.Entry) i.next();
> >                 File source = (File) entry.getKey();
> >-                String destination = (String) entry.getValue();
> >+                CopyDescription description = (CopyDescription)entry.getValue();
> >+                String destination = description.destination;
> >
> >                 File destinationFile = new File( outputDirectory, destination );
> >
> >@@ -119,7 +120,7 @@
> >                     destinationFile.getParentFile().mkdirs();
> >                 }
> >
> >-                copyFile( source, destinationFile );
> >+                copyFile( source, destinationFile, description );
> >             }
> >         }
> >         catch ( Exception e )
> >@@ -165,6 +166,8 @@
> >
> >             scanner.scan();
> >
> >+            ResourceFilter filter = new ResourceFilter();
> >+            filter.resource = resource;
> >             List includedFiles = Arrays.asList( scanner.getIncludedFiles() );
> >             for ( Iterator j = includedFiles.iterator(); j.hasNext(); )
> >             {
> >@@ -177,48 +180,68 @@
> >                     entryName = targetPath + "/" + name;
> >                 }
> >
> >-                resourceEntries.put( new File( resource.getDirectory(), name ), entryName );
> >+                resourceEntries.put( new File( resource.getDirectory(), name ), new CopyDescription(entryName, filter) );
> >             }
> >         }
> >
> >         return resourceEntries;
> >     }
> >
> >-    private void initializeFiltering()
> >+    private Properties initializeFiltering(boolean doFiltering, File propertiesFile)
> >         throws MojoExecutionException
> >     {
> >-        if ( filtering )
> >+        if ( doFiltering )
> >         {
> >             try
> >             {
> >-                filterProperties = PropertyUtils.loadPropertyFile( filterPropertiesFile, true, true );
> >+                return PropertyUtils.loadPropertyFile( propertiesFile, true, true );
> >             }
> >             catch ( IOException e )
> >             {
> >                 throw new MojoExecutionException( "Error loading property file '" + filterPropertiesFile + "'", e );
> >             }
> >         }
> >+        return null;
> >     }
> >
> >-    private void copyFile( File from, File to )
> >-        throws IOException
> >+    private void copyFile( File from, File to, CopyDescription desc )
> >+        throws IOException, MojoExecutionException
> >     {
> >-        if ( !filtering )
> >+        boolean doFiltering = filtering || desc.filter.resource.isFiltering();
> >+        if ( !doFiltering )
> >         {
> >             FileUtils.copyFile( from, to );
> >         }
> >         else
> >         {
> >+            // first initialize properties for this resource
> >+            if ( desc.filter.properties == null )
> >+            {
> >+                if ( filterPropertiesFile != null && filterProperties == null )
> >+                {
> >+                    filterProperties = initializeFiltering( true, filterPropertiesFile );
> >+                }
> >+                if ( desc.filter.resource.getFilterPropertiesFile() != null )
> >+                {
> >+                    Properties resourceProps = initializeFiltering( true, new File(desc.filter.resource.getFilterPropertiesFile()) );
> >+                    resourceProps.putAll(filterProperties);
> >+                    desc.filter.properties = resourceProps;
> >+                }
> >+                else
> >+                {
> >+                    desc.filter.properties = filterProperties;
> >+                }
> >+            }
> >             // buffer so it isn't reading a byte at a time!
> >             Reader fileReader = new BufferedReader( new FileReader( from ) );
> >             Writer fileWriter = null;
> >             try
> >             {
> >                 // support ${token}
> >-                Reader reader = new InterpolationFilterReader( fileReader, filterProperties, "${", "}" );
> >+                Reader reader = new InterpolationFilterReader( fileReader, desc.filter.properties, "${", "}" );
> >
> >                 // support @token@
> >-                reader = new InterpolationFilterReader( reader, filterProperties, "@", "@" );
> >+                reader = new InterpolationFilterReader( reader, desc.filter.properties, "@", "@" );
> >
> >                 reader = new InterpolationFilterReader( reader, new ReflectionProperties( project ), "${", "}" );
> >
> >@@ -233,4 +256,17 @@
> >             }
> >         }
> >     }
> >+
> >+    static protected final class CopyDescription {
> >+        public CopyDescription(String dest, ResourceFilter f) {
> >+            this.destination = dest;
> >+            this.filter = f;
> >+        }
> >+        public String destination;
> >+        public ResourceFilter filter;
> >+    }
> >+    static protected final class ResourceFilter {
> >+        public Resource resource;
> >+        public Properties properties;
> >+    }
> > }
> >Index: D:/dev/workspace/maven-components/maven-model/maven.mdo
> >===================================================================
> >--- D:/dev/workspace/maven-components/maven-model/maven.mdo	(revision 239437)
> >+++ D:/dev/workspace/maven-components/maven-model/maven.mdo	(working copy)
> >@@ -1932,11 +1932,19 @@
> >         </field>
> >         <field>
> >           <name>filtering</name>
> >-          <version>3.0.0</version>
> >+          <version>3.0.0+</version>
> >           <description><![CDATA[Boolean. Describe if resources are filtered or not.]]></description>
> >           <type>boolean</type>
> >           <defaultValue>false</defaultValue>
> >         </field>
> >+        <field>
> >+          <name>filterPropertiesFile</name>
> >+          <version>4.0.0</version>
> >+          <description><![CDATA[
> >+            The filename for a properties file containing filters to be applied if filtering is turned on.
> >+          ]]></description>
> >+          <type>String</type>
> >+        </field>
> >       </fields>
> >     </class>
> >     <class>
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Carsten Ziegeler <cz...@apache.org>.
Brett Porter wrote:
> I think this is reasonable, but I'd like to allow multiple sources
> (properties, and multiple files). The existence of the filtering element
> can be used to trigger it.
> 
> <filtering>
>   <filterTokens>
>     <token>value</token>
>   </filterTokens>
>   <filterFiles>
>     <filterFile>foo.properties</filterFile>
>     <filterFile>bar.properties</filterFile>
>   </filterFiles>
> </filtering>
> 
> Dowside is that for a single file it is quite verbose.
> 
Yeah, I thought of this, too and I think it makes absolutely sense.
So, +1 :)

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: [M2] Proposal for filtering of resources

Posted by Brett Porter <br...@apache.org>.
I think this is reasonable, but I'd like to allow multiple sources
(properties, and multiple files). The existence of the filtering element
can be used to trigger it.

<filtering>
  <filterTokens>
    <token>value</token>
  </filterTokens>
  <filterFiles>
    <filterFile>foo.properties</filterFile>
    <filterFile>bar.properties</filterFile>
  </filterFiles>
</filtering>

Dowside is that for a single file it is quite verbose.

Any other suggestions? Any problems with having filtering here in the
first place?

- Brett

Carsten Ziegeler wrote:

>In my opinion the current configuration of resources wrt filtering is a
>little bit too complicated and not as user friendly as it could be :)
>I think the most natural way is to configure the filters directly on the
>resources. This allows to easily configure different resource sets with
>different filtering behaviour:
>
><!-- XML Files filtered -->
><resource>
>  <directory>src/resources</directory>
>  <includes>
>    <include>**/*.xml</include>
>    <exclude>**/description.xml</exclude>
>  </includes>
>  <filtering>true</filtering>
> <filteringPropertiesFile>myfilters.properties</filteringPropertiesFile>
></resource>
><!-- XML description files are filtered differently -->
><resource>
>  <directory>src/resources</directory>
>  <includes>
>    <include>**/description.xml</include>
>  </includes>
>  <filtering>true</filtering>
> <filteringPropertiesFile>descfilter.properties</filteringPropertiesFile>
></resource>
><!-- Binary stuff, not filtered: -->
><resource>
>  <directory>src/resources</directory>
>  <includes>
>    <excludes>**/*.xml</excludes>
>  </includes>
></resource>
>
>WDYT?
>
>Attached is a patch that should provide this feature - but I don't have
>tested it yet and I'm not sure if the properties file is resolved in the
>correct location. But it would be a start :) (At least it compiles and
>the resource plugin still works the way it is today.)
>
>  
>
>------------------------------------------------------------------------
>
>Index: D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java
>===================================================================
>--- D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java	(revision 239437)
>+++ D:/dev/workspace/maven-components/maven-plugins/maven-resources-plugin/src/main/java/org/apache/maven/plugin/resources/ResourcesMojo.java	(working copy)
>@@ -97,7 +97,7 @@
>     public void execute()
>         throws MojoExecutionException
>     {
>-        initializeFiltering();
>+        filterProperties = initializeFiltering(filtering, filterPropertiesFile);
>         copyResources( resources, outputDirectory );
>     }
> 
>@@ -110,7 +110,8 @@
>             {
>                 Map.Entry entry = (Map.Entry) i.next();
>                 File source = (File) entry.getKey();
>-                String destination = (String) entry.getValue();
>+                CopyDescription description = (CopyDescription)entry.getValue();
>+                String destination = description.destination;
> 
>                 File destinationFile = new File( outputDirectory, destination );
> 
>@@ -119,7 +120,7 @@
>                     destinationFile.getParentFile().mkdirs();
>                 }
> 
>-                copyFile( source, destinationFile );
>+                copyFile( source, destinationFile, description );
>             }
>         }
>         catch ( Exception e )
>@@ -165,6 +166,8 @@
> 
>             scanner.scan();
> 
>+            ResourceFilter filter = new ResourceFilter();
>+            filter.resource = resource;
>             List includedFiles = Arrays.asList( scanner.getIncludedFiles() );
>             for ( Iterator j = includedFiles.iterator(); j.hasNext(); )
>             {
>@@ -177,48 +180,68 @@
>                     entryName = targetPath + "/" + name;
>                 }
> 
>-                resourceEntries.put( new File( resource.getDirectory(), name ), entryName );
>+                resourceEntries.put( new File( resource.getDirectory(), name ), new CopyDescription(entryName, filter) );
>             }
>         }
> 
>         return resourceEntries;
>     }
> 
>-    private void initializeFiltering()
>+    private Properties initializeFiltering(boolean doFiltering, File propertiesFile)
>         throws MojoExecutionException
>     {
>-        if ( filtering )
>+        if ( doFiltering )
>         {
>             try
>             {
>-                filterProperties = PropertyUtils.loadPropertyFile( filterPropertiesFile, true, true );
>+                return PropertyUtils.loadPropertyFile( propertiesFile, true, true );
>             }
>             catch ( IOException e )
>             {
>                 throw new MojoExecutionException( "Error loading property file '" + filterPropertiesFile + "'", e );
>             }
>         }
>+        return null;
>     }
> 
>-    private void copyFile( File from, File to )
>-        throws IOException
>+    private void copyFile( File from, File to, CopyDescription desc )
>+        throws IOException, MojoExecutionException
>     {
>-        if ( !filtering )
>+        boolean doFiltering = filtering || desc.filter.resource.isFiltering();
>+        if ( !doFiltering )
>         {
>             FileUtils.copyFile( from, to );
>         }
>         else
>         {
>+            // first initialize properties for this resource
>+            if ( desc.filter.properties == null ) 
>+            {
>+                if ( filterPropertiesFile != null && filterProperties == null )
>+                {
>+                    filterProperties = initializeFiltering( true, filterPropertiesFile );
>+                }
>+                if ( desc.filter.resource.getFilterPropertiesFile() != null )
>+                {
>+                    Properties resourceProps = initializeFiltering( true, new File(desc.filter.resource.getFilterPropertiesFile()) );
>+                    resourceProps.putAll(filterProperties);
>+                    desc.filter.properties = resourceProps;
>+                }
>+                else
>+                {
>+                    desc.filter.properties = filterProperties;
>+                }
>+            }
>             // buffer so it isn't reading a byte at a time!
>             Reader fileReader = new BufferedReader( new FileReader( from ) );
>             Writer fileWriter = null;
>             try
>             {
>                 // support ${token}
>-                Reader reader = new InterpolationFilterReader( fileReader, filterProperties, "${", "}" );
>+                Reader reader = new InterpolationFilterReader( fileReader, desc.filter.properties, "${", "}" );
> 
>                 // support @token@
>-                reader = new InterpolationFilterReader( reader, filterProperties, "@", "@" );
>+                reader = new InterpolationFilterReader( reader, desc.filter.properties, "@", "@" );
> 
>                 reader = new InterpolationFilterReader( reader, new ReflectionProperties( project ), "${", "}" );
> 
>@@ -233,4 +256,17 @@
>             }
>         }
>     }
>+
>+    static protected final class CopyDescription {
>+        public CopyDescription(String dest, ResourceFilter f) {
>+            this.destination = dest;
>+            this.filter = f;
>+        }
>+        public String destination;
>+        public ResourceFilter filter;
>+    }
>+    static protected final class ResourceFilter {
>+        public Resource resource;
>+        public Properties properties;
>+    }
> }
>Index: D:/dev/workspace/maven-components/maven-model/maven.mdo
>===================================================================
>--- D:/dev/workspace/maven-components/maven-model/maven.mdo	(revision 239437)
>+++ D:/dev/workspace/maven-components/maven-model/maven.mdo	(working copy)
>@@ -1932,11 +1932,19 @@
>         </field>
>         <field>
>           <name>filtering</name>
>-          <version>3.0.0</version>
>+          <version>3.0.0+</version>
>           <description><![CDATA[Boolean. Describe if resources are filtered or not.]]></description>
>           <type>boolean</type>
>           <defaultValue>false</defaultValue>
>         </field>
>+        <field>
>+          <name>filterPropertiesFile</name>
>+          <version>4.0.0</version>
>+          <description><![CDATA[
>+            The filename for a properties file containing filters to be applied if filtering is turned on.
>+          ]]></description>
>+          <type>String</type>
>+        </field>
>       </fields>
>     </class>
>     <class>
>
>  
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org