Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: for the plan.

Jump to: navigation, search


  • 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, nesting of projects (each with its own leadership and associated list of committers) can take place at any level...
  • [Etienne] Eclipse Papyrus definitly needs to be a project, and not only a component. We plan to promote Papyrus as a new major feature of Eclipse ecosystem, and a component status isn't appropriated. If we use future Eclipse terms, it will be a Container Projects with several Operating Projects.

I think Papyrus must be directly under Eclipse Modeling TopLevel Project, and not under MDT. MDT is for standard metamodels, not for every tooling (like BPMN2 Ecore inside MDT, and BPMN tooling inside STP). So, I propose to rename this proposal from "MDT-Papyrus" to "Papyrus".

  • [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)...

  • [Etienne] My preference is for option b), because the problem isn't from which party does every commiter come from, but who will really works. So, I agree with Javier to have for each component of Papyrus a more precise description and a list of active commiters. After 6 to 12 months, we will clean commiters list by cleaning inactive commiters.
  • [Javier] I think that, first of all, we need to clearly define what is a party; I mean that this project is mainly promoted for projects where several organizations participate. The FTE counting is for every "project" or for every "organization"? For instance, MOSKitt aims to invest 2 FTE, but each of them from a different company. In case of selecting the a) approach, would we have one initial committer or none of them? I understand that suitable balancing the representation is really important but, from my point of view, most project decisions (or key ones) should be approved unanimously. Therefore, in order to facilitate the daily work, option b) could be better and, as Etienne marked, cleaning the list in short term.
  • [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.

[Etienne] Generic tools like EMF Compare needs to be specialized for UML models, with a specific engine and some specific UI.

    • 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.

[Etienne] It's easy: Papyrus will allow to use GEF modelers, GMF generated modelers, GMF not generated modelers, non-graphical modelers in a common way. So, you can add external tools (commercial or opensource) just by adding a backbone connector. It will provide an extensible way for UML modeling. BUT, inside Papyrus project, there will be Papyrus diagrams which will be created by a merge of existing tools (MDT UML2Tools, Papyrus v1, TopCased, ...). And they will rely on GMF Runtime (what you describe as minimal technology). Every time we can, we will use GMF Tool, but we will not limited to GMF Tool capability. [Javier] We are really excited to see this multi-technology support on top of GMF. Sorry for my ignorance but, is it currently working in the initial proposed code contribution?

    • 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.).

[Etienne] Fine. But why not call it Outline? [Javier] Eclipse outlines provide non-editable views of some data (am I wrong?) and we aim to add editing capabilities.

    • 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. :)

Papyrus Proposed Architecture

[Cedric] I will try to clarify the actual proposed architecture.

  • First of all, the idea is to have "plug and play" diagrams: to add a diagram, you add its plugin, and, thanks to the eclipse extension mechanism, the diagram should be accessible in Papyrus Editor.
  • Papyrus Editor should support GEF diagrams, GMF generated diagrams, actual UML2 Tool diagrams (MDT), EMF trees or any home made diagrams. It is not dedicated to GMF, nor a GMF demonstrator.
  • The Papyrus Backbone provide the infrastructure to support multidiagrams accepting any kind of diagrams. The backbone should be independant from any diagrams technologies.
  • Various diagram types can be organized by their technologies: GEF, GMF, UML2Tool... For each technology, we could provide the basic support for this technology. This is done actually in (org.eclipse.papyrus.scribe.core, org.eclipse.papyrus.uml2tools, org.eclipse.papyrus.gmf)

[Javier] From our point of view, one issue that still have to be clarified in the discussion and in the proposal are the goals of the project (or how these goals are planned to be achieved). I understand that the final goal is to supply industrially usable UML2 and SysML graphical editors. Then, in order to achieve this goal, a "glue" technology is going to be developed for supporting the integration of GMF, GEF, EMF, etc. editors. But, what about end-user editors? It is ok providing a technology independent backbone but we also must be concerned about the end-user editors. Although the backbone supports any technology, which is the selected technology for developing the UML2 and SysML editors? Will the papyrus technology host different implementations of the same kind of diagram using different technologies? Or am I wrong and no specific editor will be provided and just the backbone is the project expected result?

  • So, all GMF based diagrams can be added independantly, and they can also share common infrastructure as proposed by Javier.

Following is a more detailed list of initial code contribution. Note that this code already exist and is working.

