Question

Being a Maven newbie, I want to know if its possible to use multiple classifiers at once; in my case it would be for generating different jars in a single run. I use this command to build my project:

mvn -Dclassifier=bootstrap package

Logically I would think that this is possible:

mvn -Dclassifier=bootstrap,api package

I am using Maven 3.0.4

Answer 1

Your project seems like a candidate for refactoring into a couple of what Maven calls “modules”. This involves splitting the code into separate projects within a single directory tree, where the topmost level is normally a parent or aggregator POM with <packaging>pom</packaging> and a <modules/> list containing the sub-project directory names.

Then, I’d advise putting the API interfaces/exceptions/whatnot into an api/ subdirectory with its own pom.xml, and putting the bootstrap classes into a bootstrap/ subdirectory with its own pom.xml. The top-level pom.xml would then list the modules like this:

<modules>
  <module>api</module>
  <module>bootstrap</module>
</module>

Once you’ve refactored the project, you will probably want to add a dependency from the bootstrap module to the api module, since I’m guessing the bootstrap will depend on interfaces/etc. from the api.

Now, you should be able to go into the top level of the directory structure and simply call:

mvn clean install

This approach is good because it forces you to think about how different use cases are supported in your code, and it makes dependency cycles between classes harder to miss.

If you want an example to follow, have a look at one of my github projects: Aprox.

NOTE: If you have many modules dependent on the api module, you might want to list it in the top-level pom.xml in the <dependencyManagement/> section, so you can leave off the version in submodule dependency declarations (see Introduction to the Dependency Mechanism).

UPDATE: Legacy Considerations

If you can’t refactor the codebase for legacy reasons, etc. then you basically have two options:

1. Construct a series of pom.xml files in an empty multimodule structure, and use the build-helper-maven-plugin along with source includes/excludes to fragment the codebase and allocate the classes to different modules out of a single source tree.

2. Maybe use a plugin like the assembly plugin to carve up the target/classes directory (${project.build.directory}) and allocate classes to the different jars. In this scenario, each assembly descriptor requires an <id/> and by default this value becomes the classifier for that assembly jar. Under this plan, the “main” jar output will still be the monolithic one created by the Maven build. If you don’t want this, you can use a separate execution of the assembly plugin, and in the configuration use <appendAssemblyId>false</appendAssemblyId>. If the output of that assembly is a jar, then it will effectively replace the old output from the jar plugin. If you decide to pursue this approach, you might want to read the assembly plugin documents to get as much exposure to different examples as you can.

Also, I should note that in both cases you would be stuck with manipulating the list of things produced by using a set of profiles in the pom in order to turn on/off different parts of the build. I’d highly recommend making the default, un-qualified build one that produces everything. This makes it more likely for things like the release plugin to catch everything you want to release, and up-rev versions, etc. appropriately.

These solutions are usually what I promote as migration steps when you can’t refactor the codebase all at once. They are especially useful when migrating from something like an Ant build that produces multiple jars out of a single source tree.