Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 297533

Summary:	Create aggregate project p2/maven repository
Product:	Community	Reporter:	Wayne Beaton <wayne.beaton>
Component:	Cross-Project	Assignee:	Cross-Project issues <cross-project.inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	gabe.obrien, henrik.lindberg, Kenn.Hussey, kim.moir, mitch.sonies, mober.at+eclipse, thomas, webmaster
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:

Description Wayne Beaton

2009-12-10 15:37:44 EST

"Cross-Project" seemed like the most appropriate place to put this. Correct me if I'm wrong.

Mitch, Henrik, and I have been discussing the creation of a new aggregate p2 repository for Eclipse projects. I've opened this bug to track the discussion.

This repository is separate from the release train repository. This new repository is not intended to replace, but rather to augment the release train repository. It provides projects that are not ready (or are not appropriate) for the rigors of participating in the release train with an means to gain additional exposure to a wider community. The repository will be accessible either via p2 or Maven.

To participate in the aggregated update site, projects are required to specify the URL of a p2 repository and a contact email address. We propose that these values can be captured in the "Project metadata" through the developer portal and made avaiable to the aggregator via a RESTful web service interface.

The aggregator periodically (on the order of nightly or weekly) pulls together the bundles/features from the collection of repositories, ensures that the required dependencies are available, and assembles the aggregation. Only features for which all dependencies can be resolved are included. If a feature's dependencies cannot be resolved, a message is sent to the contact email address informing the receiver of the error.

The aggregated repository connects (via reference) to the most recent version of the release train repository.

The aggregator mirrors the contents of the repositories it aggregates. It retains all code artefacts, including older versions. We need to assess the potential disk space requirements.

We require that projects provide us only with "release" repositories (certainly not nightly or integration builds). This contraint may introduce a need to add an authorization step to the workflow (perhaps the PMC will have to authorize the request to aggregate a repository).

We have to develop a strategy for dealing with the relatively rare case when we are required to remove an artefact for IP reasons.

We leverage the categories provided by the project repositories. We may need to revisit this strategy if the categorization becomes cumbersome.

The repository itself will be hosted on download.eclipse.org.

We need a name for this beast.

Your input is welcome.

Comment 1 Kim Moir

2009-12-10 16:15:01 EST

I would suggest sticking to aggregating integration builds. Nightly builds aren't really useful other than a sanity check. Also, many projects replace the qualifier with the buildId in their nightly build bundles so they're not useful to for upgrading with p2. Nightly build repos tend to provide new bundles for everything, integration build repos only provide deltas when upgrading with p2.

Comment 2 Wayne Beaton

2009-12-10 16:47:30 EST

Somebody from the Equinox incubator has to nominate your committers.

Comment 3 Martin Oberhuber

2009-12-11 00:27:25 EST

+1 this sounds like a great idea. 

My only concern is that since this is for projects "not ready for the release train", that one project may break others by contributing something invalid. What about a project which incorrectly contributes a too high version number for a bundle, for instance? Or has incorrect dependencies somewhere?

There seems to be a risk for that aggregate repo thing to consume a lot of maintenance effort for keeping things straight. If I look at how much effort Dave Williams has in keeping the train repo usable, the idea of having something similar for projects who are not on the train (and may thus be less mature) is making me shudder slightly.

Comment 4 Wayne Beaton

2010-04-14 15:23:18 EDT

Mitch has proposed the name "Slingshot". I like it. Thoughts?

Comment 5 Gabe O'Brien

2010-04-16 12:31:25 EDT

(In reply to comment #4)
> Mitch has proposed the name "Slingshot". I like it. Thoughts?

+1 for slingshot

Comment 6 Denis Roy

2011-03-10 14:13:55 EST

Should we mark this as depending on bug 337068?

Comment 7 Denis Roy

2012-11-08 16:30:00 EST

Wayne, what's the status of this?

Comment 8 Wayne Beaton

2012-11-08 16:33:51 EST

(In reply to comment #7)
> Wayne, what's the status of this?

Dead