New Release of MT4E

24. August, 2011

Note: This post is now obsolete since there is a newer release.

I just finished a new release of Maven Tools 4 Eclipse. It’s not written in Groovy and supports all the features of the old Python version plus a few new ones.

You can find instructions how to use it on the wiki page.

For now, you need to build the tool from source (which needs 1.4-SNAPSHOT from DecentXML) using Maven. I’m in discussion with the people at Eclipse to get a download link for the binary.

Update: The project page now has a download link.

New Website for Maven Tools For Eclipse (MT4E)

13. July, 2011

My Maven Tools for Eclipse (MT4E) project has now a wiki page:

And I’ve started to convert the tools from Python to Groovy.



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 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: M2 Repository Analysis And Dependency Management

13. May, 2011

I’ve finished RC1 of my set of tools to import Eclipse plug-ins into Maven 2 repositories. You can find the source on github. It needs Python 2.7 and lxml. pip is your friend.

The new features: There is now a tool to analyze the M2 repository for oddities. Currently, it can find these issues:

  • Dependencies which are used but not part of the repository
  • Dependencies which are used with different versions or version ranges (i.e. when one POM includes a dependency with 1.0 and another POM pulls in the very same dependency with version 1.1)
  • Dependencies which are used without versions or version ranges or a catch-all version like [0,)
  • Several versions of the same artifact in the repository

Plus it prints a list of all POMs in the repo with files (jar, pom, sources, test-sources, …). Here is a sample report.

The last tool can create a POM file with a dependencyManagement element containing the versions of the POMs in the repository. You can use this to nail down all versions to the ones existing in your repository (so you don’t accidentally pull in something you don’t want).

Lastly, I’ve enhanced the patch tool. Instead of overwriting replaced dependencies, it will now move them into a new profile. This way, users of the repository can specify which dependency they want (the one from the repository or, say, one from Maven Central).

I will try to build a new testing repo over the weekend so we can start wrapping up the necessary patches for a release.

Related posts: Eclipse 3.6.2 Artifacts for Maven 2

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”.

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” 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 and converts them into proper Maven artifacts – with source and all.

Welcome Project Dash m4e Tools. A preliminary version is available on github:

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.


Get every new post delivered to your Inbox.

Join 314 other followers