The order is:
use system-properties if available,
otherwise use properties from pom.xml if available,
otherwise use properties from profiles.xml (only M2) if available,
otherwise use properties from user settings.xml if available,
otherwise use properties from global settings.xml
Is it possible
I don't know the numbers, but I'm assuming that 99 out of 100 times the
expression is filled with a command line argument.
I can imagine why the name 'expression' was used: it must contain exactly
one expression.
But that's from the technical perspective.
We've all seen the threads where
+1 for your analysis
argument for command line argument: I understand the logic, I find it
better than expression effectively, but I'm not convinced that it is much
explicit.
I'm not convinced by value either: your analysis is perfectly right
property? system-property?
considering than when
+1 if we could get rid of the ${ and }, because users are not interested
in the fact that this is resolved as an expression.
This should make it better to read too.
When I started with Maven I never had the feeling I was passing
system-properties, so I doubt that this is the right name.
I
On Wed, May 2, 2012 at 7:40 AM, Robert Scholte apa...@sourcegrounds.comwrote:
+1 if we could get rid of the ${ and }, because users are not interested
in the fact that this is resolved as an expression.
This should make it better to read too.
When I started with Maven I never had the feeling
Hi,
expression has always caused a lot of confusion for plugin-users.
Should this be a moment to rename it to something like argument?
-Robert
Op Sat, 28 Apr 2012 23:23:11 +0200 schreef ol...@apache.org:
Author: olamy
Date: Sat Apr 28 21:23:10 2012
New Revision: 1331837
URL:
probably a good occasion to improve usability
but I don't understand argument, even if I can't find any good proposition
value? as opposed to default-value?
any other idea around?
Regards,
Hervé
Le lundi 30 avril 2012 09:31:27 Robert Scholte a écrit :
Hi,
expression has always caused a
Is there a specific problem that requires a dedicated ThreadSafe annotation
instead of a simple attribute in the Mojo annotation?
BTW, Goal annotation instead of Mojo?
Regards,
Hervé
Le samedi 28 avril 2012 21:23:11 ol...@apache.org a écrit :
Author: olamy
Date: Sat Apr 28 21:23:10 2012
2012/4/29 Hervé BOUTEMY herve.bout...@free.fr:
Is there a specific problem that requires a dedicated ThreadSafe annotation
instead of a simple attribute in the Mojo annotation?
Agree all are attribute in mojo annotation so ThreadSafe can be an
attribute too.
BTW, Goal annotation instead of