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:

  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.eclipse.dash</groupId>
        <artifactId>dependency-management</artifactId>
        <version>3.6.2</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
    <dependencies>
  <dependencyManagement>

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:

• Eclipse 3.6.2 Artifacts for Maven 2
• Maven Tools for Eclipse: M2 Repository Analysis And Dependency Management
• Maven Tools for Eclipse: Patching POMs
• Project Dash m4e Tools – Create Maven Artifacts From Eclipse Plug-ins

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

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

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.

Related Articles

• The original blog post by Jason van Zyl: Apache Maven 3.0 has landed!
• Maven 3.0 released (maven.apache.org)

    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):

                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>findbugs-maven-plugin</artifactId>
                    <version>2.3.1</version>
                    <configuration>
                        <targetJdk>1.5</targetJdk>
                    </configuration>
                </plugin>

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

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:
            processArtifact(path2)
        else:
            processGroup(path2)

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

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)
    processGroup(path)

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

While a simple task at first glance, there are a few hidden obstacles which boil down to two things: Downloads via the Internet and plugin or dependency version stability. Both can be solved by a using a proxy or a in-house repository.

The guys from Sonatype have been busy in the last months and have released Nexus 1.0.0-beta-4.2 which gives you another option to chose from besides Archiva or DSMP (my own Maven 2 proxy). I’ve tried Nexus yesterday and I have to say that I’m very pleased with the result. As usual for Open Source Software, the beta is more stable than some post-beta commercial products and it delivers with very little setup (follow the link to see the documentation).

Now, we have a second issue: version stability. Here is my recipe to achieve that. First of all, version anything in your POM. All dependencies, all plugins, everything. I’m using properties for that which I define in a common parent POM plus I’m using the dependency management. Maven 2.0.9 helps a lot here because it forces you to add version elements everywhere.

The next step is to make sure the maven builds can find their stuff. To do that, I suggest to set up two Nexus repositories. The first one is the “build” repository, the second one is the “cache” repository. While all developers should use the “build” repository, the “cache” repository can actually download dependencies from the Internet.

The “build” repository, on the other hand, is just a local repository with no Internet connection. To avoid mistakes, I suggest to install the build repo with the default settings but with all remote repositories deleted or turned into local ones. The “cache” repository should run on an unusual port and with the remote repositories enabled as described in the installation documentation.

Next, you need to create a profile in your settings.xml which switches mirrors between the two. When you want to check out a new version of some plugin, switch to the cache repository and have it download all the new stuff. This will pollute your local copy of the maven repository but only yours. After you have verified that the build completes (or fixed all the problems you’ve got), check the RSS feeds of Nexus for stuff it downloaded. Then, all you have to do, is to copy those to the “build” repository. After a refresh, all the other developers in your company can use the new, verified downloads.

Clean your local repository and build again to make sure that your colleagues won’t have any problems after the change and you’re set.

They presented the EL4J project which is the result of several years of developing web applications. From what I gathered, it makes it a bit more simple to wire web apps together using a bit of convention over configuration and Maven 2. It also has some Swing support in it.

java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-resources-plugin] was not found.
        at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:325)
        at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:212)
        at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:176)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1274)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1542)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1033)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:997)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:477)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)

When you see this, check:

1. That the JAR file of the plug-in is okay and that it contains a file META-INF/maven/plugin.xml
2. That the pom.xml of the plug-in exists and is valid.
3. That all parent POMs exist and are valid.

Good luck. I’ve opened this issue to get a better error message.