> " (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.
New Feature
Closed
Trivial
(I'm assuming that by 'source Java System properties' you mean setting them, like System.setProperty or -Dprop=val).
Most of this can be achieved using profiles in settings.xml:
started then
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)
proxies should go in the profiles section too, so you can change them.
Reading your description for the fifth time, I suspect you meant using ${propname}
in the settings.xml, which get filled in using -Dpropname=propval?
Could you clarify some more and/or say if the solutions above are good alternatives?
I think a nice one for roaming users is to have multiple settings.xml files,
and let the m2 script give a '
s ~/.m2/settings$ENVIRONMENT.xml' to main().- Switching proxy info: use a different settings.xml, specified with -s. Maybe
proxies should go in the profiles section too, so you can change them.
Reading your description for the fifth time, I suspect you meant using ${propname} in the settings.xml, which get filled in using -Dpropname=propval? Could you clarify some more and/or say if the solutions above are good alternatives? I think a nice one for roaming users is to have multiple settings.xml files, and let the m2 script give a 's ~/.m2/settings$ENVIRONMENT.xml' to main().