Re: dynamically select resources and apply filtering

[Baptiste MATHUS]

I *think* Ron means: using maven to produce your standard artifacts
(jar/war/ear ?), and then use pure ant somewhere in the process just before
deploying for a specific customer to do the replacements you're talking
about.

(By the way, invoking ant from maven (using antrun-maven-plugin) should
always be considered something bad and temporary. Writing or using a
dedicated maven plugin is the way to go).


2013/2/26 Jean-Noël Colin 

> Hi Ron,
>
> Do you mean invoking the ant plugin from the pom.xml file? I was wondering
> whether this was a good practice, or something to be kept only for
> situations where you really can't avoid it
>
> Best regards
>
> Jean-Noël
>
> On 25 Feb 2013, at 21:31, Ron Wheeler 
> wrote:
>
> > Why not move the production of the software to Maven and leave the
> assembly in Ant.
> > That would give you the best of both worlds.
> >
> >
> > On 25/02/2013 2:41 PM, Jean-Noël Colin wrote:
> >> Hi
> >>
> >> I'm trying to migrate my project from ant to maven, but I'm facing a
> few difficulties; I need to build my project for different environments
> (customers, so possibly a long list). In my ant project, I had several
> .properties file, one per customer; in this file, I had properties used to
> customize some config file; I managed to use resource filtering to achieve
> this.
> >>
> >> However, some properties defined a filename that needed to be copied to
> the war archive, but under a common name. For instance, I had several
> logos: logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; the
> source file name was specified in the properties file
> (customer1.properties, customer2.properties, customer3.properties), but the
> destination was always logo.jpg. How can I do that?
> >>
> >> Second, the properties file defines the name of the file (resources) to
> be filtered. For instance, I have a template for working with Spring
> Security in LDAP environment and another template when working when Active
> Directory; the customer properties file defined the name of the template to
> use, but in both cases, the result file needs to be
> applicationContext-security.xml. How can i achieve this? Or is there a way
> to define conditional profiles so that in the customer .properties file, I
> would say LDAP or AD, and based on that value, different profile would be
> used?
> >>
> >> Many thanks for your help
> >>
> >> Jean-Noël
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 
>

Re: Eclipse plugin and project references

[Baptiste MATHUS]

+1.
Even the maven-eclipse-plugin developers advice to use M2Eclipse instead.

Cheers


2013/2/25 Lyons, Roy 

> From my experience to date, it has proven far better to use the m2eclipse
> plugin and import the maven project directly.  It will then perform the
> build using maven...
>
> When people come to me with issues such as yours, I generally tell them to
> delete the project and re-import using m2eclipse (and never use mvn
> eclipse:eclipse again) -- and then everything works wonderfully for them.
>
>
> Thanks,
>
> Roy Lyons
>
>
>
>
> On 2/25/13 11:03 AM, "Stiffler82"  wrote:
>
> >I have a problem and can not find any support for it, also not in google.
> >I
> >created my own lib called "core.jar" and when I try to refer it as a
> >dependency in from my POM all works fine:
> >
> >   
> >  com.innosquared
> >  core
> >  1.1.10
> >   
> >
> >But when I run mvn eclipse:eclipse Maven creates wrong .classpath and
> >.project files. It resolves my jar as a java project instead of a jar
> >library. The following entry will be created in my classpath:
> >
> >  
> >
> >In my .projects file there is now:
> >
> > 
> >core
> >  
> >
> >I do not define anything in my Build-Cycle in POM, so I don't understand
> >this strange behaviour. What can I do to prevent Maven from resolving my
> >jar
> >as a java project and resolving it as a normal dependency instead?
> >
> >
> >
> >--
> >View this message in context:
> >
> http://maven.40175.n5.nabble.com/Eclipse-plugin-and-project-references-tp9
> >9838p5748396.html
> >Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >-
> >To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: dynamically select resources and apply filtering

[Jean-Noël Colin]

Hi Ron, 

Do you mean invoking the ant plugin from the pom.xml file? I was wondering 
whether this was a good practice, or something to be kept only for situations 
where you really can't avoid it

Best regards

Jean-Noël

On 25 Feb 2013, at 21:31, Ron Wheeler  wrote:

> Why not move the production of the software to Maven and leave the assembly 
> in Ant.
> That would give you the best of both worlds.
> 
> 
> On 25/02/2013 2:41 PM, Jean-Noël Colin wrote:
>> Hi
>> 
>> I'm trying to migrate my project from ant to maven, but I'm facing a few 
>> difficulties; I need to build my project for different environments 
>> (customers, so possibly a long list). In my ant project, I had several 
>> .properties file, one per customer; in this file, I had properties used to 
>> customize some config file; I managed to use resource filtering to achieve 
>> this.
>> 
>> However, some properties defined a filename that needed to be copied to the 
>> war archive, but under a common name. For instance, I had several logos: 
>> logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; the source file 
>> name was specified in the properties file (customer1.properties, 
>> customer2.properties, customer3.properties), but the destination was always 
>> logo.jpg. How can I do that?
>> 
>> Second, the properties file defines the name of the file (resources) to be 
>> filtered. For instance, I have a template for working with Spring Security 
>> in LDAP environment and another template when working when Active Directory; 
>> the customer properties file defined the name of the template to use, but in 
>> both cases, the result file needs to be applicationContext-security.xml. How 
>> can i achieve this? Or is there a way to define conditional profiles so that 
>> in the customer .properties file, I would say LDAP or AD, and based on that 
>> value, different profile would be used?
>> 
>> Many thanks for your help
>> 
>> Jean-Noël
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: dynamically select resources and apply filtering

[Jean-Noël Colin]

Hi

THanks for your suggestion, but I don't think it will work; for instance, I 
have to customize some springsecurity files that have to be included in the war 
file; those files are instantiated from templates that differ from environment 
to environment (LDAP, AD...); also, I don't want to copy all different logos to 
the war file, while only one should be used. 

I'm using jndi for db parameters for instance. 

basically, my process is: 
update code
for each environment (customer)
customize package
deploy package

so I can't think of an easy way to extract the configuration, and build the 
package only once. 

Best regards

Jean-Noël


On 25 Feb 2013, at 21:42, Adrien Rivard  wrote:

