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]
