Skip to main content

Deploying non-Maven jars to m2 repository

Posted by kohsuke on July 30, 2008 at 12:42 AM PDT

One of the problems I often have to help within Sun is to push jars to the Maven repositories. Many Sun projects, especially older ones, are normally built by Ant, so simplifying the deployment of those jars has been a challenge. And this is not just a problem for me alone — often when you are using Maven, you have dependencies that do not exist in Maven repositories yet, then you have to push those jars to the Maven repositories by yourself.

The "usual" way of doing this is to use "mvn deploy:deploy-file", but in my opinion this doesn't work very well for several reason:

  1. Using non-standard transport for deployment (in maven jargon, using custom wagon implementation) isn't very easy.

  2. If you intend to keep track of newer versons in the future, you need a wrapper shell script to automate this, and a shell script isn't portable nor easily automatable from Java.

In short, it's just not easy enough. And that's why I'm writing this post. In this post, I'll show you how you can do this by just writing one POM, which you basically just copy&paste from here with a few adjustments. You then run "mvn install" and it will push the jars and associated artifacts (if any) to the Maven2 repository.

This technique combines wagon-svn and maven-antrun-extended-plugin, and here is the typical POM:

<project xmlns=""
" title="">
  <name>Java Native Access</name>


      <!-- fake out maven and install the binary artifact -->
                <attachArtifact file="jna.jar" />
                <ant dir="." target="src-zip" />
                <attachArtifact file="build-d64/" classifier="sources" type="jar"/>

      <name> Repository for Maven</name>

      <name> Repository for Maven</name>

The text in bold is the part that you need to modify. The first part should be hopefully obvious. These are the key parameters that identify the artifact in the Maven world. The group Id normally comes from your Java package name, artifact ID normally comes from your jar file name. The version and the name should be obvious.

The second part is a little Ant build script that tells Maven what files to deploy. If you are picking up jars that are built elsewhere, all you need is the tasks. You can see two variations of the task above that attaches the main jar and the source zip. If it takes a bit of massaging to build them, you can add more Ant tasks here to get the job done. In the above example, I'm really calling into Ant to build the source zip.

Oh, and to do this, you need to have the repository publisher role in the Maven2 repository project, and a file that contains your credential to deploy files to the repository.

Related Topics >>


com4j is already available in

And believe it or not, org.jvnet.PROJECT is the "correct" package name for projects (even though there are many projects that don't follow the convention.) Powers-that-be felt that the use of "java" in the package name "" was too confusing.

Hello kohsuke, Could you put your com4j librairie in directory ? May be your package name is not "standard" ( may be more correct) I use com4j to interface HP/Mercury TestDirector COM API with Eclipse Mylyn connector. I see all defects and attachments files store in TestDirector in Eclipse Mylin. And i use maven, hudson (maven, checkstyle, pmd, violation, disk usage), artifactory for others projects. Thank. Vincent

You probably just run the mvn install. That is a great first step to make sure your artifacts are good, but to actually deploy this to, you need to do mvn deploy.

Hi kohsuke, I've tried your example pom.xml, but it installs in a local repository ($HOME/.m2/repository) as opposed to Perhaps I'm missing a maven plugin that parses a "java-net:/" URL (I'm using mvn 2.0.6 distributed with OSX).

cvidal -- Thanks for the pointer to Mavenizer. It's an interesting project (and I noticed that it's using JAXB, an extra plus point for me!.) In case of JNA, this library really doesn't have any dependencies, but the approach outlined in my posting obviously lets you define dependencies or any other POM entries easily.

coding -- Yes, if the audience of the artifacts are limited to your intranet, a repository manager would make a lot of sense.

For our environment we use Archiva to host our Maven repository. The latest version just released a few days ago allows web-based uploads. Before that I wrote a swing GUI that lets you drag-drop a jar to a text-field, enter a group, artifact and version. Finally it lets you enter a username and password (although Archiva does have a way to allow guests deploy too, which for now we have enabled (intranet), but as Maven gets used more and more at our company, we may disable that. When you fill everything out, it actually creates a POM on the filesystem and calls mvn to do the deploy-file goal. It worked pretty well.

Hi Kohsuke, Your advice is very interesting indeed. The problem I see is that the library you're mavenizing most likely has dependencies which might or might not exist in Maven repositories yet as well. And Maven poms have real value when those transitive dependencies are properly defined but getting those straight can be really cumbersome. In order to ease that process, you might want to give a look at Mavenizer: It's a command line tool which assists with mavenizing those third party libraries and generating good quality maven metadata. There's a flash demo which shows the mavenization of jfreereport: Kind regards, Cédric Vidal