As an example say you want to fix all the junit dependencies to the same version or fix the scope of an item in multiple projects. This tool will do it for you.
The tool takes a top level directory and a mapping file as inputs. It will scan for pom files and process them according to the source and target mappings.
Note, this tool REWRITES your pom file according to whatever rules are build into the org.apache.maven.model.Model class. If you are not happy with this then don’t use it or make sure you have backups of your project pom files first. Don’t say you weren’t warned.
The mapping file format is
<?xml version="1.0"?> <mappings> <mapping> <dependency-source> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.0</version> </dependency-source> <dependency-target> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.9</version> <scope>test</scope> </dependency-target> </mapping> </mappings>
or if you want you can use a wildcard for the source version number i.e.
<?xml version="1.0"?> <mappings> <mapping> <dependency-source> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>*</version> </dependency-source> <dependency-target> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.9</version> <scope>test</scope> </dependency-target> </mapping> </mappings>
I hope this proves useful to someone.
Recently I have been looking at writing a plugin for gephi. This is a open source visualisation tool which lets you create connected graphs of large data sets. I couldn’t get the source code to build and it occurred to me that it might be a good idea to “mavenize” it. After a little investigation I did find the existing maven version of the gephi codebase but after a great deal of effort I still can’t get it to build. Oh well.
One of the pleasures of writing software for your own amusement is you can go off at tangents and investigate whatever catches your interest. With that in mind I found myself pondering – what does it take to “mavenize” an existing java project?
- Put the application code under “src/main/java”.
- Put the resource files (i.e. everything that isn’t a *.java file) under “src/main/resources”
- Put your unit tests under “src/test/java” (or at least create the directory structure for it)
- Put your test resources under”src/test/resources”
- Generate a pom file with a group and artifact id along with dependencies.
This process isn’t particularly onerous when you have one project to do but if you have a number to convert then it quickly becomes a pain. The gephi application had more than 100 modules so you can see why the thought occurred to me “I can write a tool to do this” and here it is:
“mavenize” is a command line tool written in java which you can point at any number of existing java projects and it will automatically generate a maven project directory structure with all the source and resources in the correct place along with a “best guess” pom file. The best guess bit comes from looking at the source code packages and extracting the package prefix which occurs most often as the group id. The artifact id is merely the project name (i.e. the directory name which contains the “src” dir).
You can pass in a version number and a package type to assign to the generated poms. Also if your project is a NetBeans module it will read the project description file and extract the dependencies and place them into the pom file as rough guide for you.
I wrote this to fill a need and I am guessing someone, somewhere has to have the same need as well so here is the link to the project and instructions for it’s use.
From a developer point of view this tool has some interesting components.
- Uses org.apache.commons.io.DirectoryWalker class to recurse down through directories.
- Uses org.apache.commons.io.filefilter.DirectoryFileFilter and org.apache.commons.io.filefilter.IOFileFilter to compose lists of java and resource files.
- Contains good examples of reading and writing a maven pom file using the org.apache.maven.model.Model class and associated model io classes.
- In order to find the package name prefix with the largest number of occurrences I used the “longest substring” algorithm. The version I used was lifted straight from the this page. Obviously the Apache license doesn’t apply to this since it’s from elsewhere.
- I used a tool called trang to read NetBeans project.xml file and generate a sample xsd file.
- I used jaxb to read the project.xsd file and generate the relevant classes to be able to read the NetBeans project details.
I also have another tool which I have dubbed “pommel” which I will get round to publishing as well at some point. This will scan your maven projects and replace target dependencies with specific ones defined in a config file. This is extremely useful if you have to do this operation on a large number of projects.