> On Mon, Feb 25, 2013 at 8:41 PM, Jean-Noël Colin  wrote:
> 
>> Hi
>> 
>> I'm trying to migrate my project from ant to maven, but I'm facing a few
>> difficulties; I need to build my project for different environments
>> (customers, so possibly a long list). In my ant project, I had several
>> .properties file, one per customer; in this file, I had properties used to
>> customize some config file; I managed to use resource filtering to achieve
>> this.
>> 
>> 
> The best way to handle this is to externalize your configuration.This way,
> you build one time one war that never changed, and you deploy this one
> along with the configuration file.
> Since you already have properties you should just externalize them (spring
> placeholder ..). Another option would be to use JNDI (more flexible but
> also more complicated IMO)
> 
> The second option is to multiple the number of project (1 master and a lots
> of nearly empty one for each customers.), but this work only if you know
> the configuration at build time.
> 
> The Thing to not do is to build one project multiple times, but each time
> different. (Basic maven rule : One project -> one artifact)
> 
> 
>> However, some properties defined a filename that needed to be copied to
>> the war archive, but under a common name. For instance, I had several
>> logos: logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; the
>> source file name was specified in the properties file
>> (customer1.properties, customer2.properties, customer3.properties), but the
>> destination was always logo.jpg. How can I do that?
>> 
>> On a webapp, I usually read it through a Servlet that read the path
> configured in the properties.
> 
> 
> 
>> Second, the properties file defines the name of the file (resources) to be
>> filtered. For instance, I have a template for working with Spring Security
>> in LDAP environment and another template when working when Active
>> Directory; the customer properties file defined the name of the template to
>> use, but in both cases, the result file needs to be
>> applicationContext-security.xml. How can i achieve this? Or is there a way
>> to define conditional profiles so that in the customer .properties file, I
>> would say LDAP or AD, and based on that value, different profile would be
>> used?
>> 
> 
> Spring can perfectly handle multiple authentication Manager, if only one is
> configured, one will failed, the other will work.
> 
> 
>> 
>> Many thanks for your help
>> 
>> Jean-Noël
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> Adrien Rivard

Re: Why is properties-maven-plugin still in alpha?

[Markku Saarela]

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 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 
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 

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 +
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 

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:


derby

derby
derby




org.codehaus.mojo
properties-maven-plugin



set-system-properties

initialize



derby.stream.error.field
java.lang.System.out













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 

Bordeaux JUG  Leader
Jenkins  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 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org







-
To unsubsc

maven-release-plugin : How to better manage cascading releases

[Andrei Pozolotin]

Hello, there!

I am curious : "How to better manage cascading releases"
for the following use case and what you think about possible solution:

#


Releasing core bundles and dependent bundles

Changing the API of a core bundle for an application requires a
rebuild of everything down the line in order to use the new feature.
For projects with large numbers of modules (platform, news) this is
a very lengthy process of splitting the bundles into dependency
phases, then for each phase, releasing a new version of each bundle,
updating the next phase's bundles with the newly released versions,
and then releasing next phase's bundles, etc, etc. This can be a
multiple hour process with Jenkins, compounded by the fact that you
can only release one sub-project at a time in a Git repository to
avoid push conflicts causing the build to fail. This process occurs
much more frequently than I would have originally assumed. Right now
I have a bash script that attempts to automate this for news with a
combination of the maven release and version plugins, but a better
generic solution would be very welcome.

*Proposal: Modify Jenkins maven release plugin with the following
behavior:*

 1.

Add a "Cascade release dependent projects" checkbox on release page

 2.

After the release completes, look for jobs that are explicitly
dependent on the pre-release snapshot version

 3.

Update these dependent modules with the newly release version,
and trigger a Maven release on them as well

 4.

Failing releases should be skipped, and then trigger a build
failure at the very end, with clearly noted messages as to which
sub-tree failed so the user can check the logs and manually
cascade release the subtree

Step c) would need some cycle detection to support scenarios where B
and C depend on A, but C also depends on B - both A and B would have
to be released before C could be released.

#

Thank you,

Andrei

Re: Compiling maven plugin and using it in the same project.

[Adrien Rivard]

On Mon, Feb 25, 2013 at 10:59 PM, Mariusz Pluciński <
plucinski.mari...@gmail.com> wrote:

> > Why would you want to build a plug-in each time?
> > Plug-ins are usually very stable and don't change from one year to the
> next.
> >
> > What is the underlying problem that you are trying to solve that
> requires a new plug-in each time.
>
>
> Yes, plugins used extensively by various people are usually very stable
> and don't change. But this is not my case.
>
> However, my plugins are not yet stable, and I am doing various changes in
> it. I said "plugins", as I currently have written two additional plugins
> for my project (maybe the third one will appear too). Anyway, they are not
> yet stable, and I often need to fix various things in them. Until now, I
> was doing it by two-steps: 1) compile & install my plugins; 2) compile my
> project. I have thought, that it would be good to have them both built in
> one step. But then, the problem described in first post appeared.
>
> If you are asking about what are those plugins: the one does
> bytecode-level modifications on compiled classes. It is quite similar to
> feature called 'relocations' available in maven-shade-plugin, but doing
> changes that Shade cannot do. The second one is the plugin for compiling
> classes written in Jasmin (JVM Assembler).
>
> The second thing is that I want to allow my users to build project only by
> typing "mvm package" and get everything ready. I can of course,
> write a README with detailed instruction and so on, but I would prefer to
> avoid it, if possible. Additionally, I would prefer not to mess local
> repository and keep everything in source code tree, as I did until now.
>
>
One simple solution to this problem would be to use a MRM (maven repository
manager)
You deploy the plugins in it, and the users just use them as any others
maven plugins.
This make sense particulary if you are the only one to modify it and if the
plugins lifecyle are decoupled from the project lifecyle.



