-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move exampleStructures and exampleUses packages out of Zest Layouts #394
Comments
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. |
That sadly doesn't work... The example classes reference (among other things) the layout classes, meaning there is a dependency from |
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. |
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. |
The biggest change has been done to the layout API, but I think this section describes it pretty well |
FYI, I'm using Zest here: I can export diagrams like this: https://raw.githubusercontent.com/merks/test/master/report.svg |
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. |
Also we had improvements to Zest 1 that would be sad to loose. E.g. the work done by @sebHollersbacher. |
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. |
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? |
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. |
Superceded by #416 |
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.
The text was updated successfully, but these errors were encountered: