You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Olivier Lamy <ol...@apache.org> on 2008/03/01 14:52:16 UTC
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 <ja...@maven.org>:
> 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 <ol...@apache.org>
> > wrote:
> >> 2008/2/24, Jason van Zyl <ja...@maven.org>:
> >>>
> >>
> >>> 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 <ja...@maven.org>:
> >>>>>
> >>>>> 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 <ol...@apache.org>
> >>>>>> 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 <ol...@apache.org>:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Yep sure.
> >>>>>>>> Currently, the new component use the same strategy as the
> >>>>>>>> maven-resources-plugin.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Olivier
> >>>>>>>>
> >>>>>>>> 2008/2/19, Stephane Nicoll <st...@gmail.com>:
> >>>>>>>>> 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 <ol...@apache.org>
> >>>>>>>>> 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 <st...@gmail.com>:
> >>>>>>>>>>
> >>>>>>>>>>> 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 <ol...@apache.org>
> >>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you
> >>>>>>>>>>> build
> >>>>>>>>>>> one,
> >>>>>>>>>>> you suck" -- S.Yegge
> >>>>>>>>>>>
> >>>>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you build
> >>>>>>>>> one,
> >>>>>>>>> you suck" -- S.Yegge
> >>>>>>>>>
> >>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Large Systems Suck: This rule is 100% transitive. If you build
> >>>>>> one,
> >>>>>> you suck" -- S.Yegge
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
> >>> Thanks,
> >>>
> >>> Jason
> >>>
> >>> ----------------------------------------------------------
> >>> Jason van Zyl
> >>> Founder, Apache Maven
> >>> jason at sonatype dot com
> >>> ----------------------------------------------------------
> >>>
> >>>
> >>> A party which is not afraid of letting culture,
> >>> business, and welfare go to ruin completely can
> >>> be omnipotent for a while.
> >>>
> >>> -- Jakob Burckhardt
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> >
> > --
> > Large Systems Suck: This rule is 100% transitive. If you build one,
> > you suck" -- S.Yegge
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
> Simplex sigillum veri. (Simplicity is the seal of truth.)
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Filtering component
Posted by Olivier Lamy <ol...@apache.org>.
2008/10/7 Joerg Hohwiller <jo...@j-hohwiller.de>:
> -----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>
> <modelVersion>4.0.0</modelVersion>
> <groupId>foo.bar</groupId>
> <artifactId>test</artifactId>
> <version>1.0</version>
> <packaging>jar</packaging>
> <name>test</name>
> <description>filtering test</description>
>
> <build>
> <resources>
> <resource>
> <directory>src/main/resources</directory>
> <filtering>true</filtering>
> </resource>
> </resources>
> <filters>
> <filter>src/main/filters/filter1.properties</filter>
> <filter>src/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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Filtering component
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----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>
<modelVersion>4.0.0</modelVersion>
<groupId>foo.bar</groupId>
<artifactId>test</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<name>test</name>
<description>filtering test</description>
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<filters>
<filter>src/main/filters/filter1.properties</filter>
<filter>src/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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Filtering component
Posted by Olivier Lamy <ol...@apache.org>.
2008/9/24 Joerg Hohwiller <jo...@j-hohwiller.de>:
> -----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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Filtering component
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Filtering component
Posted by Olivier Lamy <ol...@apache.org>.
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 <ja...@maven.org>:
> 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 <ja...@maven.org>:
> >> 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 <ol...@apache.org>
> >>> wrote:
> >>>> 2008/2/24, Jason van Zyl <ja...@maven.org>:
> >>>>>
> >>>>
> >>>>> 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 <ja...@maven.org>:
> >>>>>>>
> >>>>>>> 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 <olamy@apache.org
> >>>>>>>> >
> >>>>>>>> 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 <ol...@apache.org>:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Yep sure.
> >>>>>>>>>> Currently, the new component use the same strategy as the
> >>>>>>>>>> maven-resources-plugin.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Olivier
> >>>>>>>>>>
> >>>>>>>>>> 2008/2/19, Stephane Nicoll <st...@gmail.com>:
> >>>>>>>>>>> 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 <ol...@apache.org>
> >>>>>>>>>>> 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 <st...@gmail.com>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 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 <ol...@apache.org>
> >>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail: dev-
> >>>>>>>>>>>>>> help@maven.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you
> >>>>>>>>>>>>> build
> >>>>>>>>>>>>> one,
> >>>>>>>>>>>>> you suck" -- S.Yegge
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you
> >>>>>>>>>>> build
> >>>>>>>>>>> one,
> >>>>>>>>>>> you suck" -- S.Yegge
> >>>>>>>>>>>
> >>>>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Large Systems Suck: This rule is 100% transitive. If you build
> >>>>>>>> one,
> >>>>>>>> you suck" -- S.Yegge
> >>>>>>>>
> >>>>>>>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> 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: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Jason
> >>>>>
> >>>>> ----------------------------------------------------------
> >>>>> Jason van Zyl
> >>>>> Founder, Apache Maven
> >>>>> jason at sonatype dot com
> >>>>> ----------------------------------------------------------
> >>>>>
> >>>>>
> >>>>> A party which is not afraid of letting culture,
> >>>>> business, and welfare go to ruin completely can
> >>>>> be omnipotent for a while.
> >>>>>
> >>>>> -- Jakob Burckhardt
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Large Systems Suck: This rule is 100% transitive. If you build one,
> >>> you suck" -- S.Yegge
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> ----------------------------------------------------------
> >> Jason van Zyl
> >> Founder, Apache Maven
> >> jason at sonatype dot com
> >> ----------------------------------------------------------
> >>
> >>
> >> Simplex sigillum veri. (Simplicity is the seal of truth.)
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
>
> Our achievements speak for themselves. What we have to keep track
> of are our failures, discouragements and doubts. We tend to forget
> the past difficulties, the many false starts, and the painful
> groping. We see our past achievements as the end result of a
> clean forward thrust, and our present difficulties as
> signs of decline and decay.
>
> -- Eric Hoffer, Reflections on the Human Condition
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Filtering component
Posted by Jason van Zyl <ja...@maven.org>.
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 <ja...@maven.org>:
>> 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 <ol...@apache.org>
>>> wrote:
>>>> 2008/2/24, Jason van Zyl <ja...@maven.org>:
>>>>>
>>>>
>>>>> 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 <ja...@maven.org>:
>>>>>>>
>>>>>>> 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 <olamy@apache.org
>>>>>>>> >
>>>>>>>> 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 <ol...@apache.org>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Yep sure.
>>>>>>>>>> Currently, the new component use the same strategy as the
>>>>>>>>>> maven-resources-plugin.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Olivier
>>>>>>>>>>
>>>>>>>>>> 2008/2/19, Stephane Nicoll <st...@gmail.com>:
>>>>>>>>>>> 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 <ol...@apache.org>
>>>>>>>>>>> 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 <st...@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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 <ol...@apache.org>
>>>>>>>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: dev-
>>>>>>>>>>>>>> help@maven.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you
>>>>>>>>>>>>> build
>>>>>>>>>>>>> one,
>>>>>>>>>>>>> you suck" -- S.Yegge
>>>>>>>>>>>>>
>>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you
>>>>>>>>>>> build
>>>>>>>>>>> one,
>>>>>>>>>>> you suck" -- S.Yegge
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Large Systems Suck: This rule is 100% transitive. If you build
>>>>>>>> one,
>>>>>>>> you suck" -- S.Yegge
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> jason at sonatype dot com
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>> A party which is not afraid of letting culture,
>>>>> business, and welfare go to ruin completely can
>>>>> be omnipotent for a while.
>>>>>
>>>>> -- Jakob Burckhardt
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Large Systems Suck: This rule is 100% transitive. If you build one,
>>> you suck" -- S.Yegge
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> jason at sonatype dot com
>> ----------------------------------------------------------
>>
>>
>> Simplex sigillum veri. (Simplicity is the seal of truth.)
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org