Jresearch Software Blog
Zelix obfuscation plugin for Maven. Release 1.1
(the record restored from backup)
Previouse:
I released the obfuscation plugin for Maven. It uses the Zelix KlassMaster obfuscator. We use this plugin for Flexess obfuscation.
The main features are:
- Supports the multi-model projects.
- Obfuscation of jar and war projects (modules)
- Recognizes signed jar projects (modules) and resign the obfuscated jar.
- Automatically rebuild project (module) dependency to obfuscated version of artifacts
- Substitute obfuscated class names in maven resources.
- Contains check task, which can check the project structure and report the issues that may prevent the obfuscation.
The plugin is open source. It is accessible from the Jresearch open repository. The plugin group is org.jresearch.commons.obfuscate, artifact id is org.jresearch.commons.obfuscate.plugin, version is 1.1.
Take into consideration that it isn't a separate project with support, documentation and clever code, We developed that plugin for internal usage just to automate some manual work.
Update of Zelix obfuscation plugin.
(Restored record from backup)
Not long ago I spent a few hours (heh...) to improve the Zelix obfuscation plugin for Maven.
In our Flexess project we use the Zelix obfuscation for almost all modules. But there are some modules, which have to be unobfuscated and in addition be compiled against the obfuscated jars, e.g. Examples for our API.
Without obfuscation such (Example, in our case) modules contains the following dependency:
<dependency>
<groupId>com.jresearchsoft.uam.client</groupId>
<artifactId>com.jresearchsoft.uam.client</artifactId>
<version>1.0.0-SNAPSHOT</version>
<scope>runtime</scope>
</dependency>
It is Ok for development, but then I did an obfuscated build I needed to change manually all such dependencies (e.g. before assembly:assembly) to something like:
<dependency>
<groupId>com.jresearchsoft.uam.client</groupId>
<artifactId>com.jresearchsoft.uam.client</artifactId>
<version>1.0.0-obfuscate-20071123101115</version>
<scope>runtime</scope>
</dependency>
To resolve this issue I introduced the resolve goal. This goal just scans the project during the build and tries to resolve all SNAPSHOT dependencies to obfuscated version. So the project will compiled against obfuscated versions of dependencies and the installed (deployed) artifact will have the resolved pom. To archive it you should add to the <build> section of a pom.xml the following code:
<plugin>
<groupId>org.jresearch.commons.obfuscate</groupId>
<artifactId>org.jresearch.commons.obfuscate.plugin</artifactId>
<executions>
<execution>
<id>resolve</id>
<goals>
<goal>resolve</goal>
</goals>
</execution>
</executions>
</plugin>
Such definition will enable resolving. It has also one more side-effect - it will disable the obfuscation of a module. So if you have the multi-module project you can add to the root pom.xml the obfuscation directive and it will be automatically skipped in all modules with resolving.
Zelix and Maven, Maven and Zelix....
We use the Zelix KlassMaster to obfuscate both the Eclipse and Maven parts of our project.
For Eclipse everything is clear - get the Ant task, bind it to the Eclipse build process and go.
With Maven it was not so ease. We implemented special plugin that obfuscates a module by module during build (we have many modules in our project).
The main idea is to obfuscate the module based on the maps from their dependencies.
And it works. Of course, with some tips and tricks, but we have build process which allows us to get development builds fully automatically and make distribution packages with minimal manual work.
That plugin is open source. You can get it from our open repository. Group is org.jresearch.commons.obfuscate, artifact is org.jresearch.commons.obfuscate.plugin It requires Zelix KlassMaster to work. Also take into consideration that it isn't a separate project with support, documentation and clever code, We developed that plugin for internal usage just to automate some manual work.



