Bugzilla – Full Text Bug Listing
| Summary: | Create GEF4 provisional component | ||
|---|---|---|---|
| Product: | [Tools] GEF | Reporter: | Alexander Nyßen <nyssen> |
| Component: | Misc | Assignee: | Alexander Nyßen <nyssen> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ahunter.eclipse, irbull, steeg |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 367582 | ||
| Bug Blocks: | |||
|
Description
Alexander Nyßen
As Indigo is about to arrive next week, I think it is save to give this all a start with setting up a GEF4 git repo. Ian (you offered to give me some guidance on this on the mailing list; therefore I took the freedom of adding you to the CC list), what would we have to do to transfer the current code base and possibly its history? From Zest 2.x I infer that we already have a git container in place for GEF. Can we reuse it? As the platform is also migrating to Git (see http://wiki.eclipse.org/Platform-releng/Juno_Git_Migration), wouldn't it be an option to migrate the whole GEF repository (with its CVS history) to Git as well and to start with the GEF 4.0 branch within this repository? Until the migration of GEF from cvs to git is to be completed, I will work on all my contributions to the provisional branch in a newly created module (GEF4) within our cvs repository (up to now I have contributed the initial contribution for a new Geometry API, as stated within bug #355997). This is probably the wrong place to start a GIT/Build discussion, but we can move to GIT anytime, build is the blocker. Last I have on the new builds from Ian was http://dev.eclipse.org/mhonarc/lists/gef-dev/msg01400.html Ian, can you update on gef-dev the status on the new builds? (In reply to comment #4) > This is probably the wrong place to start a GIT/Build discussion, but we can > move to GIT anytime, build is the blocker. > > Last I have on the new builds from Ian was > http://dev.eclipse.org/mhonarc/lists/gef-dev/msg01400.html > > Ian, can you update on gef-dev the status on the new builds? I opened bug #351232 to keep track of the migration issue, so maybe we can discuss such questions there. As I have stated therein, I think it could be possible to migrate our existing build to Git without much effort... (In reply to comment #5) > (In reply to comment #4) > > This is probably the wrong place to start a GIT/Build discussion, but we can > > move to GIT anytime, build is the blocker. > > > > Last I have on the new builds from Ian was > > http://dev.eclipse.org/mhonarc/lists/gef-dev/msg01400.html > > > > Ian, can you update on gef-dev the status on the new builds? > > I opened bug #351232 to keep track of the migration issue, so maybe we can > discuss such questions there. As I have stated therein, I think it could be > possible to migrate our existing build to Git without much effort... Despite from the still open migration issues, based on the lessons learned from starting to develop the new GEF 4 Geometry API (and also because of the compatibility requirements imposed on a gradation, which requires separate namespaces for GEF 3.x and GEF 4.x), it could be better to migrate the existing code base on a module-per-module basis (as now started for the geometry API) than to branch the overall code base in one "big bang". (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > This is probably the wrong place to start a GIT/Build discussion, but we can > > > move to GIT anytime, build is the blocker. > > > > > > Last I have on the new builds from Ian was > > > http://dev.eclipse.org/mhonarc/lists/gef-dev/msg01400.html > > > > > > Ian, can you update on gef-dev the status on the new builds? > > > > I opened bug #351232 to keep track of the migration issue, so maybe we can > > discuss such questions there. As I have stated therein, I think it could be > > possible to migrate our existing build to Git without much effort... > > Despite from the still open migration issues, based on the lessons learned > from starting to develop the new GEF 4 Geometry API (and also because of the > compatibility requirements imposed on a gradation, which requires separate > namespaces for GEF 3.x and GEF 4.x), it could be better to migrate the existing > code base on a module-per-module basis (as now started for the geometry API) > than to branch the overall code base in one "big bang". I have now defined a feature structure as well as a Tycho-based build infrastructure to which the newly developed modules may be subsequently added (up to now, only the geometry module is included). A Hudson build job has been requested in bug #363078 to make things better consumable. After the latest patch to the new GEF4 Geometry API has been approved and applied (CQ 5876) in terms of bug #355997, I think it would be reasonable to migrate the GEF4 component to its own Git module to prepare the migration of the GEF cvs repository afterwards (see bug #351232). To keep track of the Git-module creation for GEF4, I have opened bug #367582. I created a new Git repository under git://git.eclipse.org/gitroot/gef/org.eclipse.gef4.git and pushed the current GEF4 contents up. Further, I changed the Tycho/Hudson build (gef4-tycho-nightly) to build against this repository, update the GEF4 wiki page (http://wiki.eclipse.org/GEF/GEF4) and moved the GEF4 cvs module into the cvs archive folder. As the GEF4 git repository is now in place, I think we may resolve this one as being fixed, even while the Draw2d and GEF code bases have not been transferred into this repository yet. Up to now, work will concentrate on the new Geometry API. Having released GEF 3.8, the appropriate parts of the Draw2d and GEF (MVC) API may then be ported to the new Geometry API and into the GEF4 Git repository. This however is up to the project plan of the provisional component and does not have to be tracked here. The creation process may pretty much be regarded as being done, not least, because an own Tycho/Hudson based build infrastructure and Wiki pages have been put in place (so the infrastructure is completely there). Added dependency to bug #372365, which addresses the unification of the GEF4 and Zest2 provisional components after the Juno release. Also reopened this bug to indicate that the creation of the GEF4 provisional component should not be regarded as being finished before the Zest2 code base has finally joined in. Added dependency to bug #386029 (creation of a new GEF4 Graphics-API, which is the next logical step after the Geometry API has been finalized. Removed dependency on GEF4 Graphics component again. We should regard the creation of the provisional component as being finalized, now that the Zest2 code base has joined in. |