[ http://jira.codehaus.org/browse/MNG-942?page=comments#action_46854 ]
John Allen commented on MNG-942:
--------------------------------
> " (I'm assuming that by 'source Java System properties' you mean setting
> them, like System.setProperty or -Dprop=val). "
By source Java System propeties I mean reading them and substituting the value
into the location that is sourcing it. I.e. -Dx=y, then in settings.xml if I
wish to use the value defined for property x i would refer to it as ${x}.
> "Reading your description for the fifth time, I suspect you meant using
> ${propname} in the settings.xml, which get filled in using
> -Dpropname=propval? "
Indeed, system properties are those made available by the runtime via the
System.getProperties() call and can only be introduced via JVM environment
setup (including -D passing) or via explicit
System.getProperties().set/setProperty() calls. I find it useful to distinguish
between these and general use utility (java.util.Properties) properties.
> "- sourcing java system properties (a la -Dx=y ) can be done using profiles"
I saw that by they only allow for certain types of specialisation, namely (from
comments in settings.xml) 'you are restricted to specifying only artifact
repositories, plugin repositories, and free-form properties to be used as
configuration variables for plugins in the POM.'
> "- jvm args (-Xmx768m etc) cannot be in the settings.xml since the jvm has
> already started then"
Indeed, I normally refer to these these are JVM CLI arguments, not java system
properties.
> "- there's just one localRepository in the settings.xml; but you can override
> using a maven option (-Dmaven.repo.local as you said, not sure if that works
> in conjunction with profiles, because I don't know which one is set first,
> and if it's read afterwards. But why the need for multiple local
> repositories? just use -s path/to/settings.xml)
Indeed local repository specification via explicit M2 override property works
fine (-Dmaven.repo.local) and having multiple local reps is not the idea, the
idea was to support better the specialisation of the M2 environment by external
'agents' (users, scripts etc).
This is the ethos behind profiles after all - a user is able to trigger a
profile which contains a specialization of the settings either by explicit
'activateProfiles' CLI argument or via having set MAVEN_OPTS to incude a system
property that causes the profile to self activate.
Either of these technqiues is fine and allow a wrapper executable to control
the M2 setup unfortunately profiles do not cover all of the settings defined in
settings.xml, including stuff which is very likely to change depending on
where/when the build is being run such as network configuration information.
The idea of having multiple settings.xml files is not so great due to the
duplication of data and the maintenance costs and fragility that introduces. In
fact activate-profiles would also be unecessary if this approach was taken, the
decision as to which 'profile' and therefore which settings.xml file to use
could be made external to M2 and then the approriate settings.xml file could be
passed to M2 via the -s flag. This is the common approach with more script
based build systems such as make and ant but then they usually provide the
ability to make these files compostitional through supporting 'includes' and
potentially conditional logic too (like the activate switch used in profiles)
A simple approach to this kind of thing is to allow any XML element value to
overriden by its matching system property if defined. Thus
maven.settings.localRepository="foo" would override
<settings><localRepository></localRepository></settings>
And maven.settings.offline="bar"
<settings><offline></offline></settings>
This approach can even be applied to sets of elements as long as the sets have
an identifier field (such as id), e.g.:
<proxy>
<id>optional</id>
<active>true</active>
</proxy>
<proxy>
<id>work</id>
<active>false</active>
</proxy>
-Dmaven.settings.proxy.optional.active=false would override the 'optional'
proxy active element
-Dmaven.settings.proxy.work.active=false would override the 'work' proxy active
element.
If this is not your bag then I guess it would be good to ensure all location
specific (including network location) settings could be specified in profiles
that could then be turned on/off.
Hmm, not sure which i prefer, you obviously like the active profiles approach
so I would defer to that technique and simply suggest fuller support is added
to enable better customisation.
> Ability to source system properties in settings.xml
> ---------------------------------------------------
>
> Key: MNG-942
> URL: http://jira.codehaus.org/browse/MNG-942
> Project: Maven 2
> Type: Wish
> Versions: 2.0-beta-1
> Environment: Maven 2.0-beta-1
> WIN XP PRO SP2
> java version "1.5.0_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode)
> Reporter: John Allen
> Assignee: John Casey
> Priority: Trivial
> Fix For: 2.0-beta-2
>
> Original Estimate: 4 hours
> Remaining: 4 hours
>
> Would be nice to be able to source Java System properties in the global and
> user settings.xml file. This is intended to allow custom build systems to set
> arbitrary m2 settings.xml properties programmatically by wrapping m2
> executable in their own wrapper exe and then passing these settings to M2 via
> the JVM options ($MAVEN_OPTS). Currently only explicitly supported settings
> can be overrided/defined by system properties (such as maven.repo.local).
> An example might be the proxy being employed, depending on where the build is
> being run from the proxy might be set differently. Note the same machine is
> being used (a laptop in this case) but operates in multiple locations and
> therefore network configurations (work/home). The M2 wrapping script can
> detect this difference from network info (ipconfig or IE connection details)
> and set the proxy details appropriately. I guess in this example it would be
> even better if it was just able to set a System property that acted as a
> switch which then activated the correct proxy configuration defined in
> settings.xml.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
