The ORM plugin is not going fubar. I'm simply using its schema generation capabilities for my entities during my process-classes phase, and I just happen to be using derby embedded to do it. Derby, by design, will produce a derby.log file in the current working directory unless you take steps to avoid it, one of which is to set the system property derby.stream.error.field to something other than its default value. I find that setting it to java.lang.System.out is just jim-dandy.
In fact, I have different profiles for different ORMs & databases, and they *all* produce derby.log files when producing the schema against derby. Can we simply have the powers that be promote properties-maven-plugin to a GA release, or move the functionality of the set-system-properties goal to build-helper-maven-plugin? On Sun, Feb 24, 2013 at 8:43 AM, Martin Gainty <mgai...@hotmail.com> wrote: > 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: stephen.alan.conno...@gmail.com > > To: users@maven.apache.org > > > > 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 <dant...@gmail.com> 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 < > matt...@matthewadams.me> > > > > 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 < > fcamb...@gmail.com > > > > >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 < > > > matt...@matthewadams.me > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- mailto:matt...@matthewadams.me <matt...@matthewadams.me> skype:matthewadams12 googletalk:matt...@matthewadams.me http://matthewadams.me http://www.linkedin.com/in/matthewadams
