Matthew and Frederic properties-maven-plugin has no hardcoded reference to derby.log
If you could identify the ORM maven-plugin groupId,artifactId,version you are implementing ..we could take a look at where its going fubar -M ---------------------------------------- > Date: Sun, 24 Feb 2013 08:25:26 +0000 > Subject: Re: Why is properties-maven-plugin still in alpha? > From: [email protected] > To: [email protected] > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
