Re: Maven Filtering component
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are
in the order of their declaration in
the XML.
They are not used (as they are not used in resources plugin 2.2 and
adding filters as a child of the project element is not valid).
Are you talking about the fact, that I wrote pom.filters.
I thought everybody would understand what I am talking about.
But yes you are right, it is
pom.xml/project/build/filters
Anyhow I still want to say that the order of the declaration
should be honored by maven!
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
No because it already works (there is an it[1] for
this in the resources plugin).
It seems to me you are a bit too quick with your
conclusions.
Maybe that your integration-test works. But the
feature I am talking about does NOT work.
See example:
pom.xml:
?xml version=1.0 encoding=UTF-8?
!-- $Id: pom.xml 566 2008-07-25 19:51:37Z hohwille $ --
project
modelVersion4.0.0/modelVersion
groupIdfoo.bar/groupId
artifactIdtest/artifactId
version1.0/version
packagingjar/packaging
nametest/name
descriptionfiltering test/description
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
filters
filtersrc/main/filters/filter1.properties/filter
filtersrc/main/filters/filter2.properties/filter
/filters
/build
/project
src/main/filters/filter1.properties:
var1=Foo
var3=${var2}/Thing
src/main/filters/filter2.properties:
var2=${var1}-Bar
src/main/resources/test.properties:
var1=${var1}
var2=${var2}
var3=${var3}
now do mvn process-resources
and you get
target/classes/test.properties:
var1=Foo
var2=${var1}-Bar
var3=${var2}/Thing
What I am expecting is:
var1=Foo
var2=Foo-Bar
var3=Foo-Bar/Thing
Thanks,
--
Olivier
Take care
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI69bEmPuec2Dcv/8RAibJAJ4wIEpNy9K2hRfnBFOfbWQ3LBFL2gCfe9JO
b+6+DF8VRWampqo0xTPfFjA=
=HIjj
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
2008/10/7 Joerg Hohwiller [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are
in the order of their declaration in
the XML.
They are not used (as they are not used in resources plugin 2.2 and
adding filters as a child of the project element is not valid).
Are you talking about the fact, that I wrote pom.filters.
I thought everybody would understand what I am talking about.
But yes you are right, it is
pom.xml/project/build/filters
Anyhow I still want to say that the order of the declaration
should be honored by maven!
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
No because it already works (there is an it[1] for
this in the resources plugin).
It seems to me you are a bit too quick with your
conclusions.
Maybe that your integration-test works. But the
feature I am talking about does NOT work.
Have you tested with current resources plugin trunk or with a released
version ?
You should really have a look at the it test in the resources plugin I
have added some asserts due to your email.
See example:
pom.xml:
?xml version=1.0 encoding=UTF-8?
!-- $Id: pom.xml 566 2008-07-25 19:51:37Z hohwille $ --
project
modelVersion4.0.0/modelVersion
groupIdfoo.bar/groupId
artifactIdtest/artifactId
version1.0/version
packagingjar/packaging
nametest/name
descriptionfiltering test/description
build
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
filters
filtersrc/main/filters/filter1.properties/filter
filtersrc/main/filters/filter2.properties/filter
/filters
/build
/project
src/main/filters/filter1.properties:
var1=Foo
var3=${var2}/Thing
src/main/filters/filter2.properties:
var2=${var1}-Bar
src/main/resources/test.properties:
var1=${var1}
var2=${var2}
var3=${var3}
now do mvn process-resources
and you get
target/classes/test.properties:
var1=Foo
var2=${var1}-Bar
var3=${var2}/Thing
What I am expecting is:
var1=Foo
var2=Foo-Bar
var3=Foo-Bar/Thing
Thanks,
--
Olivier
Take care
Jörg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI69bEmPuec2Dcv/8RAibJAJ4wIEpNy9K2hRfnBFOfbWQ3LBFL2gCfe9JO
b+6+DF8VRWampqo0xTPfFjA=
=HIjj
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
as often I a little late on some threads ;)
I have start a proposal [1]
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are in the order of their declaration in
the XML.
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
My suggestion to implement this, would be to
create chains of Properties that inherit
from their parent and resolve this in
getProperty(). However you might not want to
use your own API defined as clean interface
instead of Properties.
Thanks
Jörg
Thanks for comments,
--
Olivier
[1]
http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI2pjzmPuec2Dcv/8RAj+JAJ9CuWvkh8A+UbHxgJfksaIPQbT5hQCfete7
XejVhEEoWmQxfpIvgoLLJJ4=
=xaPy
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
2008/9/24 Joerg Hohwiller [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Hi there,
as often I a little late on some threads ;)
I have start a proposal [1]
so far so good.
I have the following suggestions:
1. Also specify that the pom.filters are in the order of their declaration in
the XML.
They are not used (as they are not used in resources plugin 2.2 and
adding filters as a child of the project element is not valid).
2. Resolve variables whenever they are requested.
What I mean is that I can do
filter1.properties:
var1=Foo
var3=${var2}/Thing
filter2.properties:
var2=${var1}-Bar
So if I resolve ${var3} I get Foo-Bar/Thing.
That would be an excellent feature, since I am using
maven for deploying a large system and therefore
build it as multiple debian-packages with
seperation of application- and configuration-packages.
The configuration packages are build for
production as well as for 14 different
testing-environments. Various ports, hostnames, etc.
slightly differ in these environments. I could avoid
a lot of redundancies and daramtically simplify my
filters with the features described above.
Do I need to file a JIRA ticket or is this enough
input?
No because it already works (there is an it[1] for this in the
resources plugin).
Thanks,
--
Olivier
[1]
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-resources-plugin/src/it/filter/
My suggestion to implement this, would be to
create chains of Properties that inherit
from their parent and resolve this in
getProperty(). However you might not want to
use your own API defined as clean interface
instead of Properties.
Thanks
Jörg
Thanks for comments,
--
Olivier
[1]
http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFI2pjzmPuec2Dcv/8RAj+JAJ9CuWvkh8A+UbHxgJfksaIPQbT5hQCfete7
XejVhEEoWmQxfpIvgoLLJJ4=
=xaPy
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
Hi, I have start a proposal [1] Thanks for comments, -- Olivier [1] http://docs.codehaus.org/display/MAVEN/Resources+Handling+(common+component+maven-filtering) 2008/3/1, Jason van Zyl [EMAIL PROTECTED]: I'll write something up about the ordering of processing in the wiki so that we don't lose it in the ether. Probably won't happen today but later Sunday night. On 1-Mar-08, at 5:52 AM, Olivier Lamy wrote: Jason, Have you found some time to look ? I have created a resources plugin branch [1] which use the new component. Thanks, -- Olivier [1] https://svn.apache.org/repos/asf/maven/plugins/branches/MRESOURCES-56/ 2008/2/28, Jason van Zyl [EMAIL PROTECTED]: You just have to make sure that the processing order that happens in the resource plugin matches what would happen with processing of only execution properties in the CLI/Embedder. I can take a look tomorrow or grab me on IRC or I'll forget. I'm in one of my lose track of time modes. On 28-Feb-08, at 4:25 AM, Stephane Nicoll wrote: I agree with you Olivier. Now I don't know the internals of the embedder. Jason, what do you think? Stéphane On Mon, Feb 25, 2008 at 11:06 PM, Olivier Lamy [EMAIL PROTECTED] wrote: 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. I have changed System.getProperties to mavenSession.executionProperties. Now we have to agree on the properties loading order. If I look at the current maven-resources-plugin implementation which use System props and not mavenSession.executionProperties, this ones doesn't win. IMHO, it's not correct because the user must wins with a cli input. The component (maven-filtering) use the order defined in the documentation [1]. WDYT ? Thanks, -- Olivier [1] http://people.apache.org/~olamy/staging-sites/maven- filtering/ . Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/ properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure,
Re: Maven Filtering component
Jason, Have you found some time to look ? I have created a resources plugin branch [1] which use the new component. Thanks, -- Olivier [1] https://svn.apache.org/repos/asf/maven/plugins/branches/MRESOURCES-56/ 2008/2/28, Jason van Zyl [EMAIL PROTECTED]: You just have to make sure that the processing order that happens in the resource plugin matches what would happen with processing of only execution properties in the CLI/Embedder. I can take a look tomorrow or grab me on IRC or I'll forget. I'm in one of my lose track of time modes. On 28-Feb-08, at 4:25 AM, Stephane Nicoll wrote: I agree with you Olivier. Now I don't know the internals of the embedder. Jason, what do you think? Stéphane On Mon, Feb 25, 2008 at 11:06 PM, Olivier Lamy [EMAIL PROTECTED] wrote: 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. I have changed System.getProperties to mavenSession.executionProperties. Now we have to agree on the properties loading order. If I look at the current maven-resources-plugin implementation which use System props and not mavenSession.executionProperties, this ones doesn't win. IMHO, it's not correct because the user must wins with a cli input. The component (maven-filtering) use the order defined in the documentation [1]. WDYT ? Thanks, -- Olivier [1] http://people.apache.org/~olamy/staging-sites/maven-filtering/ . Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a
Re: Maven Filtering component
I'll write something up about the ordering of processing in the wiki so that we don't lose it in the ether. Probably won't happen today but later Sunday night. On 1-Mar-08, at 5:52 AM, Olivier Lamy wrote: Jason, Have you found some time to look ? I have created a resources plugin branch [1] which use the new component. Thanks, -- Olivier [1] https://svn.apache.org/repos/asf/maven/plugins/branches/MRESOURCES-56/ 2008/2/28, Jason van Zyl [EMAIL PROTECTED]: You just have to make sure that the processing order that happens in the resource plugin matches what would happen with processing of only execution properties in the CLI/Embedder. I can take a look tomorrow or grab me on IRC or I'll forget. I'm in one of my lose track of time modes. On 28-Feb-08, at 4:25 AM, Stephane Nicoll wrote: I agree with you Olivier. Now I don't know the internals of the embedder. Jason, what do you think? Stéphane On Mon, Feb 25, 2008 at 11:06 PM, Olivier Lamy [EMAIL PROTECTED] wrote: 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. I have changed System.getProperties to mavenSession.executionProperties. Now we have to agree on the properties loading order. If I look at the current maven-resources-plugin implementation which use System props and not mavenSession.executionProperties, this ones doesn't win. IMHO, it's not correct because the user must wins with a cli input. The component (maven-filtering) use the order defined in the documentation [1]. WDYT ? Thanks, -- Olivier [1] http://people.apache.org/~olamy/staging-sites/maven- filtering/ . Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/ properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is
Re: Maven Filtering component
I agree with you Olivier. Now I don't know the internals of the embedder. Jason, what do you think? Stéphane On Mon, Feb 25, 2008 at 11:06 PM, Olivier Lamy [EMAIL PROTECTED] wrote: 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. I have changed System.getProperties to mavenSession.executionProperties. Now we have to agree on the properties loading order. If I look at the current maven-resources-plugin implementation which use System props and not mavenSession.executionProperties, this ones doesn't win. IMHO, it's not correct because the user must wins with a cli input. The component (maven-filtering) use the order defined in the documentation [1]. WDYT ? Thanks, -- Olivier [1] http://people.apache.org/~olamy/staging-sites/maven-filtering/ . Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin.
Re: Maven Filtering component
You just have to make sure that the processing order that happens in the resource plugin matches what would happen with processing of only execution properties in the CLI/Embedder. I can take a look tomorrow or grab me on IRC or I'll forget. I'm in one of my lose track of time modes. On 28-Feb-08, at 4:25 AM, Stephane Nicoll wrote: I agree with you Olivier. Now I don't know the internals of the embedder. Jason, what do you think? Stéphane On Mon, Feb 25, 2008 at 11:06 PM, Olivier Lamy [EMAIL PROTECTED] wrote: 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. I have changed System.getProperties to mavenSession.executionProperties. Now we have to agree on the properties loading order. If I look at the current maven-resources-plugin implementation which use System props and not mavenSession.executionProperties, this ones doesn't win. IMHO, it's not correct because the user must wins with a cli input. The component (maven-filtering) use the order defined in the documentation [1]. WDYT ? Thanks, -- Olivier [1] http://people.apache.org/~olamy/staging-sites/maven-filtering/ . Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A
Re: Maven Filtering component
2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. I have changed System.getProperties to mavenSession.executionProperties. Now we have to agree on the properties loading order. If I look at the current maven-resources-plugin implementation which use System props and not mavenSession.executionProperties, this ones doesn't win. IMHO, it's not correct because the user must wins with a cli input. The component (maven-filtering) use the order defined in the documentation [1]. WDYT ? Thanks, -- Olivier [1] http://people.apache.org/~olamy/staging-sites/maven-filtering/ . Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be :
Re: Maven Filtering component
I just hit the problem today with one of my colleague. Yes, System props should definitely win. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder, Apache Maven jason at sonatype dot com -- We all have problems. How we deal with them is a measure of our worth. -- Unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl
Re: Maven Filtering component
On 24-Feb-08, at 10:35 AM, Olivier Lamy wrote: Hi, Just to be sure mavenSession.getExecutionProperties() should be use. Yes, system properties are turned into execution properties in the CLI and pushed into the session. So that from the embedder each invocation can have it's own session and isolate execution properties. We just need to try and keep this use case in mind as I see use inside the IDEs starting to match the use from the command line in the next year. We just need to determine the precedence universally and take the values from the core instead of each plugin fiddling around with system properties directly. I was currently thinking that properties in the POM are looked at first and then overridden with execution properties. Where execution properties have system properties which can be overridden by CLI parameters. Currently system properties in trunk are not neutered because when I did that a bunch of things broke, mostly proxy related plugins. But this is the plan that I had in might. If we centralize all the code we can decide ultimately what the order of precedence is. But plugins fiddling with this is a bad pattern we have to avoid. Right ? Thanks, -- Olivier 2008/2/24, Jason van Zyl [EMAIL PROTECTED]: On 24-Feb-08, at 12:36 AM, Stephane Nicoll wrote: I just hit the problem today with one of my colleague. Yes, System props should definitely win. You also must start thinking about how system properties make it into the execution environment. System properties wreak havoc in the embedder and so you should never be dealing with System properties directly in any plugin. Never. The change has been made in trunk and I can see if that change was propagated back to the branch but System properties should get turned into execution properties (a simple properties) that multiple threads being executed don't get nailed by a globally set system property. Thanks, Stéphane On Sat, Feb 23, 2008 at 11:28 PM, Olivier Lamy [EMAIL PROTECTED] wrote: Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you
Re: Maven Filtering component
Now the question is do we have to change this order ?. Have a look at MRESOURCES-39 [1]. Users complains about system properties (-D in the mvn cli) doesn't win. IMHO, system props should wins. This was the case with maven1 [2]. Thougths ? Thanks, -- Olivier [1] http://jira.codehaus.org/browse/MRESOURCES-39 [2] http://maven.apache.org/maven-1.x/reference/properties.html 2008/2/19, Olivier Lamy [EMAIL PROTECTED]: Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
Hi Olivier, Sounds good! I'll try to look into that this w-e, to see how to use it in the assembly plugin, which suffers from lots of filtering issues. Fabrice On Tue, Feb 19, 2008 at 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/http://people.apache.org/%7Eolamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Filtering component
Yep sure. Currently, the new component use the same strategy as the maven-resources-plugin. -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Filtering component
I also know that in terms of pom specified property files, it's last wins currently. -Original Message- From: Stephane Nicoll [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 19, 2008 5:37 AM To: Maven Developers List Subject: Re: Maven Filtering component I guess we should have a look to the way this is done currently to avoid breaking the backward compat. On Feb 19, 2008 11:30 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Sure, could be better. But we have to agree on the order : * System Properties * pom.properties * List of properties ( the method has a parameter which accept a List of String - path properties files ) (war plugin use it to pass a list of properties file). * pom.filters * pom.build.filters ? -- Olivier 2008/2/19, Stephane Nicoll [EMAIL PROTECTED]: This one was very much expected, thanks for doing this. However, I think that we should use a first-win strategy, otherwise there is no way to control the actual value of a property. First-win strategy is mainly used everywhere in the war plugin and ease a lot of stuff Is there any reason you choose doing this? Thanks, Stéphane On Feb 19, 2008 10:17 AM, Olivier Lamy [EMAIL PROTECTED] wrote: Hi, As you know some plugins made some filtering base on the code coming from the maven-resources-plugin. This means there are some copy and paste from the resources plugin source to other plugins. To prevent this, the code from the resources plugin has been put in a plexus component (currently in shared sandbox [1]). A documentation has been started [2]. It has been integrated in the maven-war-plugin trunk. Before calling a vote on a first alpha-1 release, I'd like to have some comments/thoughts on it. The final goal of this component should be : using it in all plugins which need filtering. Thanks, -- Olivier [1] : https://svn.apache.org/repos/asf/maven/sandbox/trunk/shared/maven-filtering/ [2] : http://people.apache.org/~olamy/staging-sites/maven-filtering/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck -- S.Yegge - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
