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: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
