Using settings properties
Is it possible to use properties defined in settings.xml within
repositories / and distributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Using settings properties
Very bad practice! The repositories defined in the pom MUST be possible for
other people (other projects depending on your artifacts) to resolve. Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjk mj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / and distributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Using settings properties
Thanks for the advice. You could have proposed a solution instead of just a
criticism.
Sent from my iPhone
On Jan 19, 2011, at 4:02 AM, Anders Hammar and...@hammar.net wrote:
Very bad practice! The repositories defined in the pom MUST be possible for
other people (other projects depending on your artifacts) to resolve. Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjk mj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / and distributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Using settings properties
Hi
At my company we use properties in the global setting.xml which the
build is dependent. This make sense since our build is strictly within
our company and everyone uses the same maven installation
For instance:
(in setting.xml)
profile
idcore/id
properties
adeViewRoot/ade/viper/adeViewRoot
/properties
(in pom.xml)
distributionManagement
repository
idsdp/id
layoutdefault/layout
nameSDP Repository/name
uniqueVersionfalse/uniqueVersion
urlfile://${adeViewRoot}/sdp/maven2-snapshots/url
/repository
I suppose that you could use environment variable, like:
site
idsdp-site/id
nameService Delivery Platform Site/name
urlfile:///net/${env.WEB_SERVER_NAME}${env.WEB_SERVER_BASE_LOCAL_DIR}/${oracle.sdp.release}/${env.ADE_VIEW_LABEL}/reports/url
/site
I think you might want to check the schema for setting.xml to see where
you can add the element properties.
Cheers
Lucas
On 01/19/2011 12:43 PM, Michael Kelleher wrote:
Thanks for the advice. You could have proposed a solution instead of just a
criticism.
Sent from my iPhone
On Jan 19, 2011, at 4:02 AM, Anders Hammarand...@hammar.net wrote:
Very bad practice! The repositories defined in the pom MUST be possible for
other people (other projects depending on your artifacts) to resolve. Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjkmj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / anddistributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
Re: Using settings properties
I would strongly suggest that you move the distMgmt section to a corporate
parent pom instead. So when (if?) you change the urls, you just update the
parent pom (and yes, you do need to update the reference in any project
inheriting from it). Anything in your pom that could change depending on the
environment is most often a bad idea.
Having a look at how things like this is solved within the open source world
(the apache parent or the codehaus parent), would give you good ideas of
best practice.
/Anders
On Wed, Jan 19, 2011 at 13:06, Lucas Persson lucas.pers...@oracle.comwrote:
Hi
At my company we use properties in the global setting.xml which the build
is dependent. This make sense since our build is strictly within our company
and everyone uses the same maven installation
For instance:
(in setting.xml)
profile
idcore/id
properties
adeViewRoot/ade/viper/adeViewRoot
/properties
(in pom.xml)
distributionManagement
repository
idsdp/id
layoutdefault/layout
nameSDP Repository/name
uniqueVersionfalse/uniqueVersion
urlfile://${adeViewRoot}/sdp/maven2-snapshots/url
/repository
I suppose that you could use environment variable, like:
site
idsdp-site/id
nameService Delivery Platform Site/name
urlfile:///net/${env.WEB_SERVER_NAME}${env.WEB_SERVER_BASE_LOCAL_DIR}/${oracle.sdp.release}/${env.ADE_VIEW_LABEL}/reports/url
/site
I think you might want to check the schema for setting.xml to see where you
can add the element properties.
Cheers
Lucas
On 01/19/2011 12:43 PM, Michael Kelleher wrote:
Thanks for the advice. You could have proposed a solution instead of just
a
criticism.
Sent from my iPhone
On Jan 19, 2011, at 4:02 AM, Anders Hammarand...@hammar.net wrote:
Very bad practice! The repositories defined in the pom MUST be possible
for
other people (other projects depending on your artifacts) to resolve.
Using
properties defined in settings.xml makes that impossible.
/Anders
On Wed, Jan 19, 2011 at 05:14, mjkmj.kelle...@gmail.com wrote:
Is it possible to use properties defined in settings.xml within
repositories / anddistributionManagement /?
Other properties seem to get resolved during a build, however when I do a
deploy, maven uses the variable name with the leading ${ and trailing },
instead of the resolved variable value.
Any ideas?
