Zest 2.0

[ptziegler]

Motivation

Throughout the migration from SWT to FX, Zest received several bugixes, as well as a (from my perspective) cleaner API. With https://github.com/fsteeg/zest, containing the latest version that is still using SWT, we now have the unique opportunity to reintegrate those changes.

Goal

• Full integration of Zest Layouts, Core, JFace and CloudIO, but not DOT (due to dependencies to XText/EMF).

• Backwards compatibility with Zest 1.x layouts: Layouts are the bread and butter of Zest. Downstream projects should be able to use their custom layouts without requiring major changes.

• Preservation of new Zest 1.x features: Our own implementation of Zest has evolved throughout the years and now contains functionality that never existed in Zest 2.0. Those features must not be removed.

Non-Goal

• Source and binary compatibility. As indicated by the increased major version, classes may be renamed, moved our outright deleted.

Tasks

• Reintegration of Zest 2.0 via Reintegration of Zest2.0 fork #410
  • CloudIO
  • Core
  • Example
  • JFace
  • Layouts
  • Tests
• Removal of internal references to deprecated API
• Update of documentation
• Due dilligence process for new contribution

Following classes will be marked for removal and are no longer considered API:

• Filter
• LayoutEntity
• LayoutItem
• LayoutIterationEvent
• LayoutRelationship
• LayoutStyles
• NestedLayoutEntity

[azoitl]

@ptziegler thx for this very nice summary on re-integrating Zest 2.0. Should we announce this also on the GEF and maybe also on the cross-projects mailing lists to get a wider reachability of this news.

[ptziegler]

Should we announce this also on the GEF and maybe also on the cross-projects mailing lists to get a wider reachability of this news.

It'll probably still take a few months before everything is done, so I think that's a little premature. But it makes sense once the updated API is somewhat cleaned up and functional.

[azoitl]

It'll probably still take a few months before everything is done, so I think that's a little premature. But it makes sense once the updated API is somewhat cleaned up and functional.

Ok that is a good point. I thought more as a pre-anouncement that Zest users can get a a heads-up.

Should we set-up a dedicated branch for that work?

[ptziegler]

Should we set-up a dedicated branch for that work?

The branch already exists. A lot of the classes overlap with one another, so I don't think it's possible to reintegrate #410 without also addressing the API which is why everything has to be done in one go.

I thought more as a pre-anouncement that Zest users can get a a heads-up.

Which is something we should certainly do. I just don't see that there is anything more to say than "We'll eventually move to Zest 2.0".

[ptziegler]

Which is something we should certainly do. I just don't see that there is anything more to say than "We'll eventually move to Zest 2.0".

Hopefully I can make some time to continue working on this again tomorrow or within the next few days. Once I have a rough idea I can also draft an email.

[azoitl]

Should we set-up a dedicated branch for that work?

The branch already exists. A lot of the classes overlap with one another, so I don't think it's possible to reintegrate #410 without also addressing the API which is why everything has to be done in one go.

I thought more like a feature branch in this repo here. So that we can work in parallel and merge it back to master when its ready.

I thought more as a pre-anouncement that Zest users can get a a heads-up.

Which is something we should certainly do. I just don't see that there is anything more to say than "We'll eventually move to Zest 2.0".

I was also not sure what to announce.

Hopefully I can make some time to continue working on this again tomorrow or within the next few days. Once I have a rough idea I can also draft an email.

If I can support you in any way. Let me know.