Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] SCA v1.0

Hi Mike,

Attached you can find a document (scaModelCorrections.pdf) that explains the corrections that we made to enable the validation of the XSD model and the structural corrections on the XSD model. This work (in progress) was made by Damien Fournier (INRIA laboratory ADAM team).

I attached also a document (scaAdditionalValidationRules.pdf) that lists assertions appearing in the specification document. We check some of them in our code. This work is in progress too.

Best regards

Stéphane

Mike Edwards a écrit :
Stephane,

This is great stuff. I am really impressed that you even used colours that are so close to those in the SCA specification. I can't wait to have the code contributed to STP so I can get to play with it...

A couple of questions

- the revisions that you had to make to the SCA XSD - can you tell me about those. We are preparing an update to the spec and we are collecting Errata.

- please tell me about the "structural problems" that you encountered. Again, we'd like to fix the spec.

Yours, Mike Edwards.

Stéphane DRAPEAU wrote:
Hi Bogdan, all,

At Obeo we are also very interested in the graphical designer for SCA. Actually, we have a first prototype that allows to define an assembly (attached there is a screenshot of the prototype). To develop this graphical designer, we started from scheme available in the OSOA web site (http://www.osoa.org/xmlns/sca/1.0/ <http://www.osoa.org/xmlns/sca/1.0/>). In the following I'll give you some details of the way we are working. - As a first step we revised the OSOA scheme to reflect properly the SCA Assembly Model Specification and to enable the validation of the XSD model. We corrected also some structural problems. This work was done with the INRIA laboratory (ADAM team). - As a second step, we generated the ecore models and made some modifications. For example, in the Wire EClass, we define source and target as EReference (in the initial model, target and source are EAttribute). - Then, we generated the code and we added some validation rules like "the component name must be unique in the composite". I think this is important because these rules exist in the specification document but they do not appear in the XSD scheme. - Finally, we developed a first version of our graphical designer. It works with Eclipse Europa, EMF 2.3 and GMF 2.0. This SCA Designer follows the SCA official specification to represent composites, services, wires... See the screenshot.

Currently, we are following the procedure to submit this graphical designer as an IP Zilla bug. If everyone is ok, this will be the initial contribution of the SCA Designer project.

This work is part of the SCOrWare project (which is supported by the French National Research Agency and OW2) that has two main goals: - to develop a component-based implementation of the SCA specification and - to develop high-level tools to facilitate end users to adopt this technology. In this project, Obeo is leading the work concerning tools and contributions for Eclipse. We are working on several tools: designers, STP extensions, code generation, etc... We can discuss on them later.

It will be great if we can work together in the graphical designer. Franco Scavuzzo told me that he is interested in working with us. To continue with this work, we are interested in creating a new STP subproject (as an incubation project if necessary). We are ok to lead it.
Who is interested in this work? What do you think about all this?

Best regards

Stéphane Drapeau
Obeo


Vatkov, Bogdan a écrit :

Hi Adrian,
I saw you have been assigned to the issue https://bugs.eclipse.org/bugs/show_bug.cgi?id=181693. Do you have any progress on that? Is it possible for me to help you with this issue? Actually I have the SCA v1.0 metamodel already imported (from XSD) as EMF model and I am using it locally for our SCA design-time implementation. Do you think it is meaningful to send you what I have for the sca1.0 emf based meta-model? This particular problem is the key point for us to start extending the STP framework. Currently we do not extend (or even re-use on API basis) any STP part but we would like to do so. (Un)fortunatelly we needed SCA v1.0 for our SCA design-time support for the SCA runtime that we are implementing and I had to create the sca 1.0 metamodel. Now I would like to have it inside STP and actually start using the entire platform, extend extension points, propose new extension points etc. Best regards,
Bogdan
------------------------------------------------------------------------

_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev



------------------------------------------------------------------------


------------------------------------------------------------------------

_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev



Attachment: scaModelCorrections.pdf
Description: Adobe PDF document

Attachment: scaAdditionalValidationRules.pdf
Description: Adobe PDF document


Back to the top