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