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

Bug 318485

Summary:	Zest extensibility
Product:	[Tools] GEF	Reporter:	Tim deBoer <deboer>
Component:	GEF-Legacy Zest	Assignee:	gef-inbox <gef-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	gregory.amerson, nyssen
Version:	3.6
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description Tim deBoer

2010-06-30 11:13:52 EDT

I've opened several bugs against Zest lately, and the most frustrating part has not been the bug themselves (bugs happen, even to the best programmers), but that Zest has been built in a way to block adopters from tweaking, subclassing, or extending Zest to fix or workaround these problems.

Zest is cool and really powerful on it's own, but as a result any problem or minor addition can be like hitting a brick wall. I've run into several cases where the only options are to reimplement/redesign a large part of Zest, or branch the code entirely. Compared with (for example) the Eclipse platform, the code is very defensive towards adopters.

Some suggestions:
 - Export the internal packages in the manifest using x-internal:=true.
 - Reduce use of private members, or provide protected accessors to them.
 - Move creation of private members to their own factory methods.
 - Reduce casting to Zest classes, especially private ones.
 - Reduce use of private and package-protected methods.
 - Use coding conventions from Eclipse platform.

Comment 1 Alexander Nyßen

2014-08-08 09:23:41 EDT

We are currently building up the next generation Zest API in terms of GEF4 Zest (which is not so restrictive), and as fundamental (i.e. breaking) changes to the Zest 1.x API will not be performed any more, I am resolving this as WONTFIX.