Move exampleStructures and exampleUses packages out of Zest Layouts

[ptziegler]

Both packages are very clearly intended to be an example, I therefore think it's appropriate to move them to a separate org.eclipse.zest.layouts.examples plugin.

To keep backwards-compatibility, I would then add this new bundle as a dependency to org.eclipse.zest.layouts and set the "reexport" flag. To allow omitting those classes, I would also set the "optional" flag.

So even if other bundles have added this dependency via "Required Plug-ins", those classes should remain available in the classpath. When using the "Import-Packages" section, it should work either way.

[azoitl]

I find that a very good idea. Especially as the ZEST code is currently our biggest source of warnings. Having it more separate and clear plugin structures can help us in cleaning.

[ptziegler]

To keep backwards-compatibility, I would then add this new bundle as a dependency to org.eclipse.zest.layouts and set the "reexport" flag. To allow omitting those classes, I would also set the "optional" flag.

That sadly doesn't work... The example classes reference (among other things) the layout classes, meaning there is a dependency from org.eclipse.zest.layouts to org.eclipse.zest.layouts.examples. Meaning I can't add a back-reference without creating a cycle.

[ptziegler]

I slept over it and overall, I'd still like to do the reintegration of the Zest 2.x respository into GEF-Classic. Given that this requires an increment of the major version, it would then also be the idea opportunity to clean up things like this.

[azoitl]

I personally would be very open to this approach. Especially as the Zest parts are currently our biggest quality issue. However I'm currently not directly using Zest so I may be not the best sparing partner for this discussion.
Do you have an idea how much this would impact existing Zest 1.x users?

[ptziegler]

Do you have an idea how much this would impact existing Zest 1.x users?

The biggest change has been done to the layout API, but I think this section describes it pretty well

[merks]

FYI, I'm using Zest here:

https://github.com/eclipse-cbi/p2repo-aggregator/blob/1d205ab82d60c21c9c0a0186b5a6799901f833b0/plugins/org.eclipse.cbi.p2repo.aggregator.analyzer.editor/src/org/eclipse/cbi/p2repo/aggregator/analyzer/presentation/AnalyzerEditor.java#L252-L265

I can export diagrams like this:

https://raw.githubusercontent.com/merks/test/master/report.svg

[ptziegler]

Hm... I don't have a clear overview over all changes yet, but I wonder if there is a way to ensure a limited backwards compatibility...

For example by keeping the "old" LayoutEntity and the "new" NodeLayout where LayoutEntity extends NodeLayout. The old classes would be marked as "deprecated" and "for removal". This way downstream projects at least have a chance to test their existing implementation against Zest 2.0, before they eventually have to migrate their code.

[azoitl]

Also we had improvements to Zest 1 that would be sad to loose. E.g. the work done by @sebHollersbacher.

[ptziegler]

Also we had improvements to Zest 1 that would be sad to loose.

We wouldn't. And that is the extremely painful part. Both Zest 2.0 and our Zest 1.0 have evolved separately. It can hardly be called a migration if we simply scrap everything that has been contributed since the fork.

Even concepts like the ProgressListener are technically not in Zest 2.0 and it would be a waste to loose such functionality.

[azoitl]

So we clean-up the current Zest 1.x version and try to get the good stuff from Zest 2.x back to our repo, like you started it with Cloudio?

[ptziegler]

Effectively, yes. I spent the past few days on a small PoC. I think it's easier to see once I draft a new PR.

[ptziegler]

Superceded by #416