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

Bug 313792

Summary:	Review provisioning capabilities of eclipse
Product:	z_Archived	Reporter:	Pascal Rapicault <pascal>
Component:	E4	Assignee:	Project Inbox <e4.runtime-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	irbull, kim.moir, pwebster, tjwatson
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	All
Whiteboard:

Description Pascal Rapicault

2010-05-20 14:50:27 EDT

Since e4 is about shaping the future of the platform, a few weeks back during the p2 call we have discussed what we wanted to see happening in e4 wrt to provisioning. Several things came up:
1) Get rid of the org.eclipse.update* bundles
2) Replace the dropins support to something more structured that would behave more like what the UI does. We called that the "install-in".

Comment 1 Ian Bull

2010-05-20 15:05:17 EDT

A few more questions:
1. IIRC, the plugins/ features/ folders act as a drop-ins (you can still unzip over your install). Do we want to keep this behaviour?

2. What about the platform.xml (this is likely covered in the org.eclipse.update* bundles)?

3. Do we need to / want to keep shipping features?

4. Do we want to continue to support site.xml (publish them and consume them as p2 repos)?  (Again, it might be part of org.eclipse.update*, but this will probably require an explicit decision).

Comment 2 Pascal Rapicault

2010-05-20 20:26:21 EDT

Thx for these additions Ian.

> 1. IIRC, the plugins/ features/ folders act as a drop-ins (you can still unzip
> over your install). Do we want to keep this behaviour?
  No.

> 2. What about the platform.xml (this is likely covered in the
> org.eclipse.update* bundles)?
  This is covered in platform.xml

> 3. Do we need to / want to keep shipping features?
  We can try, but I think this would mean changes in PDE around how they deal with grouping.

> 4. Do we want to continue to support site.xml (publish them and consume them as
> p2 repos)?  (Again, it might be part of org.eclipse.update*, but this will
> probably require an explicit decision).
  Yes, we want to be able to keep installing from legacy update sites. However this support is already in a separate plug-in: org.eclipse.equinox.p2.updatesite.