Kenn Hussey a écrit :
Raphael,
Thanks for contributing to the discussion, and providing such
insightful context. I agree that the characterization of Papyrus in the
Sphinx proposal can (and should) be improved to more accurately reflect
the project's intent and its (future) relationship to Sphinx. I was
hoping that would happen before the proposal was posted, but it's not
too late to do so now.
OK, we (Atos, CEA and Airbus) will provide suggestions of improvment on
monday.
I see both Papyrus and Sphinx working towards a similar goal,
i.e., to gather the various modeling technologies at Eclipse into a
cohesive, consumable whole. But each is taking a different approach, in
my mind - Papyrus is from a top-down perspective (i.e., end-user
consumable tool) whereas Sphinx is from a bottom-up perspective (i.e.,
common building blocks).
In fact Papyrus has both aspects (end user tool and building blocks)
and could be easily (should probably be) divided into two distinct
parts:
- the UML/SysML/Marte tool = industrial-quality tool, ready to use
and extendable to any UML profile and any DSL editor
- the papyrus backbone = modeling editor support building blocks
(services) providing model explorer, multi-diagram and multi-editor
support, preferences, filters, property view customization, sub model
management, model resource abstraction, version control
connection,...as it exists in TOPCASED.
I share the same vision about Sphinx: it does not address the top layer
(the tool) but brings features to the bottom one (the backbone) and
this is the place where we can have connections.
At the outset (as became apparent at the Summit), there is,
naturally, some overlap between the two; indeed, I think it remains to
be seen where exactly the dividing line will eventually end up, i.e.,
where Sphinx ends and Papyrus begins within a tooling stack.
See my previous point on that line. Very clear for me.
Ultimately, however, I still see Papyrus as an (the) fully
integrated modeling environment (e.g., the "JDT" of modeling, if you
will) whereas I see Sphinx as a possible (future) foundation on which
to base it (e.g., the "workbench" of modeling).
I agree with this vision and I like this analogy: Eclipse 1.0 was only
seen as a Java environement where the platform and JDT were not really
separated. Then came Eclipse 2 and 3 with cleaner architecture to let
java become an independant layer plugged on the platform as would be
CDT or other programming environements. As was it for MDT papyrus at
the beginning : a UML editor and backbone facilities logically
separated but physically linked. Now we have reached this first
separation of concerns with a backbone agnostic of UML and we really
consider it as the "workbench" of modeling.
What about Sphinx? Sphinx brings other strong experience about large
EMF models and this experience is rich and should clearly benefit to
the whole modeling community.
To my opinion, Sphinx makes sense if it can extend horizontally papyrus
backbone to provide new and optimized services on which model editors
can plug and work efficiently.
What about overlap?
Overlap can be managed quite easily if take the time to focus first on
the use cases of such a "workbench" of modeling and Sphinx proposal
starts the job in the SCOPE part. But it is not enough detailed to my
opinion. I would expect that we list the common classical expected
services like "plug a new modeling editor", search/compare/merge
models, split
model data/diagrams into resources, link models, filter models, ..)
On "initial components" we find solutions to manage some problematics
probably important but that are not really described here. So it gives
the feeling that Sphinx focuses too quickly on solutions built in
Autosar and on technologies available in Eclipse (Mylyn, BIRT, XText
...) and forgets to look at other possible implementations. To my
opinion, it would be a more open approach to consider the services to
offer and give then a mapping with possible implementations. This is
the place where Papyrus could bring some benefit, by providing part of
the mapping with existing implementations already developed and
directely usable. And we would see in a detailed way the overlap of
experienced solutions; The community could then express their
preferences on one implementation or there could coexist several
implementations behing a good abstraction = API (as it can exist in
several Eclipse components).
My two cents to make this backbone really exist through collaboration
rather than domination or substitution.
cheers
raphaël
As co-leads of this proposed new project, I trust that Sebastien
and Stephan can work together to come up with wording that is
acceptable to all parties involved. Of course, I am willing to help in
any way that I can. Personally, I'm less worried about the words (since
talk is cheap) and more about taking the necessary steps to ensure that
these efforts are suitably aligned, to the benefit the modeling
community at large.
Cheers,
Kenn
On Fri, Feb 5, 2010 at 1:39 PM, Raphael
FAUDOU <raphael.faudou@xxxxxxxxxxxxxx>
wrote:
Hi Kenn,
thanks for this clarification.
As discussions are now open, I would like to start some thread about
the vision of MDT Papyrus in this last version of the Sphinx proposal.
On the last open discussion about the position of MDT papyrus in the
modeling landscape (Eclipse Summit Europe), we (Papyrus team) had
presented our vision of MDT Papyrus as "the advent of an open source
IME at Eclipse". A the BOF session, there was some general agreement
that MDT Papyrus backbone could be considered as one of the pillars of
this IME and Christian Meier from UBS had drawn the "full picture" in
which we could see MDT Papyrus as the "modeling editor" component of
this platform. We have explained that the backbone is independant of
UML and is already able to support any modeling editor including
profile-based and DSL-based editors (see slide 15 of the ESE 2009
presentation - "advent of an open source IME at Eclipse" - if some of
you do not remember or were not present)
So, what happened in 4 months behind the scene?
How did this presentation of MDT Papyrus backbone as an open platform
to support any modeling editor could evolve to the following
description: " Papyrus
backbone which provides basic facilities required for UML2 editors (see
Code contributions for detail)" ?
Kenn, do you really agree with this description? do you really think
that MDT Papyrus backbone is limited to basic facilities for (only)
UML2 editors?
It is probably considered as a simple bad rephrasing but it changes a
lot the position of MDT papyrus and could provide confusion within the
modeling community.
On next sentence I read "The rest of the Papyrus project is intended to
be migrated to Sphinx and thereby become a consumer of it".
Personnaly I never heard about that and never stated such an intention
and I know that is not the position of CEA too. So it looks like some
kind of "shortcut" or "interpretation" of private talks. Perhaps it can
make sense that Papyrus integrates to Sphinx later but we are very far
from taking such a decision because we first have to understand clearly
the Sphinx architecture and the complements with MDT Papyrus, which is
not the case for now.
So could you please update the proposal to rephrase Papyrus description
and make it more conformant to the last presentation in Stuttgart?
Thanks a lot.
After those modifications I and other papyrus members will be happy to
start some more interesting discussions about overlap, alignement and
complements in architecture and technologies between Sphinx and MDT
papyrus.
Cheers
Raphaël
Kenn Hussey a écrit :
Guys,
Ultimately, a project proposal is not considered final until
the
project creation review, and as Stephan has pointed out, it's quite
natural (and expected!) for it to change once posted. I suspect the
Foundation was "too fast" in publishing the proposal because it is in
all of our better interests for discussions to start taking place in
the open instead of "behind closed doors" - that is the Eclipse Way.
The result of public participation in the shaping of this proposal can
only mean better things for the project and for all our individual
interests in participating in it...
Cheers,
Kenn
On Fri, Feb 5, 2010 at 10:18 AM, Stephan
Eberle <stephan.eberle@xxxxxxxxxxx>
wrote:
Sébastien,
Comments below:
Le 05/02/2010 15:01, GERARD Sebastien 166342 a écrit :
Hi Stephan,
The version
of the sphinx proposal that was uploaded
on the Eclipse web site as a project proposal (http://www.eclipse.org/proposals/sphinx/)
is
not in line with the content of the last proposal I sent you last
Wednesday.
I cc this document to this email as a reminder.
I think that "not in line" is not justified. The published version is
slightly different, yes, but as stated in my e-mail which I sent to you
upon completion of step 1 (see attachment), these differences consist
of correction of spell errors and some rephrasings but don't change the
content of the version we have commonly agreed upon in any significant
way.
According to
what we said last Wednesday, the process
for finalizing the proposal was:
1 – you
should have sent me two versions of
this proposal integrating my comments and the one of Cedric: 1 short
version
that was intended to be the official proposal, and a longest (the one
cc this email
and possibly modified by you).
Which I've done by 2010-02-04 morning CET, see attachment.
2 – then I
sho this shuld have
reviewedortest
version and then say if I am ok or if I need some final modifications.
Which I was waiting for since completion of step 1.
But you have
skipped this second stage and then you
did not give me any time to agree on the final version post on the
Eclipse web
site and you did not give the time to consult the Papyrus team to have
their final
agreement also!
No, by all honesty, I have never given green light for the publication
of the proposal.
What I've done is that I've asked Wayne at Eclipse Foundation to make
the latest version of the proposal available under a hidden link at
Eclipse.org (see attachment). It is quite normal to do that and even
stated like this in the Eclipse Development Process
( http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase).
Then Wayne asked to you and me if anyone has still any change requests
(see attachment). Me, still waiting for your reaction in response to
completion of step 1 hadn't any, and you have also not replied to Wayne.
Personally, I didn't worry much about, because I was expecting that
Wayne would wait for an explicit go from both of us before moving
forward. What happened instead is that Eclipse Foundation has turned
the proposal public without waiting for anymore feedback.
That's what happened, and I was as surprised as you when I saw that
this morning. I therefore have to say that it was Eclipse Foundation
who has been a little bit too fast here.
And again, I definitely didn't meant it to take this way.
For that
reason, I ask you to ask Eclipse to withdraw
the current version of the proposal from the Eclipse web site and then
to send
me the version of the doc used for the publication. It will give a
chance to me
and the Papyrus team to provide our comments and agreement.
Given that the differences between the version we have agreed upon and
the published one are MINOR with regard to the content, I strongly
believe that it would be to our all's disadvantage if we overreacted by
withdrawing the proposal under the eyes of the whole Eclipse community.
Really, we have been so close to starting off a really good
collaboration, why throwing all this away now because of a few spell
errors and a couple of rephrasings?
So, what I suggest is that we simply complete step 2 and then send an
updated
version of the proposal to Eclipse Foundation in case that this should
be necessary. Then this update would silently replace the current
version and that's it.
This is btw. absolutely not unusual, because an Eclipse project
proposal is not necessarily meant to stay unchanged but can be altered
during the whole proposal phase (see http://www.eclipse.org/projects/dev_process/development_process.php#6_2_2_Proposal
for details).
Thanks,
Stephan
Thanks,
Best…
Sébastien.
Dr. Sébastien Gérard
Head of MDD for DRES research project
CEA
LIST, Laboratoire d’Ingénierie dirigée par les
modèles pour les Systèmes Embarqués (LISE)
Boîte
courrier 94, GIF SUR YVETTE
CEDEX,
F-91191 France
Phone/fax : +33 1 69 08 58 24 / 83 95
Leader of the Eclipse Component Papyrus (The UML2
Graphical Modeler): www.papyrusuml.org
http://www.eclipse.org/modeling/mdt/?project=papyrus
Before printing, think about the environment
--
Dr.
Stephan EBERLE
----------------------------------------------------------------
Product
Development Manager
16-18 rue du Dôme
92100 Boulogne-Billancourt, FRANCE
Phone : +33 (0)1.73.54.00.30
Fax : +33 (0)1.73.54.00.32
Mobile : +33 (0)6.64.18.39.10
E-mail : stephan.eberle@xxxxxxxxxxx
www : http://www.geensys.com
----------------------------------------------------------------
_______________________________________________
mdt-papyrus.dev mailing list
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
--
 |
Raphaël FAUDOU
Responsable cellule
Innovation / bureau méthodes
Head
of Innovation & Method Definition
Embedded
systems & critical systems
Atos
Origin
Tel : +33 (0)5 34 36 32 89
Tel : +33 (0)6 10 53 50 44
Mail : raphael.faudou@xxxxxxxxxxxxxx
|
Atos Origin
6, Impasse Alice Guy
BP 43045
31024 Toulouse Cedex 3, France
|
P Avant
d'imprimer cet e-mail, pensez à l'environnement. Ce message et les
pièces jointes sont confidentiels et réservés à l'usage exclusif de ses
destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en
avertir immédiatement l'expéditeur et de le détruire. L'intégrité du
message ne pouvant être assurée sur Internet, la responsabilité du
groupe Atos Origin ne pourra être recherchée quant au contenu de ce
message. Bien que les meilleurs efforts soient faits pour maintenir
cette transmission exempte de tout virus, l'expéditeur ne donne aucune
garantie à cet égard et sa responsabilité ne saurait être recherchée
pour tout dommage résultant d'un virus transmis.
P Please
consider your environmental responsibility before printing this e-mail.
This
e-mail
and the
documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its
integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender
does not warrant that this transmission is virus-free and will not be
liable for any damages resulting from any virus transmitted. |
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
--
 |
Raphaël FAUDOU
Responsable cellule
Innovation / bureau méthodes
Head
of Innovation & Method Definition
Embedded
systems & critical systems
Atos
Origin
Tel : +33 (0)5 34 36 32 89
Tel : +33 (0)6 10 53 50 44
Mail : raphael.faudou@xxxxxxxxxxxxxx
|
Atos Origin
6, Impasse Alice Guy
BP 43045
31024 Toulouse Cedex 3, France
|
P Avant
d'imprimer cet e-mail, pensez à l'environnement. Ce message et les
pièces jointes sont confidentiels et réservés à l'usage exclusif de ses
destinataires. Il peut également être protégé par le secret
professionnel. Si vous recevez ce message par erreur, merci d'en
avertir immédiatement l'expéditeur et de le détruire. L'intégrité du
message ne pouvant être assurée sur Internet, la responsabilité du
groupe Atos Origin ne pourra être recherchée quant au contenu de ce
message. Bien que les meilleurs efforts soient faits pour maintenir
cette transmission exempte de tout virus, l'expéditeur ne donne aucune
garantie à cet égard et sa responsabilité ne saurait être recherchée
pour tout dommage résultant d'un virus transmis.
P Please
consider your environmental responsibility before printing this e-mail.
This e-mail
and the
documents attached are confidential and intended solely for the
addressee; it may also be privileged. If you receive this e-mail in
error, please notify the sender immediately and destroy it. As its
integrity cannot be secured on the Internet, the Atos Origin group
liability cannot be triggered for the message content. Although the
sender endeavours to maintain a computer virus-free network, the sender
does not warrant that this transmission is virus-free and will not be
liable for any damages resulting from any virus transmitted. |
|
