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]
