|[gef-dev] GEF4 and Zest2 - A unified approach|
those of you who listen to this mailing list regularly already know that I have recently (i.e. after the 3.7 release) initiated a GEF4 provisional component to be able to work on the new API of Draw2d and GEF (MVC). In parallel to my efforts Fabian, Ian, and recently also Stephan and Zoltan, have been working on a Zest 2 provisional component to develop the next generation Zest API already since 2009. However, while both provisional components pretty much have the same scope, namely to come up with a next generation API for the components that make up the GEF project, they are neither integrated with each other, nor is it very transparent to our community what they are aiming at in detail. In addition, the web pages do not even mention these components and the wiki pages are somehow unstructured, so there is no clear message to our community either.
Due to this, Fabian and I have recently discussed how we could combine both efforts and gain more transparency to our community as well as reach a better quality w.r.t to the next generation API itself. Our conclusion was that it would absolutely make sense to comprise both efforts under just one provisional component, and to promote this as the unified approach to modernize our project.
Up to now my plans for GEF4 were to continue to work on a new double-precision Geometry API (as a replacement for the Draw2d geometry classes) as an initial nucleus up to the Juno release (I have already started on it with much support by our student worker Matthias Wienand), and to copy and migrate the Draw2d and GEF MVC 3.8 code into the GEF4 repository, which I have already set up, afterwards, so that from then on it could be developed in parallel to GEF 3.x (and - and this is the real pity - also in parallel to Zest 2.0).
Now, Fabian and I came to the conclusion that it would be a good idea to in addition also migrate the current Zest 2.0 code basis into this GEF4 repository after Juno and to start with with a unified approach to develop a next generation API there.
In detail we discussed the following implications:
1) We should use the single org.eclipse.gef4.git repository that has already been set-up and discontinue to use the org.eclipse.zest.git repository. So, after the migration, we would only have the org.eclipse.gef.git repository for GEF 3.x and Zest 1.x and the org.eclipse.gef4.git repository for the provisional component.
2) We should use a single wiki page (wiki.eclipse.org/GEF/GEF4) to serve as the entry point for all efforts regarding the next generation API.
3) We should use a single Tycho/Hudson based build. The Hudson gef4-nightly-tycho job has already been set up and can be used. We also should provide a single integrated update-site.
4) We should use the org.eclipse.gef4 namespace as a general prefix, as well as a unique version number for all our plug-ins (i.e. 0.1 or 0.7 to indicate that the API is provisional). That is, during the initial migration of the 3.8 code base, the current Draw2d and GEF (MVC) plug-ins should be renamed to something like org.eclipse.gef4.draw2d and org.eclipse.gef4.mvc (as a replacement for org.eclipse.gef). The same holds for the Zest 2.0 plug-ins (i.e. org.eclipse.zest.core should become org.eclipse.gef4.zest.core).
We see two major benefits in doing so:
1) After the initial migration has been done, on the long term we would have the chance to diminish the artificial boundaries that are currently there between Draw2d/GEF (MVC) on the one side and Zest on the other. That is, we could re-modularize and re-structure the current codebase to come up with a better integrated solution. We could e.g. create something like org.eclipse.gef4.graphics that combines the Graphics of Draw2d and Zest (up to now we have two implementations). We could e.g. also come up with something like org.eclipse.gef4.layouts to unify the Draw2d Graph API and the Zest Layouts API. A lot more is thinkable
2) We can easily communicate to our community that there is just a single combined effort to modernize our project, namely GEF4. By this, we can probably build up a larger community around the modernization efforts and everything is more transparent in the end.
Fabian and I think that this is the way we should go. All others, and especially all GEF project members, please feed back!
Description: Message signed with OpenPGP using GPGMail