org.eclipse.papyrus.backboneThe integrator backbone
org.eclipse.papyrus.multidiagramProvide multidiagram base editor for GEF and GMF, independent from UML
org.eclipse.papyrus.scribe.core Hand coded diagrams core - Provide Papyrus V1 diagrams core infrastructure. Based on GEF
org.eclipse.papyrus.scribe.diagrams Hand coded diagrams - These are the Papyrus v1 diagram plugins
org.eclipse.papyrus.uml2tools Utilities to integrate UML2 Tools diagrams - Provide core infrastructure for the UML 2 Tools project editor (MDT)
org.eclipse.papyrus.uml2tools.diagrams UML2 Tools diagrams declarations - The plugins declaring the UML2 Tool diagrams
org.eclipse.papyrus.gmf Utilities to integrate other GMF diagrams - Provide core infrastructure for GMF generated diagrams
org.eclipse.papyrus.gmf.diagrams Other GMF diagrams declarations - The GMF diagrams plugins.

[Javier] I still do not have clear which functionality or infrastructure is provided in the technology independent backbone. Maybe a look at the current Papyrus v1 code will help to clarify me?

  • We also promote that the hierarchical view of the model (that we actually call outline :-( )is an independant diagram/view, as well as the property view. Like that, it should be possible to add/remove easily such view.
  • Note that a particular diagram (for example activity) can come in different implementations. Today, we already have a Papyrus implementation and a uml2tool implementation. They aren't interchangeable (because of the graphical data): you can't edit a diagram made in Papyrus with uml2tool or vice-versa. So, proposed hierarchy can't be org.eclipse.papyrus.ADIAGRAM
  • It could be interesting to check if Javier proposed hierarchical view is compatible with the proposed backbone.
  • The multidiagram support is independent from the backbone. This will ease its maintenance and reuse.
  • [Kenn] The "hierarchical view" of the model needs to be the Project Explorer, IMHO; Eclipse already provides this view, so why introduce (yet) another one?
    • [Cedric] Maybe be we need to define what we want under the words "hierarchical view", or "outline view" ... of the model. My definition is "a hierarchical tree view on the UML model, plus the diagram nodes, and excluding graphical data. The diagram nodes can be under UML packages or concepts". An example is the actual outline view of Papyrus V1, or the Rational Rose explorer. I don't think that such componant can be the Project Explorer.
    • [DCarlson] I agree with Kenn that the Project Explorer (aka the Common Navigator) should be used. It can support all the functionality that you list. The Common Navigator framework was introduced specifically to avoid the proliferation of alternative navigator views by products installed in a shared IDE. It supports a pluggable framework for content, filtering, actions, and more. As an example, the model navigator in Rational Software Modeler is implemented in the Project Explorer.
    • [Cedric] Maybe we should separate the "what" and the "where". What do we want in a "Model Explorer" and where do we want it.
      • What do we want - an explorer on the business model (UML), with nodes representing diagrams. Diagram nodes can be anywhere in the explorer (under a nested packages, under classes ...). Clicking on a diagram node open it.
      • Where do want it - It appears to be a matter of taste. So, let the end user choose. Our "model explorer" should be able to be opened in an outline as well as in the Project Explorer (as it is for Java classes explorer).
    • [Raphaël] To my opininion, there are two levels to consider : the project and the model.
      • The project can contain several models (main model and submodels, profiles used, model libraries imported...). The project explorer seems the right way to explore this. Perhaps we can see packages hierarchy too.
      • the model (or submodel) : I think we need another view to see the model hierarchy in terms of packages and in terms of diagrams and model elements. This is a more detailed view and the outline view could make sense for a given model (or else) but not the "project explorer".
    • [Kenn] The purpose of the 'Project Explorer' is not only to explore projects (and project-level artifacts), but also their contents. Everything in Eclipse starts with (and is hosted in) a project; the structure of the nodes that are displayed underneath a project in the Project Explorer need not match the physical structure (that's what the Navigator view is for), and can be as detailed (deep) as the content provider chooses...
    • [Javier] From my point of view, first we should differentiate the Common Navigator Framework (CNF) and the Project Explorer. While the first one is a "framework" for building navigators (as its name indicates ;) ), the second one is an specific view which is based on the CNF. IMHO, one view has sense if it faces a task that is not faced in other view. As its name indicates, the goal of the Project Explorer seems to be to explore projects (its contained resources and the resource contents), but not working with its resource contents (editing, refactoring, navigating to linked resources, etc.). Therefore, it could seem that a view focused on working with model/diagrams could have sense. Of course, this new view should be based on the CNF.
    • [Kenn] Well, perhaps there is room for both - note that the structured content of Java source files appears in the Project Explorer just like it does in the Package Explorer...
  • [Kenn] So, if we're going to be following the proposed new development process, we'll need to identify the sub-projects of Papyrus and their associated initial committers.

Back to the top