Building Java Dependencies

2014-09-03T00:00:00+00:00

Over the summer I was involved in the Google Summer of Code as part of Debian. The project involved building dependencies of Java-based projects and was based off this blog post. My goal for the project was to create something that wasn't Debian specific and could be used in other projects as well. Since the project was based off metadata as reported by Maven, it made sense that a Maven plugin was in order. This also gave me easy access to the metadata by using existing Maven APIs.

Why might you want to rebuild dependencies of a project that are already built? My mentor for the project, Daniel Pocock, found that one avenue for publishing an artifact into the Maven central repository involved uploading a jar and pom itself. Although this may seem legitimate (and can be in certain cases), it raises many questions with regard to free software. The big one is whether you can trust them, especially when in regard to security software. By building each of the dependencies from source, you ensure that not only the source is available and can be reviewed by others (something very important for free software), but also that the dependency is built from the source you expect.

The project is currently hosted on github and attempts to build all dependencies and transitive dependencies for a given artifact. This includes build plugins, extensions, and dependencies, some of which can be configured to be ignored and not built. It makes use of Maven metadata to find the source location and failing that the sources.jar that accompanies many artifacts in the central repository. The maven-scm-plugin API is used for fetching sources and therefore is compatible with many different source control systems, including git, cvs, perforce and more. It currently supports projects which are built with either Ant or Maven. The project is built upon plexus components and therefore very extendable should you find a project that doesn't work. In addition, since the project is built as a Maven plugin, the repository to fetch artifacts is configurable and need not the Maven central repository. The output of the plugin is again a Maven repository and therefore can be used in future builds without needing to rebuild every dependency every single time; this is the expected use case.

I was recently at debconf14 in Portland to present what I've been working on over the summer. When preparing for the talk, I was determined to show a working example on an artifact publicly available in Maven central. Although I was successful and demoed it on a small project, I found problems when dealing with larger projects. I intend to rectify this is the coming weeks. Stay tuned for the final developments.

Andrew Schurman

Building Java Dependencies