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 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] > > >> > > >> > > > > > > --------------------------------------------------------------------- > > > 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 > > ---------------------------------------------------------- > > > > > > 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: [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]
