Difference between revisions of "Slingshot"

Revision as of 13:17, 9 November 2010

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

Aggregator

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.

• Includes only integration and release builds
• Copies artefacts into a copy repository;
• Retains all artefacts

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

Repository

• 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!

Benefits

• Easier for developers to get the project bits
• Avenue for projects to gain exposure
• Not indended for end users
  • No quality assurances

Technical Requirements

What do we need to make this real? Time on Hudson and some space on the downloads server? How much time? How much space?

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?