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

Bug 329973

Summary:	Can EPP packages have more than one top level feature, to make updates easier?
Product:	[Technology] EPP	Reporter:	David Williams <david_williams>
Component:	Packager	Assignee:	Project Inbox <epp.packager-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	mknauer, remy.suen, steffen.pingel, tjwatson
Version:	unspecified
Target Milestone:	1.3.0
Hardware:	PC
OS:	All
Whiteboard:
Bug Depends on:
Bug Blocks:	265948, 332989

Description David Williams

2010-11-11 03:14:25 EST

Currently EPP packages have one "top level" feature. I'm not sure if this is required for technical reasons, but has the disadvantage that maintenance can not be "automatically" applied, that is, as discovered updates or patches, unless that top level feature is updated or patched. 

The use-case, for example, is if a very bad bug is discovered, say, in the XML Editor, such that we'd want to provide a patch for it, then users have to know to go and find and install that patch. It would not be found if users simple used the function to "check for updates. But, if users had explicitly installed the XML Feature, then it would be a top level feature (along with other top level features) and a "check for updates" would find it automatically. 

At least, that's my understanding. 

Think we can improve the "update story"?

Comment 1 Markus Knauer

2010-12-21 06:13:02 EST

In fact, the solution for the EPP packages that we have today is there for historical reasons.

But the current behaviour could be seen as a feature: A package maintainer is testing a certain configuration (a combination of features in a specified version) of a package. Now let us assume that this package contains some artifacts from  project FOO that releases a new version after the initial package release. With the current approach it is the package maintainer who is responsible for any updates and changes to his/her package, or in other words not possible to change the content that has been specified by the package maintainer. Especially with e4 this approach has its advantages.

Apart from that I did some experiments back in May this year. I tried to move the dependencies from the defining package feature into a p2.inf file, but either I did it wrong or it is not possible to make those sub-features into updatable roots with the p2.inf mechanisms. Any ideas?

Comment 2 David Williams

2011-05-12 11:36:42 EDT

I'd like to close this (my own bug) as "won't fix" ... if anyone disagrees, feel free to re-open. 

The reason is that, as Markus says, it is working as designed, and as intended, and doing it this way has some advantages (in terms of maintaining a "solid", clean/consistent) install. 

I think there could be some "easy of use" improvements still made, in future, but I think it'd have to be something more at p2 and/or p2 UI level, so it would be a user preference, somehow. That is, it needs to be a user driven choice that they would be mucking with their "product install". I've no idea how to do that, or what it would look like, so won't open an enhancement request just now ... but, if anyone else has ideas or different opinions, feel free. I do think usability (or ... flexibility) can be improved ... just not sure automatically having more "top level features" is the right way to view the solution (or ... that having just one is "the problem")?