Eclipse Maven Repository

Bug 283745 proposes that we build and maintain a Maven repository at Now, I’m not a “Maven Guy” (only because I haven’t yet had any real need to use it), but it seems like a pretty good idea to me. We discussed this bug at today’s Architecture Council meeting.

Do you agree that this is a good idea? Would you use it?

We discussed first creating a repository of artifacts from the Orbit project. I think that this could be useful, but my gut tells me that it would be more interesting and useful if we provided some mechanism for projects to promote arbitrary artifacts from their projects into the repository.

Unfortunately, I don’t know enough about Maven to know what’s possible and what is reasonable. Do we have to manage the kinds of things that projects promote into the repository? Is this something that should be part of the release train, or should it have a broader reach? Does it make any sense to promote nightly or integration builds?

Feel free to post your comments on this blog, but it would be more useful if you added your thoughts to the bug (especially comments to the effect of “I would use this”, and “I want to help make this happen”).

This entry was posted in Community. Bookmark the permalink.

8 Responses to Eclipse Maven Repository

  1. Ren says:

    I would definitely use it 😉

  2. Kristoffer Peterh?nsel says:

    As I am doing an Eclipse-based project, and attempting to build it in Maven (PDE/Maven interaction is somewhat sketchy at the moment). It would certainly be nice not to have to maintain the Eclipse projects manually on our local repository server.

    I’m sure the ops4j/PAX Runner guys would be happy not to have to maintain their own repository with the Equinox bundles as well.

  3. Sebastian says:

    This is definitely needed. Currently others (outside eclipse) host lot’s of eclipse artifacts under the groupId org.eclipse. Worse: these artifacts are broken, inconsistent and all different – sometimes without any stated dependencies.

    Eclipse should move into this area and it should be at least part of the release train. One repository for all eclipse projects seems a good option. However you will need volunteers inside eclipse foundation (and maybe Eclipse IAM project?!) to maintain this repository. Building eclipse itself with maven is another topic, but publishing eclipse bundles is possible with “mvn eclipse:to-maven” and some extra manual checks.

    If you want to promote nightly / integration builds – this is called “SNAPSHOT” in maven and makes to me only sense when eclipse is build with maven. Please remember: a public repository has to guarantee a high degree of consistency and correctness. Currently this seems only be maintained for maven central and a few others. This “rule” – the foundation of maven – might be softended for a (separate) snapshots-repository. However the amount of artifacts (per day!) leaves you to totally trust “mvn eclipse:to-maven” for this. Perhaps invastigating it’s correctness should be done by eclipse foundation.

    In closing: having maintained, correct eclipse artifacts in an official eclipse maven repository is needed and was far too long not discussed, plannend, an option.

  4. Bob says:

    I agree that an eclipse repository is needed, and that the current deployment to maven ibiblio is broken as far as version numbers and valid dependency ranges and actual dependencies. The fornax repository has it almost correct, as well as several others. Also needed in the repository are SOURCE artifacts, which can be deployed with the -sources qualifier the same way the current build artifacts are deployed. Right now I create these source artifacts myself, for every point release, and manually deploy to an internal repository (we do a lot of UML2 work internally, using maven as the build engine). IMHO, one of the main benefits of using Eclipse together with maven is the ability to automatically reference source artifacts in your development environment, using the eclipse-maven plugin takes care of this when the project is created or modified.

    Also, the dependency management mechanism of maven (the other great advantage of the product) and parent/child project -> project or artifact convention should be maintained, which requires a mapping of the standard flat project hierarchy seen in Eclipse.

    Comments left at Bug 283745 and 288644 (about the proposed groupId/artifactId convention, different than the convention used for all the other maven projects).

  5. Thiago Moreira says:

    I would use it! Right now this is the only thing that is preventing me to have my project in continuous integration hosted service.

  6. Stevo says:


    Tried to add JavaSE-1.7 execution environment in eclipse 3.5 using maven, but could not find (all) eclipse 3.5 module artifacts in public maven repositories.

  7. Eirik Rosvold says:

    I would use it.

  8. Jos says:

    Yes we need it, we are one of the groups that made this request. We use maven for our continuous builds and they need to be independent of Eclipse.
    Currently we are hosting a large number of Eclipse plugins as maven artifacts for our Mod4j project. We took the trouble to re-name them all with our own prefix (***) to ensure that they will never conflict with “official” eclipse maven artifacts.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s