> I have created quite dirty solution using exec-plugin to do two calls of
> "mvn" in sequence. But it looks horrible and I will use it only as a last
> resort.
>
>
> > Are you using Maven 2 or 3? I'm guessing 2.x…
>
> No, I am using latest version of Maven 3:
>
> $ mvn -version
> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: /usr/share/maven
> Java version: 1.7.0_10, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre
> Default locale: pl_PL, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"
>
> I should have put this into my first post, sorry.
>
>
> > What version of Maven? As far as I know, this should generally work
> > with m3 but not m2.
>
>
> Sorry, but in my case it does not work. Were there any particular changes
> in Maven, introduced to make it possible?
>
> Thanks,
> Mariusz Plucinski
>
>
>
> Wiadomość napisana przez Ron Wheeler  w
> dniu 25 lut 2013, o godz. 21:55:
>
> > Why would you want to build a plug-in each time?
> > Plug-ins are usually very stable and don't change from one year to the
> next.
> >
> > What is the underlying problem that you are trying to solve that
> requires a new plug-in each time.
> >
> >
> >
> > On 25/02/2013 3:18 PM, Mariusz Pluciński wrote:
> >> Hello,
> >>
> >> I would like to ask, is there any way to have two project: maven plugin
> and project using the plugin as submodules of the same root project, and
> compile them just by "mvn package" (orinstall) called for root project?
> >>
> >> I have tried to do it this way, but got an error:
> >>
> >> Unresolveable build extension: Plugin  or
> one of its dependencies could not be resolved: Could not find artifact
> .
> >>
> >> In case of dependencies, there is no problem to find artifact being
> submodule parallel to currently built project - maven understands, that it
> should build e.g. dependency jar before building the dependent one. Is it
> possible to make him do this with plugin?
> >>
> >> Best regards,
> >> Mariusz Pluciński
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
> >
> >
> > --
> > Ron Wheeler
> > President
> > Artifact Software Inc
> > email: rwhee...@artifact-software.com
> > skype: ronaldmwheeler
> > phone: 866-970-2435, ext 102
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Adrien Rivard

Re: Why is properties-maven-plugin still in alpha?

[Matthew Adams]

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 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 
> 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 
> 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 +
> >> > 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 
> 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:
> >> > > > >
> >> > > > > 
> >> > > > > derby
> >> > > > > 
> >> > > > > derby
> >> > > > > derby
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > org.codehaus.mojo
> >> > > > > properties-maven-plugin
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > set-system-properties
> >> > > > > 
> >> > > > > initialize
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > derby.stream.error.field
> >> > > > > java.lang.System.out
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > > 
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > 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

[ANN] Flexmojos 6.0.0 Relesed

[christofer.d...@c-ware.de]

Flexmojos, the maven plugin for building applications using Adobe Flex / Apache 
Flex, has just been released in version 6.0.0.

The main difference to older Flexmojos releases, is that this version is able 
to use Flex SDKs generated by the Apache Mavenizer tool. This way you can use 
Flexmojos to build applications with any Flex version starting with Adobe Flex 
2.0 up to Apache Flex 4.9.

The plugin has been deployed to: 
https://oss.sonatype.org/content/groups/public/net/flexmojos/oss/

If migrating from earlier versions, please have a look at the migration how-to 
page: https://flexmojos.atlassian.net/wiki/display/FLEXMOJOS/Migrating+to+6.x
The Flexmojos wiki should also provide enough information for new users to get 
up to speed pretty fast: https://flexmojos.atlassian.net/wiki/display/FLEXMOJOS

Re: Compiling maven plugin and using it in the same project.

[Mariusz Pluciński]

> Why would you want to build a plug-in each time?
> Plug-ins are usually very stable and don't change from one year to the next.
> 
> What is the underlying problem that you are trying to solve that requires a 
> new plug-in each time.


Yes, plugins used extensively by various people are usually very stable and 
don't change. But this is not my case.

However, my plugins are not yet stable, and I am doing various changes in it. I 
said "plugins", as I currently have written two additional plugins for my 
project (maybe the third one will appear too). Anyway, they are not yet stable, 
and I often need to fix various things in them. Until now, I was doing it by 
two-steps: 1) compile & install my plugins; 2) compile my project. I have 
thought, that it would be good to have them both built in one step. But then, 
the problem described in first post appeared.

If you are asking about what are those plugins: the one does bytecode-level 
modifications on compiled classes. It is quite similar to feature called 
'relocations' available in maven-shade-plugin, but doing changes that Shade 
cannot do. The second one is the plugin for compiling classes written in Jasmin 
(JVM Assembler).

The second thing is that I want to allow my users to build project only by 
typing "mvm package" and get everything ready. I can of course, write a 
README with detailed instruction and so on, but I would prefer to avoid it, if 
possible. Additionally, I would prefer not to mess local repository and keep 
everything in source code tree, as I did until now.

I have created quite dirty solution using exec-plugin to do two calls of "mvn" 
in sequence. But it looks horrible and I will use it only as a last resort.


> Are you using Maven 2 or 3? I'm guessing 2.x…

No, I am using latest version of Maven 3:

$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_10, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre
Default locale: pl_PL, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.2", arch: "x86_64", family: "mac"

I should have put this into my first post, sorry.


> What version of Maven? As far as I know, this should generally work
> with m3 but not m2.


Sorry, but in my case it does not work. Were there any particular changes in 
Maven, introduced to make it possible?

Thanks,
Mariusz Plucinski



Wiadomość napisana przez Ron Wheeler  w dniu 25 
lut 2013, o godz. 21:55:

> Why would you want to build a plug-in each time?
> Plug-ins are usually very stable and don't change from one year to the next.
> 
> What is the underlying problem that you are trying to solve that requires a 
> new plug-in each time.
> 
> 
> 
> On 25/02/2013 3:18 PM, Mariusz Pluciński wrote:
>> Hello,
>> 
>> I would like to ask, is there any way to have two project: maven plugin and 
>> project using the plugin as submodules of the same root project, and compile 
>> them just by "mvn package" (orinstall) called for root project?
>> 
>> I have tried to do it this way, but got an error:
>> 
>> Unresolveable build extension: Plugin  or one of 
>> its dependencies could not be resolved: Could not find artifact > same id>.
>> 
>> In case of dependencies, there is no problem to find artifact being 
>> submodule parallel to currently built project - maven understands, that it 
>> should build e.g. dependency jar before building the dependent one. Is it 
>> possible to make him do this with plugin?
>> 
>> Best regards,
>> Mariusz Pluciński
>> 
>> 
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Compiling maven plugin and using it in the same project.

[Wayne Fay]

> I would like to ask, is there any way to have two project: maven plugin
> and project using the plugin as submodules of the same root project, and
> compile them just by "mvn package" (orinstall) called for root project?

Anders beat me to it...

What version of Maven? As far as I know, this should generally work
with m3 but not m2.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Compiling maven plugin and using it in the same project.

[Anders Hammar]

Are you using Maven 2 or 3? I'm guessing 2.x...

/Anders


On Mon, Feb 25, 2013 at 9:18 PM, Mariusz Pluciński <
plucinski.mari...@gmail.com> wrote:

> Hello,
>
> I would like to ask, is there any way to have two project: maven plugin
> and project using the plugin as submodules of the same root project, and
> compile them just by "mvn package" (orinstall) called for root project?
>
> I have tried to do it this way, but got an error:
>
> Unresolveable build extension: Plugin  or one
> of its dependencies could not be resolved: Could not find artifact  the same id>.
>
> In case of dependencies, there is no problem to find artifact being
> submodule parallel to currently built project - maven understands, that it
> should build e.g. dependency jar before building the dependent one. Is it
> possible to make him do this with plugin?
>
> Best regards,
> Mariusz Pluciński
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Compiling maven plugin and using it in the same project.

[Ron Wheeler]

Why would you want to build a plug-in each time?
Plug-ins are usually very stable and don't change from one year to the next.

What is the underlying problem that you are trying to solve that 
requires a new plug-in each time.




On 25/02/2013 3:18 PM, Mariusz Pluciński wrote:

Hello,

I would like to ask, is there any way to have two project: maven plugin and project using 
the plugin as submodules of the same root project, and compile them just by "mvn 
package" (orinstall) called for root project?

I have tried to do it this way, but got an error:

Unresolveable build extension: Plugin  or one of its 
dependencies could not be resolved: Could not find artifact .

In case of dependencies, there is no problem to find artifact being submodule 
parallel to currently built project - maven understands, that it should build 
e.g. dependency jar before building the dependent one. Is it possible to make 
him do this with plugin?

Best regards,
Mariusz Pluciński


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: dynamically select resources and apply filtering

[Adrien Rivard]

On Mon, Feb 25, 2013 at 8:41 PM, Jean-Noël Colin  wrote:

> Hi
>
> I'm trying to migrate my project from ant to maven, but I'm facing a few
> difficulties; I need to build my project for different environments
> (customers, so possibly a long list). In my ant project, I had several
> .properties file, one per customer; in this file, I had properties used to
> customize some config file; I managed to use resource filtering to achieve
> this.
>
>
The best way to handle this is to externalize your configuration.This way,
you build one time one war that never changed, and you deploy this one
along with the configuration file.
Since you already have properties you should just externalize them (spring
placeholder ..). Another option would be to use JNDI (more flexible but
also more complicated IMO)

The second option is to multiple the number of project (1 master and a lots
of nearly empty one for each customers.), but this work only if you know
the configuration at build time.

The Thing to not do is to build one project multiple times, but each time
different. (Basic maven rule : One project -> one artifact)


> However, some properties defined a filename that needed to be copied to
> the war archive, but under a common name. For instance, I had several
> logos: logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; the
> source file name was specified in the properties file
> (customer1.properties, customer2.properties, customer3.properties), but the
> destination was always logo.jpg. How can I do that?
>
> On a webapp, I usually read it through a Servlet that read the path
configured in the properties.



> Second, the properties file defines the name of the file (resources) to be
> filtered. For instance, I have a template for working with Spring Security
> in LDAP environment and another template when working when Active
> Directory; the customer properties file defined the name of the template to
> use, but in both cases, the result file needs to be
> applicationContext-security.xml. How can i achieve this? Or is there a way
> to define conditional profiles so that in the customer .properties file, I
> would say LDAP or AD, and based on that value, different profile would be
> used?
>

Spring can perfectly handle multiple authentication Manager, if only one is
configured, one will failed, the other will work.


>
> Many thanks for your help
>
> Jean-Noël
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Adrien Rivard

Re: dynamically select resources and apply filtering

[Ron Wheeler]

Why not move the production of the software to Maven and leave the 
assembly in Ant.

That would give you the best of both worlds.


On 25/02/2013 2:41 PM, Jean-Noël Colin wrote:

Hi

I'm trying to migrate my project from ant to maven, but I'm facing a few 
difficulties; I need to build my project for different environments (customers, 
so possibly a long list). In my ant project, I had several .properties file, 
one per customer; in this file, I had properties used to customize some config 
file; I managed to use resource filtering to achieve this.

However, some properties defined a filename that needed to be copied to the war 
archive, but under a common name. For instance, I had several logos: 
logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; the source file 
name was specified in the properties file (customer1.properties, 
customer2.properties, customer3.properties), but the destination was always 
logo.jpg. How can I do that?

Second, the properties file defines the name of the file (resources) to be 
filtered. For instance, I have a template for working with Spring Security in 
LDAP environment and another template when working when Active Directory; the 
customer properties file defined the name of the template to use, but in both 
cases, the result file needs to be applicationContext-security.xml. How can i 
achieve this? Or is there a way to define conditional profiles so that in the 
customer .properties file, I would say LDAP or AD, and based on that value, 
different profile would be used?

Many thanks for your help

Jean-Noël


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Compiling maven plugin and using it in the same project.

[Mariusz Pluciński]

Hello,

I would like to ask, is there any way to have two project: maven plugin and 
project using the plugin as submodules of the same root project, and compile 
them just by "mvn package" (orinstall) called for root project?

I have tried to do it this way, but got an error:

Unresolveable build extension: Plugin  or one of 
its dependencies could not be resolved: Could not find artifact .

In case of dependencies, there is no problem to find artifact being submodule 
parallel to currently built project - maven understands, that it should build 
e.g. dependency jar before building the dependent one. Is it possible to make 
him do this with plugin?

Best regards,
Mariusz Pluciński


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

dynamically select resources and apply filtering

[Jean-Noël Colin]

Hi

I'm trying to migrate my project from ant to maven, but I'm facing a few 
difficulties; I need to build my project for different environments (customers, 
so possibly a long list). In my ant project, I had several .properties file, 
one per customer; in this file, I had properties used to customize some config 
file; I managed to use resource filtering to achieve this.

However, some properties defined a filename that needed to be copied to the war 
archive, but under a common name. For instance, I had several logos: 
logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; the source file 
name was specified in the properties file (customer1.properties, 
customer2.properties, customer3.properties), but the destination was always 
logo.jpg. How can I do that? 

Second, the properties file defines the name of the file (resources) to be 
filtered. For instance, I have a template for working with Spring Security in 
LDAP environment and another template when working when Active Directory; the 
customer properties file defined the name of the template to use, but in both 
cases, the result file needs to be applicationContext-security.xml. How can i 
achieve this? Or is there a way to define conditional profiles so that in the 
customer .properties file, I would say LDAP or AD, and based on that value, 
different profile would be used? 

Many thanks for your help

Jean-Noël


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Eclipse plugin and project references

[Lyons, Roy]

