I completely agree with Ian on this one
too. Those who are actively working on the project should be the ones to
make the decisions. We do not have any dependencies on Zest so no strong
opinion on the matter.
Ian Bull <irbull@xxxxxxxxxxxxxxxxx>
GEF development <gef-dev@xxxxxxxxxxx>
2012/02/22 06:37 PM
GEF4 and Zest2 - A unified approach
Sorry, I meant to respond and like most mails they starting
falling down the in-box list. But that's no excuse!
You guys are doing a great job and I give a big +1 to
this leadership (and to this idea). Fortunately my responsibilities
on the p2 project have increased, which unfortunately means I have less
time for Zest/GEF. Having said that, I'm extremely excited about
the work you (Alexander) and Fabian are doing.
I'm not sure who is actively working on GEF right now,
but it's my opinion that those who are actively working on the project
should be the ones to make the decisions.
I would check with Anthony first, but assuming he doesn't
see any problems, I would start to push forward on this effort.
Well, I'm not a GEF committer, but a big +1 from the peanut
On Feb 22, 2012, at 3:22 PM, Alexander Nyßen wrote:
According to the meta-data our project currently
has 10 committers. Do only three of them have an opinion on this?
Am 19.02.2012 um 17:57 schrieb Ujhelyi Zoltán:
+1 from me as well. I believe, a coordinated effort looks much better,
and can be sold together.
I really like the diminishment of artificial boundaries between GEF and
Zest. Especially, if it would be easy to add Zest layouting to GEF-based
editors (it is possible even now, but needs some manual restructuring.
Fault Tolerant Systems Research Group
Department of Measurement and Information Systems
Budapest University of Technology and Economics
On 2012.02.19., at 17:45, Fabian Steeg wrote:
From the Zest perspective I think this totally makes sense:
there's the current GEF 3.x with Zest 1.x and the future GEF 4.x with Zest
2.x. For users it's a clear message: there's a new version of the entire
GEF project, which is evolved in parallel to the current version.
And for us, having a unified code repository, documentation,
build, and release process for the new version (as we always had for the
3.x/1.x code base) should make the further development of a coherent project
On 19.02.2012, at 16:56, Alexander Nyssen wrote:
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
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!
Dr. Alexander Nyßen