[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stp-dev] SCA component introspection
|
Hi Bogdan,
[0] describes the SCA meta model used by the SCA Composite Designer. I added the new references that are not serialized but calculated directly in corrected OSOA XSD files (Meta model modifications section). Corrected OSOA XSD files are not committed because they had license problems. These problems are being solved and I will be able to commit them.
Then, I added manually the Tuscany elements in the Ecore file. I added the namespace EAnnotation in the Ecore file for Tuscany elements. All it's ok in the EMF part but with GMF I have still some issues to solve. I can add Tuscany elements with the SCA Composite Designer with the right namespace, but if I close the file and I open it again, Tuscany elements disapear (but they are still present in the EMF model...). This is an important issue but I needed a quick solution for the demonstrations I made. I'm trying to solve it.
The next step isn't to modify the Ecore file but to integrate Tuscany XSD files and then to generate the Ecore file. I will do this. If you want to integrate ASAP new implementations, send them to me or modify directly the Ecore file. I think the first solution is better. I master the add/remove/re-generation cycle with the Ecore file ;) . If it's not urgent please wait a bit, I need some time to commit the corrected OSOA XSD files.
I think that for the moment we will work with XSD files and generate the Ecore file. In background, I think about how to add some facilities for extensibility.
Best regards
Stéphane Drapeau
Obeo
[0] http://wiki.eclipse.org/SCA_Composite_Meta_Model
On Sat, 5 Jan 2008 19:01:48 +0100, "Vatkov, Bogdan" <bogdan.vatkov@xxxxxxx> wrote:
> Hi Stephane,
>
> Some months ago I was trying to find a way to define extensible EMF model
> with constant namespace but as described by Ed it is not possible to have
> multiple ecore models based on multiple xsds sharing one and the same
> target namespace, you can see the thread at [0].
> This means that we will have to change the source models for the complete
> SCA tooling each time we decide to add new implementation or binding.
> I was wondering how you applied all the corrections (and the tuscany
> specific additions) to the ecore files - are you using some automated
> approach, e.g. XSLT transformation over the ecore file or some other
> technique, or you manually applied the changes?
> How have you added the Tuscany implementation and bindings? Was it through
> corresponding XSDs and adding them to the sca.xsd or you made the changes
> in the sca.ecore after importing from xsds?
> We would need to add several implementation XSDs to the sca.xsd file and
> bring them also to the ecore file: sca-implementation-ejb.xsd,
> sca-implementation-web.xsd, sca-implementation-bpel.xsd.
>
> Could you integrate these into the sca meta-model? How can I help you with
> this? Can we define an automated approach for correcting of the model so
> that new impl or bindings can be added easily in the future?
>
> Best regards,
> Bogdan
>
> PS: regarding the introspection wiki page - I will try to create such -
> the only thing that I have for now is a concept how it should look like, no
> explicit interfaces, extension points, etc. defined yet.
>
> [0] - http://dev.eclipse.org/newslists/news.eclipse.modeling/msg00246.html
>
>
> -----Original Message-----
> From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Stéphane Drapeau
> Sent: Friday, January 04, 2008 6:48 PM
> To: STP Dev list
> Subject: Re: [stp-dev] SCA component introspection
>
> Vatkov, Bogdan a écrit :
>>
>> Hi Stephane, Etienne,
>>
>>
>>
>> Happy New Year!
>>
>>
>>
>> I would like to discuss with you the SCA introspection mechanism. I've
>> noticed that the implementation of java and composite introspection of
>> SCA components that you have provided is bound to the DnD
>> functionality for the SCA Composite Designer editor.
>>
>> I would propose the following approach:
>>
>> A definition of SCA Component Introspection interface that re-uses the
>> SCA Metamodel API for the result of the introspection process and uses
>> files for input.
>>
>> If this pattern is followed then a new extension point shall be
>> defined (for the component introspection) and the DragAndDrop
>> extension point would be extended only once for introspection of SCA
>> Components. You could have another extensions for dragging and
>> dropping of other elements, e.g. Services - that would be WSDL file or
>> Java file, containing interface definition, are dropped onto a
>> component/composite reference or component/composite service in the
>> diagram.
>>
>>
>>
>> Would you agree with refactoring of this part so that the
>> introspection itself is not bound or not dependent on graphical or
>> even editor related code?
>>
>>
>>
>> Thanks in advance.
>>
>>
>>
>> Best regards,
>>
>> Bogdan
>>
>>
>>
>>
>> ps://dev.eclipse.org/mailman/listinfo/stp-dev
>>
> Hi Bogdan,
>
> Happy New Year to you as well!
>
> I totally agree with you. It's up to you ;)
> I tried to outsource XImplementation, XInterface and XBinding. I started
> with the DnD functionality for SCAImplementation and JavaImplementation.
> But with other aspects, I have not yet succeeded to do what I want. I
> search a way to add easily new binding, implementation and interface...
>
> Are you agree to create a wiki page dedicated to the SCA Composite
> Introspector [0]?
>
> Best regards,
>
> Stéphane Drapeau
> Obeo
>
> [0] http://wiki.eclipse.org/SCA_Composite_Tools_roadmap
> _______________________________________________
> 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
