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