Ok sorry, I missed the specification
document you refer, just found a vague list of requirement regarding file
management.
I'll check the spec on the wiki as soon as
available.
De : Raphael FAUDOU [mailto:raphael.faudou@xxxxxxxxxxxxxx]
Envoyé : mardi 20 octobre
2009 14:36
À : Papyrus Project list
Cc :
thibault.landre@xxxxxxxxxxxxxx; TANGUY Yann 176637; Kenn Hussey; SZADEL Thomas
Objet : Re: [mdt-papyrus.dev]
Specification of the single file management
Hi all,
As more and more remarks are done directly by e-mail on some part or another of
the specification, I would like to suggest (recall?) some rules for efficient
collaborative work.
1. for important/large/complex features, take time to define a specification
document (at least a first draft with a list of UC and requirements). The goal
is double:
- focus on needs and not on solutions (or we will
miss the essentials)
- provide a discussion basis (the document) on
which all project members can argue by complementing/refining sentances so
that we reach final agreement.
Note 1: We really need a place to put those
specification documents. Kenn, what do you suggest? wiki or Svn? (we have the
constraint to make it evolve easily and to maintain it).
Note 2: We would like that such a specification document be published
concerning the palette.
2. Once a team took some time to elaborate a first specification document,
please respect the work and refer to it when reacting. It means:
- take the time to open this specification document
and read it completely
- complete it if needed by referencing the
requirements that you consider as incomplete or add new requirements but
ensure that they are consistent with others
- Provide samples to clarify
3. If the space of solutions must be explored to check
faisability, please create a new document or at least a new chapter so that
there is no confusion.
Thanks to all
regards
raphaël
TANGUY Yann 176637 a
écrit :
Right.
The model explorer should gives a visibility on models that are stored in a Papyrus project.
These models shoud have several serialization/storage facilities :
- native = di + notation + uml
- archived = zip file
- single file = a single xml file
- multi file = multiple xml file (granularity to be defined... Package ? Namespace ?)
This should be dealt with by an extension point in Papyrus, so that any one may add his own serialization / file management mechanism.
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de GERARD Sebastien 166342
Envoyé : mardi 20 octobre 2009 11:50
À : thibault.landre@xxxxxxxxxxxxxx
Cc : Papyrus Project list; Kenn Hussey; SZADEL Thomas
Objet : RE: [mdt-papyrus.dev] Specification of the single file management
I think we should have a Papyrus project concept.
-----Message d'origine-----
De : Thibault LANDRE [mailto:thibault.landre@xxxxxxxxxxxxxx]
Envoyé : mardi 20 octobre 2009 10:44
À : GERARD Sebastien 166342
Cc : Papyrus Project list; Kenn Hussey; SZADEL Thomas
Objet : Re: [mdt-papyrus.dev] Specification of the single file management
The Eclipse project concept doesn't suit your needs ?
GERARD Sebastien 166342 a écrit :
One advantage of zip is its ability to be able to embed other information in any kind of format.
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Thibault LANDRE
Envoyé : lundi 19 octobre 2009 17:07
À : Kenn Hussey
Cc : Papyrus Project list; SZADEL Thomas
Objet : Re: [mdt-papyrus.dev] Specification of the single file management
Kenn,
thanks for your comments.
Kenn Hussey a écrit :
Thibault,
This is a great starting point. A couple of comments/observations:
- we should get into the habit of using the term "resource" rather than
"file" because, ultimately, it shouldn't matter (to the tool) where/how
the content of a model/diagram is stored
You are right. I'll fix it
- I think the requirement to support containment proxies
(control/uncontrol actions) necessarily means that more than one
physical resource will make up a model
I agree. Each controlled model corresponds to a physical resource.
- just because compare/merge tooling doesn't support comparison of
binary resources out of the box doesn't mean we should exclude it as a
native serialization format, at least in my mind
In fact, it is possible to compare zip file. See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=273229
I have run a quick test on my environment and it seems to working fine
(Text Compare, EMF Compare...).
However it is not possible to do any merge.
But maybe we shouldn't allow user to merge their models. The *.emf,
*.notation, *.di are dependants. I think, merging will lead to more
issues than it solves. Advanced users could still unzip/zip their binary
resources to merge them.
- if we want to support arbitrary repositories (e.g. CVS vs. CDO, etc.)
transparently, we may need an "internal" storage structure/format that
is different from the source/storage format
I don't really get this point. Does this mean we should have a
(de)serialization mechanism before store our model in repositories ?
- we should also consider "backup" resources, e.g. so that we can
support things like autosave
Is the Local History not suited here ?
However we could add a mechanism to perform an autosave that user can
configure through preferences.
We propose to regroup all the content in a single file (EMF also deals
with it really well). We prototyped both solutions, and it ends up that
the single file seems to be the best solution. We certainly missed some
impacts / functionnalities.
Can you give us some arguments why having all the content in a single
file is not a good solution ?
To be clear, we are not "pro single file" or "pro zip". We would like to
find the best solution to implement this key functionnality as it will
be very difficult to modify our choice in the future.
We have not commited (we could have to) the patch for this reason.
By the way, has anyone tested the patch proposed ?
Regards,
Thibault
Cheers,
Kenn
2009/10/19 Thibault LANDRE <thibault.landre@xxxxxxxxxxxxxx
<mailto:thibault.landre@xxxxxxxxxxxxxx>>
Hi all,
You will find attached a proposed specification for the management
of resources in Papyrus.
Any remarks / comments is welcomed.
Regards,
Thibault
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx <mailto:mdt-papyrus.dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
_______________________________________________
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.
|