>From my experience to date, it has proven far better to use the m2eclipse
plugin and import the maven project directly.  It will then perform the
build using maven...

When people come to me with issues such as yours, I generally tell them to
delete the project and re-import using m2eclipse (and never use mvn
eclipse:eclipse again) -- and then everything works wonderfully for them.


Thanks,

Roy Lyons




On 2/25/13 11:03 AM, "Stiffler82"  wrote:

>I have a problem and can not find any support for it, also not in google.
>I
>created my own lib called "core.jar" and when I try to refer it as a
>dependency in from my POM all works fine:
>
>   
>  com.innosquared
>  core
>  1.1.10
>   
>
>But when I run mvn eclipse:eclipse Maven creates wrong .classpath and
>.project files. It resolves my jar as a java project instead of a jar
>library. The following entry will be created in my classpath:
>
>  
>
>In my .projects file there is now:
>
> 
>core
>  
>
>I do not define anything in my Build-Cycle in POM, so I don't understand
>this strange behaviour. What can I do to prevent Maven from resolving my
>jar
>as a java project and resolving it as a normal dependency instead?
>
>
>
>--
>View this message in context:
>http://maven.40175.n5.nabble.com/Eclipse-plugin-and-project-references-tp9
>9838p5748396.html
>Sent from the Maven - Users mailing list archive at Nabble.com.
>
>-
>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>For additional commands, e-mail: users-h...@maven.apache.org
>


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Eclipse plugin and project references

[Andreas Gudian]

The plugin will always resolve the artifact as eclipse project, if it
detects that project within your eclipse workspace, or if it is in the
reactor (i.e. part of the maven build).
Remove the other project from the workspace and you should be fine. Or make
sure that "core" now has a new version (it should be some -SNAPSHOT version
after you created that 1.1.10 version, right?)

Andreas

2013/2/25 Stiffler82 

> I have a problem and can not find any support for it, also not in google. I
> created my own lib called "core.jar" and when I try to refer it as a
> dependency in from my POM all works fine:
>
> 
>com.innosquared
>core
>1.1.10
> 
>
> But when I run mvn eclipse:eclipse Maven creates wrong .classpath and
> .project files. It resolves my jar as a java project instead of a jar
> library. The following entry will be created in my classpath:
>
>   
>
> In my .projects file there is now:
>
>  
> core
>   
>
> I do not define anything in my Build-Cycle in POM, so I don't understand
> this strange behaviour. What can I do to prevent Maven from resolving my
> jar
> as a java project and resolving it as a normal dependency instead?
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Eclipse-plugin-and-project-references-tp99838p5748396.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Eclipse plugin and project references

[Stiffler82]

I have a problem and can not find any support for it, also not in google. I
created my own lib called "core.jar" and when I try to refer it as a
dependency in from my POM all works fine: 


   com.innosquared
   core
   1.1.10


But when I run mvn eclipse:eclipse Maven creates wrong .classpath and
.project files. It resolves my jar as a java project instead of a jar
library. The following entry will be created in my classpath:

  

In my .projects file there is now:

 
core
  

I do not define anything in my Build-Cycle in POM, so I don't understand
this strange behaviour. What can I do to prevent Maven from resolving my jar
as a java project and resolving it as a normal dependency instead?



--
View this message in context: 
http://maven.40175.n5.nabble.com/Eclipse-plugin-and-project-references-tp99838p5748396.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Tomcat Maven plugin 2.1

[Anthony Dahanne]

OK, it's much clearer now, executing the archetype and running mvn
tomcat7:run and browsing to localhost:9090
Yes, the analogy between the executable war and jenkins.war is good example.
Thank you Olivier and Stephen for your time, I now have a very good
alternative to jetty for my dev. routine;
Regards,
Anthony




On Mon, Feb 25, 2013 at 11:36 AM, Olivier Lamy  wrote:

> just test the archetype:
> http://tomcat.apache.org/maven-plugin-2.1/archetype.html
>
>
> 2013/2/25 Olivier Lamy :
> > 2013/2/25 Anthony Dahanne :
> >> Hello Olivier,
> >> and thanks for the new release !
> >> I am used to mvn jetty:run so that I can quickly embed a war without
> >> configuring a servlet container ; and, reading the documentation of
> Apache
> >> Tomcat Maven executable war,
> >> http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I
> >> understand there is no equivalent of mvn jetty:run, right ?
> > No, tomcat6:run or tomcat7:run do the same. ( see
> > http://tomcat.apache.org/maven-plugin-2.1/run-mojo-features.html) (doh
> > I see some filtered variables in the doc I will fix that :-) )
> >> I understand I have to first build the executable war and launch it with
> >> java -jar to get the same behavior as mvn jetty:run ?
> > This feature is just to build a runnable jar/war. The build jar will
> > contain your war(s) and all tomcat needed classes.
> > So you will be able to just run: java -jar yourfile.jar
> >
> >> Or can mvn tomcat7:run be configured to launch an embedded servlet
> >> container ?
> > yes it do that.
> >>
> >> Thanks in advance for your answers,
> >> Regards,
> >> Anthony
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy 
> wrote:
> >>
> >>> Hi,
> >>>
> >>> The Apache Tomcat is pleased to announce the release of the 2.1
> >>> version. This plugin can used to run your war project inside an
> >>> embeded Apache Tomcat and to deploy your project to a running Apache
> >>> Tomcat instance.
> >>>
> >>> Documentation available:
> >>> http://tomcat.apache.org/maven-plugin-2.1/index.html
> >>>
> >>>
> >>> Release Notes - Apache Tomcat Maven Plugin - Version 2.1
> >>>
> >>>
> >>> ** Bug
> >>> * [MTOMCAT-61] - maven tomcat:run ignores the
> >>> useSeperateTomcatClassloaded when using serverXml property
> >>> * [MTOMCAT-119] - tomcat7:run-war fails because it expects
> >>> META-INF\context.xml
> >>> * [MTOMCAT-128] - The plugin ignores and/or parses web.xml
> >>> incorrectally when using tomcatWebXml option
> >>> * [MTOMCAT-173] - Direct dependencies are not added to classpath
> >>> * [MTOMCAT-175] - warDirectory property has wrong standard value
> >>> in release version 2.0
> >>> * [MTOMCAT-179] - Null pointer dereference in RunMojo
> >>> * [MTOMCAT-180] - Allow hostName and alias to be configured for
> >>> tomcat6:run etc
> >>> * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO
> >>> * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes
> >>> * [MTOMCAT-186] - Closing executable JAR does not call
> >>> ServletContextListener.contextDestroyed()
> >>> * [MTOMCAT-194] - Odd error message in switching from Codehaus to
> >>> Maven Tomcat6 plugin
> >>> * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war
> projects
> >>> * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only
> goals
> >>> * [MTOMCAT-206] - Runtime dependencies within multi module
> >>> projects are not loaded.
> >>>
> >>>
> >>> ** Improvement
> >>> * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals
> >>> * [MTOMCAT-188] - Allow for the creation of a war that is both
> >>> executable and deployable
> >>> * [MTOMCAT-190] - Client Certificate settings for connector
> >>> * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin
> >>> * [MTOMCAT-192] - Website text cleanup
> >>> * [MTOMCAT-199] - Text cleanup of goal definitions
> >>> * [MTOMCAT-200] - Tomcat7:redeploy
> >>> * [MTOMCAT-208] - JaCoCo instrumentation errors when running
> >>> StandaloneWarMojo
> >>>
> >>> ** New Feature
> >>> * [MTOMCAT-163] - No undeploy goal
> >>>
> >>> ** Question
> >>> * [MTOMCAT-187] - Scan resources executing run goal
> >>>
> >>> Have Fun,
> >>>
> >>> --
> >>> The Apache Tomcat Team.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: users-h...@maven.apache.org
> >>>
> >>>
> >
> >
> >
> > --
> > Olivier Lamy
> > Talend: http://coders.talend.com
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: [ANN] Apache Tomcat Maven plugin 2.1

