[ http://jira.codehaus.org/browse/MAVEN-514?page=all ]

Brett Porter updated MAVEN-514:
-------------------------------

    Fix Version: 1.1-beta-1
    Environment: 
    Description: 
Something discussed on the dev/user lists recently, and an initial 
implementation is in place. Here is my proposal from the list:

I would like to propose a generic solution via the POM and whatever 
filter-enabled copying technique that is being used. Let me know what you think.

Firstly, inside <build>:
<filters>
  <file>${basedir}/conf/${maven.username}.properties</file>
  <file>${basedir}/conf/filters.properties</file>
  <file>${basedir}/../common/filters.properties</file>
  <filter>
    <token>some.property</token>
    <value>some.value</value>
  </filter>
</filters>

Or to go really crazy, have the above as a filterset, and wrap them up in a 
list of filtersets. Ant introduced this functionality, but personally I don't 
see the use for it as long as you keep your property names a little different.

I also think build.properties, project.properties and driver/default.properties 
should be included by default when filtering is enabled.

Now, each <resource/> element can keep the <filtering>true</filtering> property 
to acknowledge it wants to be filtered.

The reason to allow different files is that the purpose of filters is to be 
able to substitute varying values, so you may not want to hard code them into 
project.xml. And this configuration should be flexible enough to work without 
Ant if necessary.

----


I'm happy to work on this once there is agreement - just opening this to track 
its progress.

  was:
Something discussed on the dev/user lists recently, and an initial 
implementation is in place. Here is my proposal from the list:

I would like to propose a generic solution via the POM and whatever 
filter-enabled copying technique that is being used. Let me know what you think.

Firstly, inside <build>:
<filters>
  <file>${basedir}/conf/${maven.username}.properties</file>
  <file>${basedir}/conf/filters.properties</file>
  <file>${basedir}/../common/filters.properties</file>
  <filter>
    <token>some.property</token>
    <value>some.value</value>
  </filter>
</filters>

Or to go really crazy, have the above as a filterset, and wrap them up in a 
list of filtersets. Ant introduced this functionality, but personally I don't 
see the use for it as long as you keep your property names a little different.

I also think build.properties, project.properties and driver/default.properties 
should be included by default when filtering is enabled.

Now, each <resource/> element can keep the <filtering>true</filtering> property 
to acknowledge it wants to be filtered.

The reason to allow different files is that the purpose of filters is to be 
able to substitute varying values, so you may not want to hard code them into 
project.xml. And this configuration should be flexible enough to work without 
Ant if necessary.

----


I'm happy to work on this once there is agreement - just opening this to track 
its progress.


> enhance resource filtering
> --------------------------
>
>          Key: MAVEN-514
>          URL: http://jira.codehaus.org/browse/MAVEN-514
>      Project: maven
>         Type: New Feature
>   Components: model additions
>     Reporter: Brett Porter
>     Assignee: Brett Porter
>      Fix For: 1.1-beta-1

>
>
> Something discussed on the dev/user lists recently, and an initial 
> implementation is in place. Here is my proposal from the list:
> I would like to propose a generic solution via the POM and whatever 
> filter-enabled copying technique that is being used. Let me know what you 
> think.
> Firstly, inside <build>:
> <filters>
>   <file>${basedir}/conf/${maven.username}.properties</file>
>   <file>${basedir}/conf/filters.properties</file>
>   <file>${basedir}/../common/filters.properties</file>
>   <filter>
>     <token>some.property</token>
>     <value>some.value</value>
>   </filter>
> </filters>
> Or to go really crazy, have the above as a filterset, and wrap them up in a 
> list of filtersets. Ant introduced this functionality, but personally I don't 
> see the use for it as long as you keep your property names a little different.
> I also think build.properties, project.properties and 
> driver/default.properties should be included by default when filtering is 
> enabled.
> Now, each <resource/> element can keep the <filtering>true</filtering> 
> property to acknowledge it wants to be filtered.
> The reason to allow different files is that the purpose of filters is to be 
> able to substitute varying values, so you may not want to hard code them into 
> project.xml. And this configuration should be flexible enough to work without 
> Ant if necessary.
> ----
> I'm happy to work on this once there is agreement - just opening this to 
> track its progress.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to