Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-ui-dev] Some thoughts on the E4 compatibility story
On 5-Dec-2011, at 10:11 AM, John Arthorne wrote:
In practical terms e4 is still officially an incubator at Eclipse and can't ship non-incubating code. There has to be a way to distinguish all the various ongoing incubating work from the more mature stuff that is in the Eclipse 4.x stream, at least within the small circle of people following the project closely.

I suggest a capitalization, "e4" vs "E4".  E4 is the big brother ;)

On 7-Dec-2011, at 4:35 PM, Eric Moffatt wrote:
Brian, first I've gotta say that I really like your comment about Eclipse 4 separating the UI 'mechanisms' from the UI 'policy'...can i use this at EclipseCon ? (properly attributed of course...;-). 

The mechanism/policy distinction is a standard description used in the OS research community, so you should free to re-use it as you like!

Hmmm, your taxonomy is interesting…  But I think there's value in separating the Eclipse 4 ("compat layer") parts into two parts: the E3 UI paradigm, what John's calling the Workbench, which also includes the extensibility/integration focus (e.g., with other Eclipse tooling); and the backwards compatibility support for the E3.x APIs ("E4 Classic?").

And in terms of terminology, there's a lot of mindshare in the community around "E4" and "Eclipse 4", so I think we should try to distinguish the layers using a suffix against "E4" or "Eclipse 4".

So here's my attempt to recast Eric's model with my separation above.
  • E4 Core: the underlying 'core' APIs (the modelled UI, CSS, DI)
  • E4 Application Platform: startup (E4Application) + extensibility (processors, fragments); lightweight policy layer (SWT binding, the base services)
    • This is what the contact demo is programmed against.
  • E4 Workbench (?): Implements the Eclipse 3.x UI paradigm + good bits from E3.x
  • E4 Classic: provides backwards compatibility to E3.x APIs (e.g., the org.eclipse.ui.{views,menus,editors} extpts); functionally identical to E4 Workbench
Right now, the E4 Workbench and E4 Classic are merged together.  Ideally they can be pulled apart.  "Workbench" is a great term except that we have an org.eclipse.e4.ui.workbench.* too, which would be in the E4AP.

Consider a new Eclipse project is starting up from scratch. Ideally we'd want them to work against the Workbench APIs (e.g., defining stuff in the .e4xmi) vs using the older extension points in E4 Classic.  My clients are in a similar situation, as they want to be able to integrate with other Eclipse-based tools (e.g., BIRT, Teiid, perhaps even JDT!), so they do *not* want to just use the E4 App Platform.  Although they'll need to ship with the E4 Classic to enable plugging in with other packages, they want to avoid using the E4 Classic APIs though too.

I think we should really work on getting this figured out so that we have a common terminology for EclipseCon.  It'll be confusing for people to have to reconcile Eric's terms with Tom's terms with Paul's terms with my terms…

Brian.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Back to the top