Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Slingshot"

Line 43: Line 43:
 
*Not indended for end users
 
*Not indended for end users
 
**No quality assurances
 
**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?

Revision as of 13:12, 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?

Back to the top