Best way to handle EMF and xtext-generated UI/edit/editor bundles for january.geometry?

[jayjaybillings]

I wanted to put a specific ticket in to talk about cleaning up this xtext/emf generated code org.eclipse.january.geometry. I'm sure @gerring will respond with "just remove it," especially since I've prodded him! ;-)

N.B. - The VTK bundles are very messed up and need to be reworked. There's some dirty code in there and I'm not sure how it snuck in.

The original goal of creating bundles like org.eclipse.january.geometry.{iges,mtl,obj,vtk} was to extend the geometry data model for 3D geometries to support the IGES, MTL, OBJ and VTK file formats. Each plugin provides extensions to the model, importers and exports, and graphical editors, all of which is managed by EMF magic. All of the "core" data structures for geometry are provided in org.eclipse.january.geometry. All of the org.eclipse.january.geometry.xtext.* bundles provide extensions as described above.

I can see arguing how to deal with this in two ways:

1. January provides utilities to work with its data structures, especially some of the more complicated ones like 3D geometries.
2. January only provides the basic data structures. Utilities to edit, modify, import, or export these data structures are provided by other projects.

I put this ticket up because I want to engage the community in how this is fixed. Any thoughts? Any other ways to deal with this? (A possible third option could be what Jonah suggested in his email about extra repos, for example.)

[jayjaybillings]

@jonahkichwacoders Given your recent experience with xtext in CDT as you mentioned in #58, any thoughts on this?

I'll note too that you mentioned in #58 that January is data and algorithms, which is inline with number 1 above. What do you do with all the UI stuff from xtext in CDT? (If you even use it...)

[jonahgraham]

The Xtext bundles are well split between core/ui. The core plugin + tests (the ones without .ide or .ui) are true core ones (not even requiring OSGi, let along workbench or UI). In CDT, the Linker Script is one self-contained feature with core and ui plug-ins.

At the moment it would seem to me that the ui and ide plug-ins don't really belong in January. It seems that EAVP provides one set of UI to operate on these models, and at the moment they are derived from the auto-generated Xtext ones.

A related question, that would help me understand better is: what does o.e.j.geometry.* aim to provide? Reading and serialization of models? Processing of them? Algorithms on them? etc. With o.e.j.form + dataset it is much more obvious.

[jayjaybillings]

1. o.e.j.geometry provides data structures for managing 3D geometries. If you think about dataset, it provides an efficient way to store nD data. However, the most efficient way to store 3D geometries is in graphs with some small arrays at each node. o.e.j.geometry provides that and is the primary way that o.e.j.form stores its geometric data.
2. o.e.j.geometry can be stored in xsi since it is based on an EMF model. o.e.j.g.{m.edit,m.editor} are bundles generated by EMF to support editing geometries persisted in that way.
3. o.e.j.g.ide and o.e.j.g.xtext.{obj,vtk,iges,mtl} provide support to read various geometry formats into an o.e.j.geometry. All of these are based on xtext and o.e.j.g.ide is STL support and is mislabeled. (I updated #57 to reflect that.)
4. o.e.j.g.{xtext..ui,xtext..ide} are xtext generated bundles with IDE and UI editor utilities for these files. In scientific computing, there is little use for supporting a geometry format if you also don't provide editors and tooling for it, so we generated these as well.

I think that 1 should stay in January. I think there is a good argument to be made that 3 could stay as well. I think 2 & 4 should go back to EAVP.

Any thoughts?

[PeterC-DLS]

Closing as january-forms was moved to https://github.com/eclipse/january-forms