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
On 20 October 2011 06:38, Dirk Olmes d...@xanthippe.ping.de 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 pluginManagement 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 project parent groupId.../groupId artifactId.../artifactId version.../version /parent groupId.../groupId artifactId.../artifactId version.../version packagingobfusacted-installer/packaging dependencies ...!-- list the deps here -- /dependencies build plugins plugin groupId.../groupId artifactIdobfuscated-installer-maven-plugin/artifactId version.../version extensiontrue/extension /plugin /plugins /build /project or project parent groupId.../groupId artifactId.../artifactId version.../version /parent groupId.../groupId artifactId.../artifactId version.../version packagingobfusacted-installer/packaging dependencies ...!-- list the deps here -- /dependencies build extensions extension groupId.../groupId artifactIdobfuscated-installer-lifecycle/artifactId version.../version /extension /extensions /build /project 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
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 project parent groupId.../groupId artifactId.../artifactId version.../version /parent groupId.../groupId artifactId.../artifactId version.../version packagingobfusacted-installer/packaging dependencies ...!-- list the deps here -- /dependencies build plugins plugin groupId.../groupId artifactIdobfuscated-installer-maven-plugin/artifactId version.../version extensiontrue/extension /plugin /plugins /build /project 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 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
Am 18.10.2011 um 14:41 schrieb Anders Hammar and...@hammar.net: 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
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 d...@xanthippe.ping.de To: Maven Users List users@maven.apache.org 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 and...@hammar.net: 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
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
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 d...@xanthippe.ping.de 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
Am 18.10.2011 13:28, schrieb Dirk Olmes: I am aware of the pluginManagement 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
On 20.10.2011, at 00:21, Ansgar Konermann wrote: Am 18.10.2011 13:28, schrieb Dirk Olmes: I am aware of the pluginManagement 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
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
packagingpom/packaging 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.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
executions
execution
phaseinitialize/phase
goals
goalread-project-properties/goal
/goals
configuration
files
file${basedir}/build.properties/file
/files
/configuration
/execution
/executions
/plugin
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 pluginManagement 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
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 d...@xanthippe.ping.de 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
packagingpom/packaging 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.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
executions
execution
phaseinitialize/phase
goals
goalread-project-properties/goal
/goals
configuration
files
file${basedir}/build.properties/file
/files
/configuration
/execution
/executions
/plugin
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 pluginManagement 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
Re: writing a parent pom that does not execute its plugins
On Tue, Oct 18, 2011 at 1:28 PM, Dirk Olmes d...@xanthippe.ping.de 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
packagingpom/packaging 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.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
executions
execution
phaseinitialize/phase
goals
goalread-project-properties/goal
/goals
configuration
files
file${basedir}/build.properties/file
/files
/configuration
/execution
/executions
/plugin
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 pluginManagement 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
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 tom...@gmail.com wrote:
On Tue, Oct 18, 2011 at 1:28 PM, Dirk Olmes d...@xanthippe.ping.de 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
packagingpom/packaging 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.
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
executions
execution
phaseinitialize/phase
goals
goalread-project-properties/goal
/goals
configuration
files
file${basedir}/build.properties/file
/files
/configuration
/execution
/executions
/plugin
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 pluginManagement 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
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:
= %
project
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdparent/artifactId
packagingpom/packaging
version1-SNAPSHOT/version
build
pluginManagement
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-verifier-plugin/artifactId
version1.0/version
executions
execution
idverification/id
phaseverify/phase
goals
goalverify/goal
/goals
/execution
/executions
configuration
verificationFile${basedir}/v.xml/verificationFile
/configuration
/plugin
/plugins
/pluginManagement
/build
profiles
profile
idauto-verification/id
activation
file
existsv.xml/exists
/file
/activation
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-verifier-plugin/artifactId
/plugin
/plugins
/build
/profile
/profiles
modules
modulechild1/module
modulechild2/module
/modules
/project
= %
Child1:
= %
project
parent
groupIdtest/groupId
artifactIdparent/artifactId
version1-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdchild2/artifactId
packagingpom/packaging
/project
= %
Child2 the same, except artifactId. Verification file child2/v.xml:
= %
verifications
files
file
locationpom.xml/location
containschild2/contains
/file
/files
/verifications
= %
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
