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]
