Ok. At least it's not a snapshot. I'm more worried about the client's perception than anything, btw. I'll just have to explain about snapshots v. releases etc.
On Mon, Feb 25, 2013 at 9:45 AM, Benson Margulies <[email protected]>wrote: > There are no 'powers that be'. There are volunteers. In the case of > the properties-maven-plugin, those are volunteers at the codehaus mojo > project, not the Apache Maven project. You really shouldn't let the > word 'alpha' bother you. > > On Mon, Feb 25, 2013 at 9:33 AM, Matthew Adams <[email protected]> > wrote: > > 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 <[email protected]> > 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: [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] > >> > >> > > > > > > -- > > mailto:[email protected] <[email protected]> > > skype:matthewadams12 > > googletalk:[email protected] > > http://matthewadams.me > > http://www.linkedin.com/in/matthewadams > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- mailto:[email protected] <[email protected]> skype:matthewadams12 googletalk:[email protected] http://matthewadams.me http://www.linkedin.com/in/matthewadams
