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
