Jump to: navigation, search


More discussion in Bug 297533.

What is it?

Slingshot is an Über Repository for Eclipse Projects

  • An aggregate repository
    • Like the simultaneous release repository
    • But without the rigours (or quality assurances)
  • A means for projects to extend their reach
  • Manifests as a p2 and Maven repository
  • Target Audience
    • Developers/Committers
    • Adopters
    • Not intended to be included in packages
    • Not for end-users


Slingshot is a p2 repository aggregator. It gathers the contributions from multiple project repositories, and combines them into a single repository that is accessible as both a p2 and Maven repository. Only code that has resolvable dependencies is included in the aggregate repository. Unresolved dependencies are reported back to the project.

Opt in

To participate in Slingshot, a project must provide a "contribution" file (which uses the same format as the release train). This file is typically stored in the project's website CVS. A pointer to this file is provided via the portal using the Project's "slingshotconfigurationurl" attribute (this is a single absolute URL).


  • Links to simultaneous release repository (i.e. everything in the simultaneous release is automatically accessible through Slingshot)
  • Retains no artifacts itself, but rather provides pointers to repositories individually maintained by the projects (this is to reduce the already out-of-control duplication on our download server)
    • Ideally restricted to milestones and release builds only (but it is ultimately up to the projects to decide what they're going to include)
  • Only includes artifacts with resolvable dependencies
    • Facilitates reproduceable builds
  • Categorizes based on project structure
  • Automated
    • Email notification if dependencies cannot be resolved.
    • We don't chase down your dependencies
    • If your project depends on another project's output, it is your responsibility to make sure that the other project participates
    • That's your job!


  • Easier for developers to get the project bits
  • Avenue for projects to gain exposure
  • Not indended for end users
    • No quality assurances
  • Support for Maven-based builds using Eclipse Technology


  • Who decides what goes into the repository?
    • Ideally restricted to milestone builds
    • Projects provide their own configuration, they can contribute whatever they choose to contribute?
  • Once-in-always-in?
    • If projects maintain their own artefact repositories, we are at their mercy to maintain them and not change them in ways that confuse or damage consumers
  • We really can't make yet another copy of artefacts
    • Our downloads server is already approaching (exceeding?) the TB mark
    • If we make a copy, then we need to have a mechanism for removing things that have been included in error
    • Working from a project-provided p2 repository reduces the maintenance burden and increases our probability of success

Technical Requirements

  • Build scripts run nightly on Hudson
  • Repository metadata written to /downloads

Other Requirements

  • Landing Page (how do we find/explain it?)
  • Trademark issues with the name?
    • Do we even use this name externally? Or is this just the "Eclipse Über Repository"?
    • FWIW, I do like the use of the term "Über", but recognise that we need to be slightly more professional here.
  • Who will provide support and bring people up to speed with this?
    • My sense is that the steady state should require relatively little support, but somebody will have to pay attention to the Hudson job to make sure it doesn't fall over.
  • What else am I missing?