John, I am in the same case of edward and want to "enable/disable" test "families" while executing my maven builds.
For instance, I'll want to execute every "data access tests" once per day -and not after each commits because it takes time !- For some other tests, I'd like to execute only selenium tests (which rely on deployed app and take long long time too) => this tests will be planned twice per week. My personnal test framework allows to "tag" tests with families in order to execute (or not) tests depending on system properties. By exemple, if I run : mvn test -Dtest.families.includes=SELENIUM,DATA_ACCESS every "heavy" tests (tests which take a long time to execute !) will be executed. Moreover, I'll be able to execute "regression pre-emptive" tests after each commits by executing the following command line : mvn test -Dtest.families.includes=NON-REGRESSION I can't see how I could define these "per-build" properties (neither in MAVEN_OPTS nor in my pom.xml file since it will be defined for every build I run !) except by defining some profiles for that. I don't really thing this would be the better way since I could have lots of profiles (for now on, I have approx 6-7 test families ... and I don't want to make a cartesian product of all of these families with profiles !) 2009/4/20 John Casey <[email protected]> > Another couple things to consider: > > 1. in Surefire, you should probably use the systemProperties to pass on > system properties explicitly. Just a suggestion. > > 2. For actual system properties, it might be wiser to set them in > MAVEN_OPTS instead of the mvn -D option. This is because Maven has > deprecated the propagation of -D options into system properties, in order to > make it a little friendlier for people trying to run multiple maven > instances in a single JVM (without getting cross-pollution of sysprops). > > Using MAVEN_OPTS (which IIRC you can set in Hudson), you can still specify > '-Dsystem.property=foo' and have it work fine. > > -john > > > edward eric pedersson wrote: > >> yes you are right. >> >> It seems 2.4.3 of the plugin is broken but 2.4.2 works just fine. >> >> will lock down the version is the pom. >> >> thanks for your help >> >> 2009/4/20 Stephen Connolly <[email protected]>: >> >>> Have you locked down the version of surefire you are using in your pom? >>> >>> if you have not locked it down, then you will be picking up a newer >>> version of surefire with 2.1.0. >>> >>> AFAIK, a newer version of surefire has issues passing system >>> properties to the forked process. >>> >>> in any case you should always lock down the versions of plugins that >>> you are using or else your build is not fully reproducible >>> >>> -Stephen >>> >>> 2009/4/20 edward eric pedersson <[email protected]>: >>> >>>> Hi >>>> >>>> We use the command line to pass on system properties to the java >>>> virtual machine when running our Hudson builds on a Linux box. It used >>>> to work quite well in 2.0.9 by since we upgraded to 2.1.0 it has >>>> stopped working altogether. The system properties just never make it >>>> to the java virtual machine. >>>> >>>> I have created a small test project and indeed it does not work at >>>> all. I have attached it in case you want to give it a go. [it got >>>> blocked so sending without attachment] >>>> >>>> This should work just fine with maven 2.0.9 >>>> >>>> mvn2.0.9 -Dsystem.test.property=test test >>>> >>>> But this will fail >>>> >>>> mvn2.1 -Dsystem.test.property=test test >>>> >>>> The java code simply does this >>>> >>>> assertTrue( System.getProperty("system.test.property") != null); >>>> >>>> >>>> Any thoughts >>>> >>>> -- >>>> >>>> >>>> -- e >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Frédéric Camblor
