release:perform or surefire:test not setting system properties during deploy
Hi Folks,
I have some tests running that read a system property to determine where some
resources should be read from. I've defined that property inside a master pom
file, and created profiles that activate that property on other projects pom
files. The structure is somehow like this:
master-pom-folder
|-master-pom.xml
|-submodule-folder
|-submodule-pom.xml
|-test-project
|-test-pom.xml
In the master pom file, I've the following:
properties
mycompany.localTestData/temp/testdata//mycompany.localTestData
/properties
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.6/version
/plugin
/plugins
/pluginManagement
/build
[...]
profiles
profile
idrelease/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
systemPropertyVariables
mycompany.testRoot${mycompany.localTestData}/mycompany.testRoot
/systemPropertyVariables
argLine-Dmycompany.testRoot=${mycompany.localTestData}/argLine
/configuration
/plugin
/plugins
/build
/profile
/profiles
The submodule-pom.xml is just a parent for all project it contains, and it
inherits from this master-pom. The test-pom.xml inherits from the
submodule-pom.xml.
Running effective-pom with the release profile activated over the
submodule-pom.xml and test-pm.xml tells me that the configuration for surefire
plugin is correct, for instance:
build
[...]
plugins
[...]
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.6/version
configuration
additionalClasspathElements
additionalClasspathElementtarget/test-classes/additionalClasspathElement
/additionalClasspathElements
systemPropertyVariables
mycompany.testRoot/temp/testdata//mycompany.testRoot
/systemPropertyVariables
argLine-Dmycompany.testRoot=/temp/testdata//argLine
/configuration
/plugin
[...]
However, when I try release:prepare release:perform with that profile activated
on the submodule-pom.xml, the execution of the tests seems to be ignoring those
settings. When tests read the system property mycompany.testRoot using
System.getProperty it comes null, and the default value gets set. You can note
that I have even tried different approches, using systemPropertyVariables and
later argLine, and end up leaving both in the profile. Any thoughts on what
might be happening? Am I missing something?
Kind regards,
Felipe Roos
http://www.linkedin.com/in/feliperoos
Achar desculpas para os nossos
defeitos não nos torna melhores
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Res: release:perform or surefire:test not setting system properties during deploy
I've just figured out that the setting I need is arguments from relase
plugin.
Using that solved my problem.
Felipe Roos
http://www.linkedin.com/in/feliperoos
Achar desculpas para os nossos
defeitos não nos torna melhores
- Mensagem original
De: Felipe Roos feliper...@yahoo.com
Para: Maven Users users@maven.apache.org
Enviadas: Quarta-feira, 9 de Fevereiro de 2011 15:53:31
Assunto: release:perform or surefire:test not setting system properties
during
deploy
Hi Folks,
I have some tests running that read a system property to determine where
some
resources should be read from. I've defined that property inside a master
pom
file, and created profiles that activate that property on other projects pom
files. The structure is somehow like this:
master-pom-folder
|-master-pom.xml
|-submodule-folder
|-submodule-pom.xml
|-test-project
|-test-pom.xml
In the master pom file, I've the following:
properties
mycompany.localTestData/temp/testdata//mycompany.localTestData
/properties
[...]
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
version2.0/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version2.6/version
/plugin
/plugins
/pluginManagement
/build
[...]
profiles
profile
idrelease/id
activation
activeByDefaultfalse/activeByDefault
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
configuration
systemPropertyVariables
mycompany.testRoot${mycompany.localTestData}/mycompany.testRoot
/systemPropertyVariables
argLine-Dmycompany.testRoot=${mycompany.localTestData}/argLine
/configuration
/plugin
/plugins
/build
/profile
/profiles
The submodule-pom.xml is just a parent for all project it contains, and it
inherits from this master-pom. The test-pom.xml inherits from the
submodule-pom.xml.
Running effective-pom with the release profile activated over the
submodule-pom.xml and test-pm.xml tells me that the configuration for
surefire
plugin is correct, for instance:
build
[...]
plugins
[...]
plugin
artifactIdmaven-surefire-plugin/artifactId
version2.6/version
configuration
additionalClasspathElements
additionalClasspathElementtarget/test-classes/additionalClasspathElement
/additionalClasspathElements
systemPropertyVariables
mycompany.testRoot/temp/testdata//mycompany.testRoot
/systemPropertyVariables
argLine-Dmycompany.testRoot=/temp/testdata//argLine
/configuration
/plugin
[...]
However, when I try release:prepare release:perform with that profile
activated
on the submodule-pom.xml, the execution of the tests seems to be ignoring
those
settings. When tests read the system property mycompany.testRoot using
System.getProperty it comes null, and the default value gets set. You can
note
that I have even tried different approches, using systemPropertyVariables
and
later argLine, and end up leaving both in the profile. Any thoughts on what
might be happening? Am I missing something?
Kind regards,
Felipe Roos
http://www.linkedin.com/in/feliperoos
Achar desculpas para os nossos
defeitos não nos torna melhores
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Res: Buildmanagement-Strategy
Hi Folks, That's a very intersting conversation. Regarding internal process, do you have such things as internal releases and external releases? If so, how do you manage your maven releases of releases and snapshots during the qualification cycles? Regards, Felipe Roos http://www.linkedin.com/in/feliperoos Achar desculpas para os nossos defeitos não nos torna melhores - Mensagem original De: Nayan Hajratwala na...@chikli.com Para: Maven Users List users@maven.apache.org Enviadas: Quinta-feira, 16 de Setembro de 2010 13:39:16 Assunto: Re: Buildmanagement-Strategy On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote: Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-) Good luck! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Release Notes Plugin
Hi Folks, Does anyone knows about a plugin that can attach/generate an internal release notes? For instance, I'm trying to generate a report based on SVN changelog filtering, as that might be interesting for testers that use the component to perform system testing. I've looked at some approaches using maven changelog pluging, but that requires me to know in advance what range of revisions/date I need. What I'm looking for is an automated way of getting the change log since last version. How do you guys deal with release notes in general when using maven? Regards, Felipe Roos http://www.linkedin.com/in/feliperoos Achar desculpas para os nossos defeitos não nos torna melhores - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
