Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Slingshot"
(→Technical Requirements) |
(→Opt in) |
||
Line 19: | Line 19: | ||
==Opt in== | ==Opt in== | ||
− | To participate in Slingshot, a project must provide a "[[Helios/Contributing to Helios Build | 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). | + | To participate in Slingshot, a project must provide a "[[Helios/Contributing to Helios Build|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== | ==Repository== |
Revision as of 12:22, 11 November 2010
More discussion in Bug 297533.
Contents
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.
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
- 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?