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> <packaging>obfusacted-installer</packaging> <dependencies> ...<!-- list the deps here --> </dependencies> <build> <plugins> <plugin> <groupId>...</groupId> <artifactId>obfuscated-installer-maven-plugin</artifactId> <version>...</version> <extension>true</extension> </plugin> </plugins> </build> </project> or <project> <parent> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> </parent> <groupId>...</groupId> <artifactId>...</artifactId> <version>...</version> <packaging>obfusacted-installer</packaging> <dependencies> ...<!-- list the deps here --> </dependencies> <build> <extensions> <extension> <groupId>...</groupId> <artifactId>obfuscated-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