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]
