Archive for May, 2009

Apache Maven

May 24, 2009

I am using Apache Maven 2 to build the most projects i am involved in. It keeps the project minimal, by the concise description of the dependencies through the transient dependency mechanism and it stores the dependent JAR files separately of the project. It integrates nicely with Eclipse (by creating Eclipse projects) and promises an easy way to get night builds and to separate the sources in a team; for security reasons I don’t want all the members of the team to have all the source code of the application.

I foresee an application of Maven dependency resolution in BeanShell. It will be greatly to have a function like Maven.resolveDependency(String groupid, String artifactid,[String version]). This will make use of the local Maven cache or it will connect to the configured maven repositories and it will download the JAR file together with its dependencies. What a great way to use “dependency rich” modules like Apache Fop in short and self containing BeanShell scripts.

On the other hand, daily use of Maven is far away from idyllic. What annoys a lot are the permanent changes that invalidate the previous configurations. Yesterday I have to build a Web Start application for my employer’s Java Swing software application. Of course, I perceived it as a rather routine task, even with special requirement to obfuscate as much as possible of the source code, except of course of the parts being introspected by the various XML parsers or serializers.

First, I have realized that obfuscation is not possible for multiple projects, except if they are united together. The assembly:assembly plug-in was stubborn enough to include the current directory even if I explicitly forbade it. It also created the nice “c:” entry in the JAR file. Fortunately the entry was not recursive, else I would have ended with my whole C drive in the output file. Help came from the FreeHEP plug-in, their implementation shown efficiency and coherence.

Second, finding an obfuscator is not a trivial job. After some tests, yguard shown the best results.

Third, building the Web Start application itself. Some nice guy renamed the group ID of the package from org.codehaus.mojo” to org.codehaus.mojo.webstart”, so basically I have wondered for a few hours why is my configuration not working, why some settings are simply ignored. I figured it out after I have downloaded the sources of the plug-in and tied to debug it. The task of the plug-in is not trivial, it needs to sign all the dependent JAR file involved in the project and to build the JNLP file. Until now I had my own JNLP template, containing a $dependencies macro to avoid listing the dependencies manually. The file was now simply ignored as I moved to the new plugin and I had to spend a lot of time to fix the configuration. The reason I moved to the new plugin was simple: I needed a way to resign already signed JARs and the new plugin seamed to be the only solution.

Other thoughts about Maven: it is full of unexpected issues, such as, lastly:

[INFO] Internal error in the plugin manager executing goal ‘org.apache.maven.plu gins:maven-antrun-plugin:1.1:run’: Unable to find the mojo ‘org.apache.maven.plugins:maven-antrun-plugin:1.1:run’ in the plugin ‘org.apache.maven.plugins:maven- antrun-plugin’
Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-antrun-plugin:1.1:run.

Well, the plugin was there, it has even worked previously when running the sibling project. The error occured when compiling the parent project. After some efforts to understand the issue I found a forum, here somebody indicate that placing the plug-in in theĀ  pluginManagement” section of the parent project will overcome the issue. This has worked, but I am still frustrated by not having an answer on the question “why?”.

Another point is the AndroMDA code generator. The generator is implemented through a Maven plugin. In winter I have spend some effort to write an educational software consisting in multiple choiche questions. The software was EJB3 based, all entity beans were described in an UML model. The code generator produced all needed beans, with annotations, cascading rules and database configuration file. The problem now is that the generator was as a Snapshot, and now the same version is not working anymore. [error here].

So, what is the future of Apache Maven? Here is my vision:

  • GUI: it should be possible to configure the project and each single plugin through an user interface. It does not need to be fancy but it should be just effective, see ArgoUML. Editing text XML in 21st century is outrageos.
  • Custom project phases. The predefined build / clean / site lists of phases are insufficient for complex projects.
  • Multiple target types. What if the user needs to have multiple JAR versions of the same project, such as “Java 1.5” or “Java 1.6” Runtime? Again hardcoding the possible targets as: sources/javadoc/jar is a private club solution.
  • Multiple languages. C/C++/.NET, even if the project flow is orchestrated by the Java engine.
  • Pipelines. It is nice to have a declarative syntax, but some steps have to be procedural. Currently I think I abuse the Ant plugin and/or the “executions” feature of the plugins, to achieve some kind of procedural steps. Forking should be also allowed, as it can greatly increase the build performance, especially on multiprocessor/multicore machines.
  • Atomicity. Each goal of the plugins has to be atomic. Goals like “discover the Philosopher’s Stone, compile the project and interpret Beethoven’s 9th symphony” should be clearly split in their atomic constituents.
  • Easiness of plug-in development. Writing a plug-in should be easy, ant-like. Also the license should allow, if not yet doing it, proprietary code. Also, the parameters of a plug-in should be self-describing, so that the user interface will be able to present the choiches properly. There should be a plugin test framework, to facilitate quality assurance.