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 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] > > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