[Olivier Lamy]

just test the archetype:
http://tomcat.apache.org/maven-plugin-2.1/archetype.html


2013/2/25 Olivier Lamy :
> 2013/2/25 Anthony Dahanne :
>> Hello Olivier,
>> and thanks for the new release !
>> I am used to mvn jetty:run so that I can quickly embed a war without
>> configuring a servlet container ; and, reading the documentation of Apache
>> Tomcat Maven executable war,
>> http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I
>> understand there is no equivalent of mvn jetty:run, right ?
> No, tomcat6:run or tomcat7:run do the same. ( see
> http://tomcat.apache.org/maven-plugin-2.1/run-mojo-features.html) (doh
> I see some filtered variables in the doc I will fix that :-) )
>> I understand I have to first build the executable war and launch it with
>> java -jar to get the same behavior as mvn jetty:run ?
> This feature is just to build a runnable jar/war. The build jar will
> contain your war(s) and all tomcat needed classes.
> So you will be able to just run: java -jar yourfile.jar
>
>> Or can mvn tomcat7:run be configured to launch an embedded servlet
>> container ?
> yes it do that.
>>
>> Thanks in advance for your answers,
>> Regards,
>> Anthony
>>
>>
>>
>>
>>
>> On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy  wrote:
>>
>>> Hi,
>>>
>>> The Apache Tomcat is pleased to announce the release of the 2.1
>>> version. This plugin can used to run your war project inside an
>>> embeded Apache Tomcat and to deploy your project to a running Apache
>>> Tomcat instance.
>>>
>>> Documentation available:
>>> http://tomcat.apache.org/maven-plugin-2.1/index.html
>>>
>>>
>>> Release Notes - Apache Tomcat Maven Plugin - Version 2.1
>>>
>>>
>>> ** Bug
>>> * [MTOMCAT-61] - maven tomcat:run ignores the
>>> useSeperateTomcatClassloaded when using serverXml property
>>> * [MTOMCAT-119] - tomcat7:run-war fails because it expects
>>> META-INF\context.xml
>>> * [MTOMCAT-128] - The plugin ignores and/or parses web.xml
>>> incorrectally when using tomcatWebXml option
>>> * [MTOMCAT-173] - Direct dependencies are not added to classpath
>>> * [MTOMCAT-175] - warDirectory property has wrong standard value
>>> in release version 2.0
>>> * [MTOMCAT-179] - Null pointer dereference in RunMojo
>>> * [MTOMCAT-180] - Allow hostName and alias to be configured for
>>> tomcat6:run etc
>>> * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO
>>> * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes
>>> * [MTOMCAT-186] - Closing executable JAR does not call
>>> ServletContextListener.contextDestroyed()
>>> * [MTOMCAT-194] - Odd error message in switching from Codehaus to
>>> Maven Tomcat6 plugin
>>> * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war projects
>>> * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only goals
>>> * [MTOMCAT-206] - Runtime dependencies within multi module
>>> projects are not loaded.
>>>
>>>
>>> ** Improvement
>>> * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals
>>> * [MTOMCAT-188] - Allow for the creation of a war that is both
>>> executable and deployable
>>> * [MTOMCAT-190] - Client Certificate settings for connector
>>> * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin
>>> * [MTOMCAT-192] - Website text cleanup
>>> * [MTOMCAT-199] - Text cleanup of goal definitions
>>> * [MTOMCAT-200] - Tomcat7:redeploy
>>> * [MTOMCAT-208] - JaCoCo instrumentation errors when running
>>> StandaloneWarMojo
>>>
>>> ** New Feature
>>> * [MTOMCAT-163] - No undeploy goal
>>>
>>> ** Question
>>> * [MTOMCAT-187] - Scan resources executing run goal
>>>
>>> Have Fun,
>>>
>>> --
>>> The Apache Tomcat Team.
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Tomcat Maven plugin 2.1

[Stephen Connolly]

On 25 February 2013 16:29, Anthony Dahanne wrote:

> Hello Olivier,
> and thanks for the new release !
> I am used to mvn jetty:run so that I can quickly embed a war without
> configuring a servlet container ; and, reading the documentation of Apache
> Tomcat Maven executable war,
> http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I
> understand there is no equivalent of mvn jetty:run, right ?
>

http://tomcat.apache.org/maven-plugin-2.1/tomcat7-maven-plugin/run-mojo.htmlis
the equivalent of jetty:run

the one you list creates a executable .war much like jenkins.war


