Mikel Cármenes Cavia wrote:
Well, that sure sounds like another very intelligent way to do it. Would you
mind sharing the portion of your POM that takes care of this sort of
functionality?
Ok, here we go ...
Step 1: list all the dependencies into a text file
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>resolve</goal>
</goals>
<configuration>
<excludeGroupIds>de.exentra</excludeGroupIds>
<outputFile>${project.build.directory}/dependencies.txt</outputFile>
</configuration>
</execution>
</executions>
</plugin>
Step2: fill out the proguard template
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.1-beta-1</version>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>java</goal>
</goals>
<configuration>
<mainClass>com.xxx.ProguardConfigFilter</mainClass>
<arguments>
<argument>${project.build.directory}/dependencies.txt</argument>
<argument>${settings.localRepository}</argument>
<argument>${project.basedir}/proguard.conf.in</argument>
<argument>${project.build.directory}/proguard.conf</argument>
</arguments>
</configuration>
</execution>
</executions>
</plugin>
I'll leave the implementation of ProguardConfigFilter as an exercise to
the reader but it's fairly simple: read in the generated
dependencies.txt, build full paths to the jars in the local repository
and stuff that into the proguard.conf.in. Finally, write the result to
proguard.conf
Step 3: pack up all my project's classes into a single jar
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<phase>process-classes</phase>
<goals>
<goal>attached</goal>
</goals>
<configuration>
<finalName>my-project-open</finalName>
<appendAssemblyId>false</appendAssemblyId>
<descriptors>
<descriptor>assembly.xml</descriptor>
</descriptors>
<attach>false</attach>
</configuration>
</execution>
</executions>
</plugin>
the assembly.xml is fairly simple, too but it assumes that all my
project's modules have the same groupId:
<assembly>
<id>deployment</id>
<formats>
<format>jar</format>
</formats>
<includeBaseDirectory>false</includeBaseDirectory>
<dependencySets>
<dependencySet>
<outputDirectory></outputDirectory>
<outputFileNameMapping></outputFileNameMapping>
<unpack>true</unpack>
<scope>runtime</scope>
<includes>
<include>com.xxx:*</include>
</includes>
</dependencySet>
</dependencySets>
</assembly>
Step4: proguard
<plugin>
<groupId>com.pyx4me</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.2</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>proguard</goal>
</goals>
</execution>
</executions>
<configuration>
<proguardInclude>${project.build.directory}/proguard.conf</proguardInclude>
<includeDependency>false</includeDependency>
<injar>my-project-open.jar</injar>
<outjar>my-project.jar</outjar>
<libs>
<lib>${java.home}/lib/rt.jar</lib>
</libs>
</configuration>
</plugin>
Further, do you incorporate your "other" dependencies into
the jar after ProGuard is done with the obfuscation, or do you always keep
them outside?
As you might have seen from the steps above, my build is special in two
ways:
- we don't obfuscate any third party dependencies. The philosophy is
that you don't want to obfuscate something that's publicly available anyway.
- we pack up all our project's output into a single jar. That's due to
the fact that third party dependencies almost never change but our
project does. With this approach, deployment becomes easy: just swap out
a single jar and be done :-)
Thanks so much for the insight Dirk!
Hope this helps,
-dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
