>>> 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>
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: [email protected] For additional commands, e-mail: [email protected]
