Difference between revisions of "Talk:MDT/Papyrus-Proposal"

Revision as of 10:58, 22 April 2008

• Precise the content of the initial contribution
• Refine the component architecture
• Choose an organization and a leader: a kind of PMC + one leader ? Due to the relative investment of the developers (to be detailed ?), I suggest to choose Sébastien to lead the component, with the other candidates in this committee.
• Detail the planning
• Change "project" into "component"

• [Kenn] : I’ll take a closer look at the proposal soon, but in the meantime note that we need to more consistently use “component” instead of “project”, and that we should identify one lead for this component (instead of two or three).

• [raphaël] : in fact we need 5 components and two levels.

Papyrus is the UML tool and the final deliverable for UML end users (higl level component with a dedicated roadmap) Papyrus is composed of several lower-level components (each of them having a roadmap):

 a) backbone (the diagram container) with an API to integrate diagrams into, 
 b) MTD diagram adaptor : a layer on top of MDT diagrams to make them conform to the backbone API
 c) other UML diagrams outside of MDT : contributions of other diagrams that will be developed directly in Papyrus Eclipse component
 d) facilities (EMFCompare, outline, properties...) : all things to integrate to have full-featured tool
 e) XMIDI reference implementation, with import and export commands.

• [Kenn] These seem more like features than components. There should be one roadmap into which the plans for each of these features will fit...

• [raphaël] in that case those would be really huge features ;-) the backbone, for instance, will provide multi-editor layout, multi-diagrams model, collaborative work support...

The idea of presenting those "large features" as components is based on two ideas : parallel work and modularity. By creating them as components we ensure that there be one leader and one roadmap for each, in addition to an integration planning to reach the global tool level. With such a structure, it gives immediately the rules of efficient parallel work (different teams can work on different components at the same time when interfaces are clearly defined) and promotes modularity through potential reuse of each group of features.

• [Kenn] OK, that makes sense, then. There are no restrictions on how the functionality/code within a project/component is organized - we should impose whatever structure makes sense. Currently, only projects and sub-projects are officially recognized at Eclipse (components are "second class" entities), but if/when the proposed changes to the development process are approved (see http://www.eclipse.org/projects/dev_process/development_process.php#), nesting of projects (each with its own leadership and associated list of committers) can take place at any level...

• [raphaël] commitee and initial committers

The idea of a Project Management Committee was a way to give special representation to the parties the most involved in development and in specification of the tool through initial and future contributions. As PMC is reserved for high level project it can not be used in our case and we have to rely on the committer vote to provide representation. It seems we have two options :

 a) minimalist list of initial committers : each party investing at least 2 FTE could have one initial committer. Parties with at least 3 FTE would have two committers (CEA for instance). This option strongly limits the number of initial committers (probably 4 or 5) and so gives a better start for the project (easier to ensure coherency and good-quality commits if there are a few committers). After some months, other committers could be promoted through the Eclipse well-known meritocracy process.
 b) Open list of intitial committers : each party could have one initial commiter for each FTE provided (with a limitation of 3 initial committers by party).  According to the first estimation of efforts provided by the different interested parties, this second option would lead to 6 to 9 committers. 

My preference is for option a)...

• [Javier] In the MOSKitt project we have been analyzing the proposal and several issues have raised.
  • From the proposal, one project goal is "Support industrial needs like version management & team work". Which kind of functionality is expected to provide? Supporting models/diagrams merging and/or differences visualizations? We suppose that core team working functionality should be provided by any other kind of tool, like a models or projects repository.
  • In the proposal different degrees of GMF use are specified ("Rely on GMF runtime for common look & feel", "Based on GMF generation as far as possible", "... around valuable UML & SysML diagram editors (GMF based or not)). If we aim to provide a usable UML2/SysML tool we think that we should clearly define a common base technology in order to supply an homogeneous experience. Flexibility and facility to be extended are really desirable and main goals, but we should clearly define the common/minimal technology for the editors (¿GMF?, ¿GEF?, ¿Anything?). From out point of view, GMF should be the common technology.
  • We also think that a hierarchical view for editing the model is really required but, from our point of view, it is not required to be integrated in the outline view but in an specific view. In MOSKitt we have developed a little framework for building such a kind of view (to be released in the next 0.5.0 version). It is based on the Eclipse Common Navigation Framework and provide some functionality that can be used for any modeling tool (not only uml2). Using this framework it is extremely easy supporting new models using extension points (in our case, we are also using it for our database, workbreakdown structure and dashboard editors) and all of them share some common functionality (like synchronization with the graphical editor, showing the elements that are present in the current diagram, hiding the diagrams, etc.).

• • What do you think about creating a "Style Guide" for the figures in the editors. It could provide homogeneity. It even could be implemented in a shared .graph model.
  • We do not have very clear the component structure that has been proposed. Maybe a more detailed description of every component describing their goals would be desirable.
    • org.eclipse.papyrus.scribe.core and org.eclipse.papyrus.scribe.diagrams contains "hand-coded" diagrams. What do you mean by hand-coded? GEF-based?
    • org.eclipse.papyrus.uml2tools. Which kind of utilities do you expect to provide in this component/feature?
    • which does "diagram declaration" mean? The .graph, .gmfmap, .gmfgen models?
    • why uml2tools.diagrams and gmf.diagrams? Which non UML2 diagrams are expected or supposed to be supported?
  • Based in our current experience developing our GMF-based multidiagram UML2 editor, we have been studying a component organization which we include here aiming to help in defining the definitive organization:
    • org.eclipse.papyrus.core
      • Multidiagram support
        • Supporting infraestructure (commands and registry for mapping editor and model element)
        • Actions for creating subdiagrams and browsing the diagrams structure
      • Creation and initialization wizards
      • Performance improvements (editparts and resources caching)
      • Copy&Paste support
      • Drag&Drop support (EditPolicy + generation templates)
      • Extension point for the definition of new diagram editos
      • Actions for managing profile application
    • org.eclipse.papyrus.common
      • Shared .graph
      • Shared Java2D figures
      • Icons + IconRegistry
      • Shared generation templates
      • Parsers
    • org.eclipse.papyrus.ADIAGRAM.def
      • .tool, .graph, .gmfmap, .gmfgen
    • org.eclipse.papyrus.ADIAGRAM
      • Generated code and hand-made modifications
      • Extension to declare a new diagram
    • org.eclipse.papyrus.tabbedproperties
      • Sections (based on org.eclipse.emf.tabbedproperties)
      • Filters
      • Extensions to declare the tabs and sections
    • org.eclipse.papyrus.navigator
      • Eclipse view that extends the Common Navigation Framework (CNF)
        • Selection synchronization with the open diagram
      • Abstract Content Providers
        • Adapter factory to show any Ecore based model
        • Adapter factory to show the diagrams of a model
      • Abstract Action Providers
      • Copy&Paste, cut, delete actions
      • Action to open a diagram on double-click
    • org.eclipse.papyrus.navigator.uml2
      • UML2 Content provider (based on the UML2-MDT Adapter factory)
      • Actions for adding new elements (new child, new siblings)
  • Please, note that this so verbose commentaries just aim to help to clarify the proposal. We really appreciate all the excellent work that has been carried out to achieve this point. :)