Plugins are development time tools and not deliverables to the customer.
So customer should not care how(by which plugin versions) artifacts are
build. Therefore never reveal versions of the build tools to the
customer :-)
Markku
On 02/26/2013 12:34 AM, Matthew Adams wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
