Here's my progress report for the first phase of Gentoo Maven Integration project for
finishing the work under Google Summer of Code and starting move in to
a voluntary position.
The goal of this project was to build maven and it's huge number of
dependencies from source, and then facilitate the packagers for
packaging maven-based Java packages. There are two eclasses which will
facilitate bootstrapping maven along with building maven-based
packages, and packaging Maven plugins. These eclasses address some
fundamental issues of incompatibilities between Gentoo build system
and Maven build system.
There were two main goals for the project. One is building
maven-from-source. It is now completed and has been thoroughly tested.
There are around 40+ ebuilds that are direct dependencies of Maven
which were packaged/bumped during the project period. General users of
maven can have the full benefit from this package now. Please file
bugs at https://bugs.gentoo.org/ if you find any.
The second phase was a lengthy process and the scope wasn't fit for
one and half months time. But with mentors' blessing, I've made a
quite a big progress and was able to emerge a minimal package built
via native Maven.
Let me describe the surface details of the second phase. The idea was
to facilitate the packagers to package maven-based packages. This has
been a long-time blocker for Gentoo-Java (which extends to more than
3-4 years). For this phase, we needed several requirements including
dependency management issues and rewriting of pom.xml to match
Gentoo's needs. One requirement in it was the need to have a mechanism
to use the installed system jars instead of downloading the jars from
maven repos. One another is that pom needs to respect the Gentoo SLOT
system. Further, configuration details needed to be added to tell the
JDK and JRE versions needed for building (ie need to add config bits
to maven-compiler-plugin section in the pom). And, then it needs
several maven plugins to build packages. There were enormous amount of
plugins available that most of them need special attention separately.
For the second phase, the hard part is over. And, as I said, I was
able to emerge a minimal maven-based implementation. Maven isn't much
cooperative when it comes to dependency management, but our solution
Along with that, the first iteration of work is complete. I'm hoping
to be the maintainer for Maven under Gentoo Java herd for the
foreseeable future. And, I'm eagerly waiting to wear the Gentoo
Developer hat one day. I'm interested in knowing the generic plan for
recruiting developers who come via Summer of Code as well.
There are few things to be done to bring the use of the Maven
integration to it's full potential. These are more like plug-ins to
the core base, and beautifying the process. I need to make new plans
for these with help from Java herd.
* There's only five maven plugins has been packaged. Have a fresh
look at maven-surefire-plugin. Needs to add all other plugins.
* Currently, when MAVEN_PARENTPOM_UNIQUE_ID is set to rewrite
<parent> node of the pom, it rewrites all the poms in the project
including sub-modules. The most probable usecase is that rewrite the
parent element of the top-level/aggregator pom. The configuration bits
needed are already there (-w option), but the implementation needs to
* Merge the separate ebuilds of maven-2.2.1 maven-2.2.1 release in
to one. There are around 20+ ebuilds dedicated for this. These ebuilds
probably won't be needed separately so it's ok to merge these
together. Need to evaluate possibility of issues of having all these
Here are some references if you are interested in getting deeper in
Maven in Gentoo. Feel free to contact me if you like to extend your
helping hand for the project. I'm at kasunbg +spamfree at gmail.com
* The wiki 1 - Developer and User guide for Maven in Gentoo -
* The wiki 2 - Manpage for java-maven-2 eclass -
* Repository 1 - gsoc-maven-overlay -
* Repository 2 - Branch for Javatoolkit -
* TracBrowser view -