Re: writing a parent pom that does not execute its plugins
On 10/19/2011 09:32 PM, Anders Hammar wrote: >> I was able to make the profile idea work in the end. The trick is >> the enablement: the parent module defines a profile that is enabled >> through a property. The child module defines that property. Works >> like a charm. > > That should not work. Are you using Maven 3.0.x or 2.x? I'm using Maven 2.2.1. I tried to reproduce my approach in isolation but I can't =:-| The profile is not activated by setting the property in the child. -dirk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
>>> Regarding your use case: do you have a) N products which need to be >>> packaged all in the same way or b) one product which has to be packaged >>> in N similar variants? Or where is the variation in your packaging >>> otherwise? What differs between the projects you're attempting to package? >> >> It's more like a) - different products, same packaging. These products are >> all very similar since they sit on top of the same framework, though. The >> packaging process is always like this: >> >> - use an assembly to put all of our classes from different child modules >> into one jar that's to be fed into proguard for obfuscation >> - generate the obfuscator config, this plugin resolves depencies and puts >> paths to third party jars into a template >> - use proguard to obfuscate only our classes - third party classes are open >> source anyway so there's little use in obfuscating them >> - use another assembly to package up all third party jars along with our >> obfuscated jar and some supporting resources like scripts etc. into a >> deployment zip >> - use yet another assembly to package up the deployment zip and an installer >> shell script into an installer.zip >> >> All the installers we produce vary only in dependencies and in the contents >> of the various assemblies. The list of plugins and their configurations >> stays the same. > > This is crying out for a custom packaging... with that you can define > all the plugins to bind to the lifecycle of that custom packaging, and > then presto-chango your pom becomes > > > > ... > ... > ... > > ... > ... > ... > obfusacted-installer > > ... > > > > > ... > obfuscated-installer-maven-plugin > ... > true > > > > This is somewhat unfortunate because (quoting Anders' reply earlier in this thread): > Unfortunately it is not possible to include configuration of a plugin > in a custom packaging type. You need to create specific plugins (with > the proper default config) and use them in the packaging type. Please tell me there's an easier way to specify default configuration to a plugin than hard-coding the required values in MOJOs? How would I create the 3 executions of the assembly plugin? 3 different plugins? This approach seems far too heavy-weight ... I'm still tryig to find out why the approach I'm using (profiles activated by a child module) actually works when everyone says it shouldn't :-) -dirk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
On 20 October 2011 06:38, Dirk Olmes wrote: > On 20.10.2011, at 00:21, Ansgar Konermann wrote: >> >> Am 18.10.2011 13:28, schrieb Dirk Olmes: >>> >>> I am aware of the section but fail to see if it would >>> help: I'd still have to list all the plugins to be executed in the >>> individual installer POMs. >> >> True, but IMHO a lot better than specifying the whole plugin >> configuration over and over again. This is probably the "low hanging >> fruit" which you could harvest easily. > > Not low enough for me :-) > The alternative would have been to write a custom generator for pom files. > >> Regarding your use case: do you have a) N products which need to be >> packaged all in the same way or b) one product which has to be packaged >> in N similar variants? Or where is the variation in your packaging >> otherwise? What differs between the projects you're attempting to package? > > It's more like a) - different products, same packaging. These products are > all very similar since they sit on top of the same framework, though. The > packaging process is always like this: > > - use an assembly to put all of our classes from different child modules > into one jar that's to be fed into proguard for obfuscation > - generate the obfuscator config, this plugin resolves depencies and puts > paths to third party jars into a template > - use proguard to obfuscate only our classes - third party classes are open > source anyway so there's little use in obfuscating them > - use another assembly to package up all third party jars along with our > obfuscated jar and some supporting resources like scripts etc. into a > deployment zip > - use yet another assembly to package up the deployment zip and an installer > shell script into an installer.zip > > All the installers we produce vary only in dependencies and in the contents > of the various assemblies. The list of plugins and their configurations > stays the same. This is crying out for a custom packaging... with that you can define all the plugins to bind to the lifecycle of that custom packaging, and then presto-chango your pom becomes ... ... ... ... ... ... obfusacted-installer ... ... obfuscated-installer-maven-plugin ... true or ... ... ... ... ... ... obfusacted-installer ... ... obfuscated-installer-lifecycle ... depending on whether you require some custom mojo's, or just the custom lifecycle with existing plugins -Stephen > > -dirk > > > - > 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: writing a parent pom that does not execute its plugins
On 20.10.2011, at 00:21, Ansgar Konermann wrote: Am 18.10.2011 13:28, schrieb Dirk Olmes: I am aware of the section but fail to see if it would help: I'd still have to list all the plugins to be executed in the individual installer POMs. True, but IMHO a lot better than specifying the whole plugin configuration over and over again. This is probably the "low hanging fruit" which you could harvest easily. Not low enough for me :-) The alternative would have been to write a custom generator for pom files. Regarding your use case: do you have a) N products which need to be packaged all in the same way or b) one product which has to be packaged in N similar variants? Or where is the variation in your packaging otherwise? What differs between the projects you're attempting to package? It's more like a) - different products, same packaging. These products are all very similar since they sit on top of the same framework, though. The packaging process is always like this: - use an assembly to put all of our classes from different child modules into one jar that's to be fed into proguard for obfuscation - generate the obfuscator config, this plugin resolves depencies and puts paths to third party jars into a template - use proguard to obfuscate only our classes - third party classes are open source anyway so there's little use in obfuscating them - use another assembly to package up all third party jars along with our obfuscated jar and some supporting resources like scripts etc. into a deployment zip - use yet another assembly to package up the deployment zip and an installer shell script into an installer.zip All the installers we produce vary only in dependencies and in the contents of the various assemblies. The list of plugins and their configurations stays the same. -dirk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
Am 18.10.2011 13:28, schrieb Dirk Olmes: > I am aware of the section but fail to see if it would > help: I'd still have to list all the plugins to be executed in the > individual installer POMs. True, but IMHO a lot better than specifying the whole plugin configuration over and over again. This is probably the "low hanging fruit" which you could harvest easily. All other approaches I'm aware of involve a lot more effort. Regarding your use case: do you have a) N products which need to be packaged all in the same way or b) one product which has to be packaged in N similar variants? Or where is the variation in your packaging otherwise? What differs between the projects you're attempting to package? Best regards Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
Unfortunately it is not possible to include configuration of a plugin in a custom packaging type. You need to create specific plugins (with the proper default config) and use them in the packaging type. /Anders On Wed, Oct 19, 2011 at 13:43, Dirk Olmes wrote: > On 10/18/2011 01:55 PM, Anders Hammar wrote: >> I'm thinking that a custom packing type is what you want to create. >> Then use that as the packaging in those Maven projects where you >> create the install zips, and it will bind the appropriate plugins to >> the lifecycle. > > Thanks, Anders. I looked into creating a custom packaging type - > assuming that I will need to create a custom lifecycle as described in > [1] or [2]. Ok, this allows me to bind additional plugins to lifecycle > phases but now how do I configure those plugins? I will have 3 different > executions for the assembly plugin, one for jarring up all classes to be > obfuscated, one for packaging up all libs and one for packaging the > final installer zip. > > Where would I do that kind of configuration? > > -dirk > > [1] > http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/ > [2] > http://sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html > > - > 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: writing a parent pom that does not execute its plugins
> I was able to make the profile idea work in the end. The trick is the > enablement: the parent module defines a profile that is enabled through a > property. The child module defines that property. Works like a charm. That should not work. Are you using Maven 3.0.x or 2.x? /Anders > > More details here: > http://xanthippe.dyndns.org/blog/index.php?/archives/33-Templating-Maven-plugin-configurations.html > > -dirk > - > 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: writing a parent pom that does not execute its plugins
Some plugins already provide the following 2 properties * skip * forceMojoExecution The idea is that those plugins must not get executed when the project is of type 'pom'. But since most of this plugins in bigger projects get defined in a 'backend-parent' module (or kind of) which is the parent of all backend modules, it's pretty hard otherwise. Example being the sql-maven-plugin [1], the openjpa-maven-plugin, etc We have been discussing about generalizing this approach, but we would need a bit brainstorming still as there are mojos which explicitely gets executed on the parent pom (also). Generalized I'd say there are 3 types of plugins: a.) sql-maven-plugin like only need to get executed in projects with packaging != pom b.) aggregator mojos (like javadoc-aggregated) which run _only_ on the parent pom c.) mojos which need to get executed in every project (like the site-plugin) LieGrue, strub [1] http://mojo.codehaus.org/sql-maven-plugin/execute-mojo.html - Original Message - > From: Dirk Olmes > To: Maven Users List > Cc: > Sent: Wednesday, October 19, 2011 7:55 PM > Subject: Re: writing a parent pom that does not execute its plugins > > Am 18.10.2011 um 14:41 schrieb Anders Hammar : > >> Today, activating a profile defined in a parent from the child is not > possible. > > I was able to make the profile idea work in the end. The trick is the > enablement: the parent module defines a profile that is enabled through a > property. The child module defines that property. Works like a charm. > > More details here: > http://xanthippe.dyndns.org/blog/index.php?/archives/33-Templating-Maven-plugin-configurations.html > > -dirk > - > 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: writing a parent pom that does not execute its plugins
Am 18.10.2011 um 14:41 schrieb Anders Hammar : > Today, activating a profile defined in a parent from the child is not > possible. I was able to make the profile idea work in the end. The trick is the enablement: the parent module defines a profile that is enabled through a property. The child module defines that property. Works like a charm. More details here: http://xanthippe.dyndns.org/blog/index.php?/archives/33-Templating-Maven-plugin-configurations.html -dirk - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
On 10/18/2011 01:55 PM, Anders Hammar wrote: > I'm thinking that a custom packing type is what you want to create. > Then use that as the packaging in those Maven projects where you > create the install zips, and it will bind the appropriate plugins to > the lifecycle. Thanks, Anders. I looked into creating a custom packaging type - assuming that I will need to create a custom lifecycle as described in [1] or [2]. Ok, this allows me to bind additional plugins to lifecycle phases but now how do I configure those plugins? I will have 3 different executions for the assembly plugin, one for jarring up all classes to be obfuscated, one for packaging up all libs and one for packaging the final installer zip. Where would I do that kind of configuration? -dirk [1] http://www.sonatype.com/people/2009/08/create-a-customized-build-process-in-maven/ [2] http://sonatype.com/books/mvnref-book/reference/writing-plugins-sect-plugins-lifecycle.html - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
Hi Anders,
Anders Hammar wrote:
> Today, activating a profile defined in a parent from the child is not
> possible.
this is not entirely true:
= %<
$ find .
.
./child1
./child1/pom.xml
./child2
./child2/pom.xml
./child2/v.xml
./pom.xml
= %<
Parent:
= %<
4.0.0
test
parent
pom
1-SNAPSHOT
org.apache.maven.plugins
maven-verifier-plugin
1.0
verification
verify
verify
${basedir}/v.xml
auto-verification
v.xml
org.apache.maven.plugins
maven-verifier-plugin
child1
child2
= %<
Child1:
= %<
test
parent
1-SNAPSHOT
4.0.0
test
child2
pom
= %<
Child2 the same, except artifactId. Verification file "child2/v.xml":
= %<
pom.xml
child2
= %<
Works with M3. Works with M2 locally, but not in the reactor.
:)
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
Today, activating a profile defined in a parent from the child is not possible.
/Anders
On Tue, Oct 18, 2011 at 14:35, Tomasz Pik wrote:
> On Tue, Oct 18, 2011 at 1:28 PM, Dirk Olmes wrote:
>> Hi,
>>
>> our Maven (2.2.1) build generates install zips with obfuscated sources
>> from the artifacts within the build. Over the last year we created more
>> and more installer packages this way, using the famous copy/paste approach.
>>
>> I'd like to clean things up so I thought I'd create a parent POM with
>> pom and have the installer modules inherit from
>> it. Now the problem is that in the installer-parent module I'm binding
>> plugins to the specific lifecycle phases already, e.g.
>>
>>
>> org.codehaus.mojo
>> properties-maven-plugin
>>
>>
>> initialize
>>
>> read-project-properties
>>
>>
>>
>> ${basedir}/build.properties
>>
>>
>>
>>
>>
>>
>> My problem is that I don't want the newly created installer-parent
>> module to execute those plugins but rather the child modules.
>>
>> I am aware of the section but fail to see if it would
>> help: I'd still have to list all the plugins to be executed in the
>> individual installer POMs.
>
> Maybe put those plugins into dedicated profile in parent pom and then
> activate this profile in children?
>
> Regards,
> Tomek
>
> PS http://jira.codehaus.org/browse/MNG-4154
>
>>
>> I'm thankful for any hint ...
>>
>> -dirk
>>
>> -
>> 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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: writing a parent pom that does not execute its plugins
On Tue, Oct 18, 2011 at 1:28 PM, Dirk Olmes wrote:
> Hi,
>
> our Maven (2.2.1) build generates install zips with obfuscated sources
> from the artifacts within the build. Over the last year we created more
> and more installer packages this way, using the famous copy/paste approach.
>
> I'd like to clean things up so I thought I'd create a parent POM with
> pom and have the installer modules inherit from
> it. Now the problem is that in the installer-parent module I'm binding
> plugins to the specific lifecycle phases already, e.g.
>
>
> org.codehaus.mojo
> properties-maven-plugin
>
>
> initialize
>
> read-project-properties
>
>
>
> ${basedir}/build.properties
>
>
>
>
>
>
> My problem is that I don't want the newly created installer-parent
> module to execute those plugins but rather the child modules.
>
> I am aware of the section but fail to see if it would
> help: I'd still have to list all the plugins to be executed in the
> individual installer POMs.
Maybe put those plugins into dedicated profile in parent pom and then
activate this profile in children?
Regards,
Tomek
PS http://jira.codehaus.org/browse/MNG-4154
>
> I'm thankful for any hint ...
>
> -dirk
>
> -
> 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: writing a parent pom that does not execute its plugins
I'm thinking that a custom packing type is what you want to create.
Then use that as the packaging in those Maven projects where you
create the install zips, and it will bind the appropriate plugins to
the lifecycle. Not sure though how this would work with your
obfuscated sources jars though as plain sources jars are added when
releasing through a profile in the super-pom. I'm thinking you need to
ensure that profile is not executed.
/Anders
On Tue, Oct 18, 2011 at 13:28, Dirk Olmes wrote:
> Hi,
>
> our Maven (2.2.1) build generates install zips with obfuscated sources
> from the artifacts within the build. Over the last year we created more
> and more installer packages this way, using the famous copy/paste approach.
>
> I'd like to clean things up so I thought I'd create a parent POM with
> pom and have the installer modules inherit from
> it. Now the problem is that in the installer-parent module I'm binding
> plugins to the specific lifecycle phases already, e.g.
>
>
> org.codehaus.mojo
> properties-maven-plugin
>
>
> initialize
>
> read-project-properties
>
>
>
> ${basedir}/build.properties
>
>
>
>
>
>
> My problem is that I don't want the newly created installer-parent
> module to execute those plugins but rather the child modules.
>
> I am aware of the section but fail to see if it would
> help: I'd still have to list all the plugins to be executed in the
> individual installer POMs.
>
> I'm thankful for any hint ...
>
> -dirk
>
> -
> 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
writing a parent pom that does not execute its plugins
Hi,
our Maven (2.2.1) build generates install zips with obfuscated sources
from the artifacts within the build. Over the last year we created more
and more installer packages this way, using the famous copy/paste approach.
I'd like to clean things up so I thought I'd create a parent POM with
pom and have the installer modules inherit from
it. Now the problem is that in the installer-parent module I'm binding
plugins to the specific lifecycle phases already, e.g.
org.codehaus.mojo
properties-maven-plugin
initialize
read-project-properties
${basedir}/build.properties
My problem is that I don't want the newly created installer-parent
module to execute those plugins but rather the child modules.
I am aware of the section but fail to see if it would
help: I'd still have to list all the plugins to be executed in the
individual installer POMs.
I'm thankful for any hint ...
-dirk
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