> I understand I have to first build the executable war and launch it with
> java -jar to get the same behavior as mvn jetty:run ?
> Or can mvn tomcat7:run be configured to launch an embedded servlet
> container ?
>
> Thanks in advance for your answers,
> Regards,
> Anthony
>
>
>
>
>
> On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy  wrote:
>
> > Hi,
> >
> > The Apache Tomcat is pleased to announce the release of the 2.1
> > version. This plugin can used to run your war project inside an
> > embeded Apache Tomcat and to deploy your project to a running Apache
> > Tomcat instance.
> >
> > Documentation available:
> > http://tomcat.apache.org/maven-plugin-2.1/index.html
> >
> >
> > Release Notes - Apache Tomcat Maven Plugin - Version 2.1
> >
> >
> > ** Bug
> > * [MTOMCAT-61] - maven tomcat:run ignores the
> > useSeperateTomcatClassloaded when using serverXml property
> > * [MTOMCAT-119] - tomcat7:run-war fails because it expects
> > META-INF\context.xml
> > * [MTOMCAT-128] - The plugin ignores and/or parses web.xml
> > incorrectally when using tomcatWebXml option
> > * [MTOMCAT-173] - Direct dependencies are not added to classpath
> > * [MTOMCAT-175] - warDirectory property has wrong standard value
> > in release version 2.0
> > * [MTOMCAT-179] - Null pointer dereference in RunMojo
> > * [MTOMCAT-180] - Allow hostName and alias to be configured for
> > tomcat6:run etc
> > * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO
> > * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes
> > * [MTOMCAT-186] - Closing executable JAR does not call
> > ServletContextListener.contextDestroyed()
> > * [MTOMCAT-194] - Odd error message in switching from Codehaus to
> > Maven Tomcat6 plugin
> > * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war projects
> > * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only
> goals
> > * [MTOMCAT-206] - Runtime dependencies within multi module
> > projects are not loaded.
> >
> >
> > ** Improvement
> > * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals
> > * [MTOMCAT-188] - Allow for the creation of a war that is both
> > executable and deployable
> > * [MTOMCAT-190] - Client Certificate settings for connector
> > * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin
> > * [MTOMCAT-192] - Website text cleanup
> > * [MTOMCAT-199] - Text cleanup of goal definitions
> > * [MTOMCAT-200] - Tomcat7:redeploy
> > * [MTOMCAT-208] - JaCoCo instrumentation errors when running
> > StandaloneWarMojo
> >
> > ** New Feature
> > * [MTOMCAT-163] - No undeploy goal
> >
> > ** Question
> > * [MTOMCAT-187] - Scan resources executing run goal
> >
> > Have Fun,
> >
> > --
> > The Apache Tomcat Team.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: [ANN] Apache Tomcat Maven plugin 2.1

[Olivier Lamy]

2013/2/25 Anthony Dahanne :
> Hello Olivier,
> and thanks for the new release !
> I am used to mvn jetty:run so that I can quickly embed a war without
> configuring a servlet container ; and, reading the documentation of Apache
> Tomcat Maven executable war,
> http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I
> understand there is no equivalent of mvn jetty:run, right ?
No, tomcat6:run or tomcat7:run do the same. ( see
http://tomcat.apache.org/maven-plugin-2.1/run-mojo-features.html) (doh
I see some filtered variables in the doc I will fix that :-) )
> I understand I have to first build the executable war and launch it with
> java -jar to get the same behavior as mvn jetty:run ?
This feature is just to build a runnable jar/war. The build jar will
contain your war(s) and all tomcat needed classes.
So you will be able to just run: java -jar yourfile.jar

> Or can mvn tomcat7:run be configured to launch an embedded servlet
> container ?
yes it do that.
>
> Thanks in advance for your answers,
> Regards,
> Anthony
>
>
>
>
>
> On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy  wrote:
>
>> Hi,
>>
>> The Apache Tomcat is pleased to announce the release of the 2.1
>> version. This plugin can used to run your war project inside an
>> embeded Apache Tomcat and to deploy your project to a running Apache
>> Tomcat instance.
>>
>> Documentation available:
>> http://tomcat.apache.org/maven-plugin-2.1/index.html
>>
>>
>> Release Notes - Apache Tomcat Maven Plugin - Version 2.1
>>
>>
>> ** Bug
>> * [MTOMCAT-61] - maven tomcat:run ignores the
>> useSeperateTomcatClassloaded when using serverXml property
>> * [MTOMCAT-119] - tomcat7:run-war fails because it expects
>> META-INF\context.xml
>> * [MTOMCAT-128] - The plugin ignores and/or parses web.xml
>> incorrectally when using tomcatWebXml option
>> * [MTOMCAT-173] - Direct dependencies are not added to classpath
>> * [MTOMCAT-175] - warDirectory property has wrong standard value
>> in release version 2.0
>> * [MTOMCAT-179] - Null pointer dereference in RunMojo
>> * [MTOMCAT-180] - Allow hostName and alias to be configured for
>> tomcat6:run etc
>> * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO
>> * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes
>> * [MTOMCAT-186] - Closing executable JAR does not call
>> ServletContextListener.contextDestroyed()
>> * [MTOMCAT-194] - Odd error message in switching from Codehaus to
>> Maven Tomcat6 plugin
>> * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war projects
>> * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only goals
>> * [MTOMCAT-206] - Runtime dependencies within multi module
>> projects are not loaded.
>>
>>
>> ** Improvement
>> * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals
>> * [MTOMCAT-188] - Allow for the creation of a war that is both
>> executable and deployable
>> * [MTOMCAT-190] - Client Certificate settings for connector
>> * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin
>> * [MTOMCAT-192] - Website text cleanup
>> * [MTOMCAT-199] - Text cleanup of goal definitions
>> * [MTOMCAT-200] - Tomcat7:redeploy
>> * [MTOMCAT-208] - JaCoCo instrumentation errors when running
>> StandaloneWarMojo
>>
>> ** New Feature
>> * [MTOMCAT-163] - No undeploy goal
>>
>> ** Question
>> * [MTOMCAT-187] - Scan resources executing run goal
>>
>> Have Fun,
>>
>> --
>> The Apache Tomcat Team.
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>



--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [ANN] Apache Tomcat Maven plugin 2.1

[Anthony Dahanne]

Hello Olivier,
and thanks for the new release !
I am used to mvn jetty:run so that I can quickly embed a war without
configuring a servlet container ; and, reading the documentation of Apache
Tomcat Maven executable war,
http://tomcat.apache.org/maven-plugin-2.1/executable-war-jar.html , I
understand there is no equivalent of mvn jetty:run, right ?
I understand I have to first build the executable war and launch it with
java -jar to get the same behavior as mvn jetty:run ?
Or can mvn tomcat7:run be configured to launch an embedded servlet
container ?

Thanks in advance for your answers,
Regards,
Anthony





