Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

GEF/GEF4

< GEF
Revision as of 10:50, 21 October 2011 by Alexander.nyssen.itemis.de (Talk | contribs) (Motivation)

Motivation

As agreed on in Bugzilla 347636, GEF 4.0 API will be started in parallel to the current GEF 3.x development branch under the following terms:

  1. After the Indigo release has been completed, a GEF experimental branch is

created by forking the GEF 3.7 code-base into a Git repository (possibly located next to Zest 2.0, so that all experimental GEF components can be found in one place).

  1. The experimental branch created thereby will live parallel to the GEF HEAD

branch, considering all its API as provisional unless explicitly graduated. It will not interfere with GEF HEAD, i.e. it will have its own build process and separate wiki pages for documentation of the ongoing work (similar to Zest 2.0).

  1. Committers working on the experimental branch will be responsible for

ensuring fixes made to GEF HEAD also get applied to the experimental branch.

  1. Graduation of the experimental branch back into GEF HEAD will have to imply

that a proper compatibility layer is in place so all GEF 3.x clients run in a 100% binary compatible method. It will furthermore have to be acknowledged by all GEF committers.

  1. Work will start without an incubator project at first, granting commit

rights on the Git repository to all current GEF committers. The question of introducing an incubator project (located under GEF) will be deferred until a) community wants to actively get involved or b) Juno has been released (whatever comes first).

As migration of GEF to git has not been completed yet (see Bugzilla 351232 for details), development has been started by creating a new Geometry API, based on the current Draw2d geometry classes (see Bugzilla 355997 for details). Due to the lessons learned in developing an initial GEF 4 Geometry API, and due to the compatibility requirements imposed on a gradation of the new GEF4 API, it was concluded that migrating the existing code base on a module-per-module basis is more appropriate than branching the whole code base. The completion of the GEF4 Geometry API will be the first package that is to be completed with respect to this. Based on the Geometry API, other packages may then be investigated, as outlined in the Roadmap below.

Components / Roadmap

  • GEF4 Geometry - Q4 2011
  • Draw2d Core (Graphics, Canvas, Figure, Bounds, etc.)

Back to the top