Fail safe has the same config options, and perhaps your ORM's maven plugin needs an enhancement ;-)
On Sunday, 24 February 2013, Matthew Adams wrote: > Good suggestion, but I need it for not just that (and besides, you should > be using failsafe for integration tests, not surefire). But also I need > that property set for database schema generation via my ORM's Maven plugin, > which happens during the process-classes phase. > > > On Fri, Feb 22, 2013 at 10:58 PM, Dan Tran <[email protected]> wrote: > > > for you case, you should pass the system property directly into surefire > > > > -D > > > > On Fri, Feb 22, 2013 at 7:33 PM, Matthew Adams <[email protected]> > > wrote: > > > Hmmm. I'm using the goal > > > set-system-properties< > > > http://mojo.codehaus.org/properties-maven-plugin/set-system-properties-mojo.html > > >and > > > specifying a phase explicitly. Seems to work fine. > > > > > > For the curious, my use case is trying to get rid of the annoying > > derby.log > > > file during my integration-test phase by using the derby system > > > property derby.stream.error.field=java.lang.System.out. > > > > > > Maybe we could move the set-system-properties goal over to the > > > build-helper-maven-plugin< > > http://mojo.codehaus.org/build-helper-maven-plugin/>. > > > Seems like a good place for it. > > > > > > Works like a charm when you set it like this: > > > > > > <profile> > > > <id>derby</id> > > > <properties> > > > <app.db.vendor.id>derby</app.db.vendor.id> > > > <app.db.driver.id>derby</app.db.driver.id> > > > </properties> > > > <build> > > > <plugins> > > > <plugin> > > > <groupId>org.codehaus.mojo</groupId> > > > <artifactId>properties-maven-plugin</artifactId> > > > <executions> > > > <execution> > > > <goals> > > > <goal>set-system-properties</goal> > > > </goals> > > > <phase>initialize</phase> > > > <configuration> > > > <properties> > > > <property> > > > <name>derby.stream.error.field</name> > > > <value>java.lang.System.out</value> > > > </property> > > > </properties> > > > </configuration> > > > </execution> > > > </executions> > > > </plugin> > > > </plugins> > > > </build> > > > </profile> > > > > > > > > > > > > > > > On Fri, Feb 22, 2013 at 9:59 AM, Frédéric Camblor <[email protected] > > >wrote: > > > > > >> Hi ! > > >> > > >> I *think* this is because this plugin is shooting you in the foot, by > > >> making you think it will *always* load externalized properties whereas > > it > > >> won't be the case. > > >> For instance, during call of direct plugin goal (like release:prepare > / > > >> release:perform), the plugin won't be binded to any phases => > properties > > >> won't be loaded / made available. > > >> > > >> I think this was based on a good idea at the beginning, but is not > > really > > >> applicable. > > >> > > >> Cheers, > > >> Frédéric > > >> > > >> Frédéric Camblor <http://fcamblor.wordpress.com/> > > >> <http://www.twitter.com/fcamblor> > > >> Bordeaux JUG <http://bordeauxjug.org/> Leader > > >> Jenkins <http://jenkins-ci.org/> community member & plugin commiter > > >> > > >> > > >> > > >> On Fri, Feb 22, 2013 at 4:39 PM, Matthew Adams < > [email protected] >