On Mon, Feb 25, 2013 at 10:40 AM, Olivier Lamy  wrote:

> Hi,
>
> The Apache Tomcat is pleased to announce the release of the 2.1
> version. This plugin can used to run your war project inside an
> embeded Apache Tomcat and to deploy your project to a running Apache
> Tomcat instance.
>
> Documentation available:
> http://tomcat.apache.org/maven-plugin-2.1/index.html
>
>
> Release Notes - Apache Tomcat Maven Plugin - Version 2.1
>
>
> ** Bug
> * [MTOMCAT-61] - maven tomcat:run ignores the
> useSeperateTomcatClassloaded when using serverXml property
> * [MTOMCAT-119] - tomcat7:run-war fails because it expects
> META-INF\context.xml
> * [MTOMCAT-128] - The plugin ignores and/or parses web.xml
> incorrectally when using tomcatWebXml option
> * [MTOMCAT-173] - Direct dependencies are not added to classpath
> * [MTOMCAT-175] - warDirectory property has wrong standard value
> in release version 2.0
> * [MTOMCAT-179] - Null pointer dereference in RunMojo
> * [MTOMCAT-180] - Allow hostName and alias to be configured for
> tomcat6:run etc
> * [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO
> * [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes
> * [MTOMCAT-186] - Closing executable JAR does not call
> ServletContextListener.contextDestroyed()
> * [MTOMCAT-194] - Odd error message in switching from Codehaus to
> Maven Tomcat6 plugin
> * [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war projects
> * [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only goals
> * [MTOMCAT-206] - Runtime dependencies within multi module
> projects are not loaded.
>
>
> ** Improvement
> * [MTOMCAT-99] - Make redeploy goal consistent with deploy goals
> * [MTOMCAT-188] - Allow for the creation of a war that is both
> executable and deployable
> * [MTOMCAT-190] - Client Certificate settings for connector
> * [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin
> * [MTOMCAT-192] - Website text cleanup
> * [MTOMCAT-199] - Text cleanup of goal definitions
> * [MTOMCAT-200] - Tomcat7:redeploy
> * [MTOMCAT-208] - JaCoCo instrumentation errors when running
> StandaloneWarMojo
>
> ** New Feature
> * [MTOMCAT-163] - No undeploy goal
>
> ** Question
> * [MTOMCAT-187] - Scan resources executing run goal
>
> Have Fun,
>
> --
> The Apache Tomcat Team.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Why is properties-maven-plugin still in alpha?

[Benson Margulies]

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  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  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 +
>> > 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  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:
>> > > > >
>> > > > > 
>> > > > > derby
>> > > > > 
>> > > > > derby
>> > > > > derby
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > org.codehaus.mojo
>> > > > > properties-maven-plugin
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > set-system-properties
>> > > > > 
>> > > > > initialize
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > derby.stream.error.field
>> > > > > java.lang.System.out
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > > 
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > 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 
>> > > > >> 
>> > > > >> Bordeaux JUG  Leader
>> > > > >> Jenkins  community member & plugin
>> commiter
>> > > > >>
>> > > > >>
>> > > > >>
>> > > > >> On Fri, Feb 22, 2013 at 4:39 PM, Matthew Adams <
>> > > matt...@matthewadams.me
>> > >
>> 

[ANN] Apache Tomcat Maven plugin 2.1

[Olivier Lamy]

Hi,

The Apache Tomcat is pleased to announce the release of the 2.1
version. This plugin can used to run your war project inside an
embeded Apache Tomcat and to deploy your project to a running Apache
Tomcat instance.

Documentation available: http://tomcat.apache.org/maven-plugin-2.1/index.html


Release Notes - Apache Tomcat Maven Plugin - Version 2.1


** Bug
* [MTOMCAT-61] - maven tomcat:run ignores the
useSeperateTomcatClassloaded when using serverXml property
* [MTOMCAT-119] - tomcat7:run-war fails because it expects
META-INF\context.xml
* [MTOMCAT-128] - The plugin ignores and/or parses web.xml
incorrectally when using tomcatWebXml option
* [MTOMCAT-173] - Direct dependencies are not added to classpath
* [MTOMCAT-175] - warDirectory property has wrong standard value
in release version 2.0
* [MTOMCAT-179] - Null pointer dereference in RunMojo
* [MTOMCAT-180] - Allow hostName and alias to be configured for
tomcat6:run etc
* [MTOMCAT-182] - Typo in Tomcat6 AbstractRunWarMojo MOJO
* [MTOMCAT-185] - change phase for tomcat6/7:run to process-classes
* [MTOMCAT-186] - Closing executable JAR does not call
ServletContextListener.contextDestroyed()
* [MTOMCAT-194] - Odd error message in switching from Codehaus to
Maven Tomcat6 plugin
* [MTOMCAT-197] - tomcat7:undeploy goal not ignoring non-war projects
* [MTOMCAT-198] - Fix base classes for redeploy and redeploy-only goals
* [MTOMCAT-206] - Runtime dependencies within multi module
projects are not loaded.


** Improvement
* [MTOMCAT-99] - Make redeploy goal consistent with deploy goals
* [MTOMCAT-188] - Allow for the creation of a war that is both
executable and deployable
* [MTOMCAT-190] - Client Certificate settings for connector
* [MTOMCAT-191] - Return the "redeploy" goal to the Maven plugin
* [MTOMCAT-192] - Website text cleanup
* [MTOMCAT-199] - Text cleanup of goal definitions
* [MTOMCAT-200] - Tomcat7:redeploy
* [MTOMCAT-208] - JaCoCo instrumentation errors when running
StandaloneWarMojo

** New Feature
* [MTOMCAT-163] - No undeploy goal

** Question
* [MTOMCAT-187] - Scan resources executing run goal

Have Fun,

--
The Apache Tomcat Team.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Why is properties-maven-plugin still in alpha?

[Matthew Adams]

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  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 +
> > 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  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:
> > > > >
> > > > > 
> > > > > derby
> > > > > 
> > > > > derby
> > > > > derby
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > org.codehaus.mojo
> > > > > properties-maven-plugin
> > > > > 
> > > > > 
> > > > > 
> > > > > set-system-properties
> > > > > 
> > > > > initialize
> > > > > 
> > > > > 
> > > > > 
> > > > > derby.stream.error.field
> > > > > java.lang.System.out
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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 
> > > > >> 
> > > > >> Bordeaux JUG  Leader
> > > > >> Jenkins  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 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams