RC1 of Testing Ready For Testing [Updated]

15. May, 2011

I’ve recreated the testing repository using the latest version of my Maven Tools 4 Eclipse.

To browse the repository, please use the Nexus interface.

If you pull in any dependencies from the repository, non-Eclipse artifacts will come from from Project Orbit. If you want non-Eclipse dependencies (like log4j) from Maven Central, you need to change your profiles.

Deactivate “m4e.orbit” and activate “m4e.maven-central“. From the command line, that’s “-P m4e.maven-central” but I suggest to put these into your settings.xml (add “<activeProfile>m4e.maven-central</activeProfile>” to it).

Note that you don’t need to deactivate the profile m4e.orbit. As soon as you specify a profile on the command line or via the settings, it’s deactivated automatically.

“mvn help:active-profiles” and “mvn dependency:tree” are your friends.

Let me know if you find anything missing, odd, broken by  filing a bug or posting a comment here.

UPDATE 2011-05-30

Some dependencies from the new repo can also be found on Maven Central. One nasty problem is that both repos contain org.eclipse.equinox.app but the version from Maven Central contains odd dependencies which break your build.

To fix this, add this to your parent/root POM:


This will limit all version ranges to the versions found in our new repository. Since Maven Central didn’t import new versions for at least one year, this should fix all problems.

Related posts:

Maven Tools for Eclipse: Patching POMs

11. April, 2011

I’ve added a new feature to my Maven tools for Eclipse: Applying patches to POMs.

This is a first step towards solving issues like this one: Bug 342046 – Invalid third party dependencies in Mavenized BIRT plugins

I’m not 100% happy with the result, though. Currently, the patch overwrites the original code. I think it would be much better if it created a profile instead. This way, you could see the original code and it would be simple to switch between different solutions for a problem in a POM.

The two standard problems are:

  • Bad version (no version, version range or wrong version)
  • Dependency name

The latter is introduced by the fact that Eclipse projects need to pull dependencies via Project Orbit. Orbit often renames dependencies so there is a naming conflict if you pull your dependencies from Maven Central. So we need a way to say “I’m using Orbit” and “I want Maven Central”.

Eclipse 3.6.2 Artifacts for Maven 2

20. March, 2011
Apache Maven logo.

Image via Wikipedia

Update: The project has its own web site, now.

Two days ago, I told you about Project Dash and my new tools for it. Well, we did run them over the weekend and import a lot of stuff from Eclipse 3.6.2 into a brand new testing Maven 2 repository.

So if you want to use Eclipse bundles in Maven 2 for your own projects (SWT, EMF, even BIRT), have a look and let me know:

  • Did I miss anything?
  • Is anything wrong? Version numbers, names, dependencies, optional dependencies.
  • Any other comments?

Making the world a better place, one line of code at a time! :-)

The tools are here.

New project home page: Maven Tools 4 Eclipse

Project Dash m4e Tools – Create Maven Artifacts From Eclipse Plug-ins

18. March, 2011

[UPDATE] There is now a testing repo which contains Eclipse 3.6.2

If you use Maven and Eclipse, you know the pain: How do I convert Eclipse plug-ins into Maven artifacts?

The simple step is to run mvn eclipse:make-artifacts (or the ill fated eclipse:to-maven).

But that’s only half of the work. A few of the plug-ins have bad dependencies (stuff isn’t declared optional, polluting your runtime classpath; versions of dependencies are missing). And a major problem is source attachments. Eclipse separates those from the binaries, so you end up with org.eclipse.core.runtime and org.eclipse.core.runtime.sources.

A few days ago, bug 337068 – “Please set up maven.eclipse.org” was fixed. The site exists and there is even a Nexus running on it.

Unfortunately, it’s a bit empty for now. We’re working on it :-)

One of the first steps is a set of tools that takes downloads from eclipse.org and converts them into proper Maven artifacts – with source and all.

Welcome Project Dash m4e Tools. A preliminary version is available on github: https://github.com/digulla/org.eclipse.dash.m4e.tools

It consists of three tools so far:

  1. m4e-import can import downloads (archived or unpacked) into a temporary Maven 2 repository. Your own local repository (${user.home}/.m2/repository) is left untouched!
  2. m4e-merge can merge several a temporary Maven 2 repositories into one.
  3. m4e-attach-sources tries to find all source bundles, moves+renames the source JAR to the right place and name and deletes the unnecessary folder.

Next step is a tool to patch the artifacts. One open issue is: How to handle dependencies which come from Project Orbit (bundling third party libraries for Eclipse projects).

Please visit Bug 340416 – “Resolving dependencies from Project Orbit” if you have an opinion.

Maven 3.0 is here

18. October, 2010

Maven 3.0 has been released.Maven Logo

Using the FindBugs plugin for Maven with Java 5

16. July, 2010

If you use the Maven 2 FindBugs plugin with Java 5 code, you will get a lot of errors like:

    Can't use annotations when running in JDK 1.4 mode!
    Can't use JDK 1.5 for loop syntax when running in JDK 1.4 mode!
    Can't use generics unless running in JDK 1.5 mode!
    Can't use enum as a keyword in pre-JDK 1.5 target

The solution is to set the targetJdk (even though this option isn’t mentioned in the docs and even mvn help:describe can’t find it):


Note that you should clean your project; otherwise the new option may not be used for some reason.

Attaching Sources To Eclipse Artifacts

8. October, 2009

After running mvn eclipse:make-artifacts -DstripQualifier=true -DeclipseDir=...path/to/eclipse, you might have lots of source JARs but they aren’t in the right place for Maven 2 to pick them up.

This little Python script fixes that. Just run it after eclipse:make-artifacts.

Note: You may be wondering why I use eclipse:make-artifacts instead of the recommended eclipse:to-maven. Simple: I don’t like to have a dozen core-*.jar in my project.

"""Maven 2 Eclipse Artifact Source resolver

After importing Eclipse artifacts into an M2 repository with

> mvn eclipse:make-artifacts -DstripQualifier=true -DeclipseDir=.../eclipse

run this script to move all source JARs in the right place for
Maven 2 to pick them up.
import os, sys
from shutil import copyfile

def processGroup(path):
    print 'group %s' % path
    for dir in os.listdir(path):
        path2 = os.path.join(path, dir)
        if '.' in dir:

def processArtifact(path):
    srcPath = path + '.source'
    #print 'processArtifact',srcPath
    if os.path.exists(srcPath):

def processArtifactWithSource(basePath):
    binPath = basePath
    srcPath = basePath + '.source'
    baseName = os.path.basename(basePath)
    print 'artifact', baseName
    for version in os.listdir(binPath):
        vbinPath = os.path.join(binPath, version)
        vsrcPath = os.path.join(srcPath, version)
        srcJar = os.path.join(vsrcPath, '%s.source-%s.jar' % (baseName, version))
        destJar = os.path.join(vbinPath, '%s-%s-sources.jar' % (baseName, version))
        if os.path.exists(srcJar):
            print '%s -> %s' % (srcJar, destJar)
            copyfile(srcJar, destJar)

m2repo = os.environ['M2_REPO']
if not m2repo:
    raise Exception('Env variable M2_REPO is not set')

root = os.path.join(m2repo, 'org', 'eclipse')
for dir in os.listdir(root):
    path = os.path.join(root, dir)

Updated 01. December 2009: The script now figures out where your M2 repo is. Plus a minimum of documentation.


Get every new post delivered to your Inbox.

Join 334 other followers