Re: [M2] Proposal for filtering of resources
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, SN 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]
Re: [M2] Proposal for filtering of resources
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, SN 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]
Re: [M2] Proposal for filtering of resources
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 signature.asc Description: Digital signature
Re: [M2] Proposal for filtering of resources
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, SN 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]
Re: [M2] Proposal for filtering of resources
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
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. filteringtrue/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, SN 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]
Re: [M2] Proposal for filtering of resources
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, SN 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]
Re: [M2] Proposal for filtering of resources
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'))}/
echoUsing 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}
echoLoading 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}
echoLoading 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}
echoLoading filter ${filter.src}/echo
ant:filter filtersfile=${filter.src}/
/u:available
/goal
I am wondering if M2 could have something like:
filtering
filterTokens
tokenvalue/token
/filterTokens
filterFiles
filterFile env=foodevfoo.properties/filterFile
filterFilebar.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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Cheers,
Thomas
Re: [M2] Proposal for filtering of resources
On Thu, 25 Aug 2005, Thomas Van de Velde wrote: I am wondering if M2 could have something like: filtering filterTokens tokenvalue/token /filterTokens filterFiles filterFile env=foodevfoo.properties/filterFile filterFilebar.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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Cheers, Thomas -- 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]
[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
directorysrc/resources/directory
includes
include**/*.xml/include
exclude**/description.xml/exclude
/includes
filteringtrue/filtering
filteringPropertiesFilemyfilters.properties/filteringPropertiesFile
/resource
!-- XML description files are filtered differently --
resource
directorysrc/resources/directory
includes
include**/description.xml/include
/includes
filteringtrue/filtering
filteringPropertiesFiledescfilter.properties/filteringPropertiesFile
/resource
!-- Binary stuff, not filtered: --
resource
directorysrc/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, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
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 )
+{
+
Re: [M2] Proposal for filtering of resources
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
tokenvalue/token
/filterTokens
filterFiles
filterFilefoo.properties/filterFile
filterFilebar.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
directorysrc/resources/directory
includes
include**/*.xml/include
exclude**/description.xml/exclude
/includes
filteringtrue/filtering
filteringPropertiesFilemyfilters.properties/filteringPropertiesFile
/resource
!-- XML description files are filtered differently --
resource
directorysrc/resources/directory
includes
include**/description.xml/include
/includes
filteringtrue/filtering
filteringPropertiesFiledescfilter.properties/filteringPropertiesFile
/resource
!-- Binary stuff, not filtered: --
resource
directorysrc/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,
Re: [M2] Proposal for filtering of resources
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 tokenvalue/token /filterTokens filterFiles filterFilefoo.properties/filterFile filterFilebar.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, SN 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]
Re: [M2] Proposal for filtering of resources
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
tokentokenname/token
tokenanothertokenname/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
tokenvalue/token
/filterTokens
filterFiles
filterFilefoo.properties/filterFile
filterFilebar.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
directorysrc/resources/directory
includes
include**/*.xml/include
exclude**/description.xml/exclude
/includes
filteringtrue/filtering
filteringPropertiesFilemyfilters.properties/filteringPropertiesFile
/resource
!-- XML description files are filtered differently --
resource
directorysrc/resources/directory
includes
include**/description.xml/include
/includes
filteringtrue/filtering
filteringPropertiesFiledescfilter.properties/filteringPropertiesFile
/resource
!-- Binary stuff, not filtered: --
resource
directorysrc/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
Re: [M2] Proposal for filtering of resources
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 tokentokenname/token tokenanothertokenname/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, SN 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]
Re: [M2] Proposal for filtering of resources
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 tokentokenname/token tokenanothertokenname/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, SN 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]
Re: [M2] Proposal for filtering of resources
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, SN 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]
Re: [M2] Proposal for filtering of resources
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 tokenvalue/token /filterTokens filterFiles filterFilefoo.properties/filterFile filterFilebar.properties/filterFile /filterFiles /filtering And what if you use something like this (in resource): resource ... filteringprofile-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. filteringWAS-5.1/filtering incze - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Proposal for filtering of resources
On Wed, 24 Aug 2005, Incze Lajos wrote: And what if you use something like this (in resource): resource ... filteringprofile-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. filteringWAS-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: [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]
