Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » AMW » AMW evolution wishes
AMW evolution wishes [message #468651] Tue, 04 November 2008 10:13 Go to next message
Gabriel BARBIER is currently offline Gabriel BARBIER
Messages: 106
Registered: July 2009
Senior Member
Hello AMW team and everyone,

Because I'm not able to edit following page in wiki :
http://wiki.eclipse.org/index.php?title=AMW_Wish_List&ac tion=edit,
I post here some ideas. And I think it is a good place to discuss about
them ...

AMW structure :
1. First of all, AMW and AM3(Mega modeling) share a lot of concepts in
their meta models. Perhaps these concepts could be factorized in a parent
meta model. Or a simpler scenario could be : AM3 offers links at model
level, and AMW extends AM3 to offer links at level of model elements.
2. And with AM3, we could store informations about weaved models and meta
models, instead of using a properties file so we would be able to delete
these damned file.

AMW model handler :
3. being able to use models and meta models already loaded in EMF registry
(so perhaps without physical representations of these models)
4. To be more general, being able to use all existing protocols in EMF to
use models and meta models : file, platform, resource, uri, plugin, etc.
5. When a weaved model is a Emf UML2 model and contains a multiplicity
'*', the basic EMF connector is not able to load it. We could improve AMW
model handler to extends basic connector for each specific meta models.
Exception thrown :
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value '*' is
not legal.
6. Configuration : how to define a strategy when a meta class is defined
twice, for example : load or not the second meta model, ignore new
definition, ...

ATL model handler for AMW :
7. When an AMW model has been written, the associated properties file
should have been written also.


For all these wishes, I'm waiting for your feedbacks and an order (what
priority you give ?) to know what to implement and when.

Regards,
Gabriel
Re: AMW evolution wishes [message #468676 is a reply to message #468651] Wed, 19 November 2008 12:36 Go to previous messageGo to next message
Marcos Didonet Del Fabro is currently offline Marcos Didonet Del Fabro
Messages: 84
Registered: July 2009
Member
Hi,

Thanks for collaborating. I have some comments below.

> Because I'm not able to edit following page in wiki :
> http://wiki.eclipse.org/index.php?title=AMW_Wish_List&ac tion=edit,
> I post here some ideas. And I think it is a good place to discuss about
> them ...

You can create a Bugzilla account to be able to edit the Eclipse Wiki. :)

> AMW structure :
> 1. First of all, AMW and AM3(Mega modeling) share a lot of concepts in
> their meta models. Perhaps these concepts could be factorized in a parent
> meta model. Or a simpler scenario could be : AM3 offers links at model
> level, and AMW extends AM3 to offer links at level of model elements.

I agree, specially the extension and linking capabilities. Historically,
AMW was developed earlier than AM3, thus we didn't have this
factorization in mind.

For instance, using AMW coupled with AM3 would avoid having the .prop
file, which adds some complexity for keeping the files.

> 2. And with AM3, we could store informations about weaved models and meta
> models, instead of using a properties file so we would be able to delete
> these damned file.

See above.. :)

> AMW model handler :
> 3. being able to use models and meta models already loaded in EMF registry
> (so perhaps without physical representations of these models)

AMW already handles metamodels that are in the registry. However, the
URI must be typed manually in the edit boxes, e.g., http://....

An extension to models is also closely related with an integration with AM3.

> 4. To be more general, being able to use all existing protocols in EMF to
> use models and meta models : file, platform, resource, uri, plugin, etc.

Yep. In my opinion, It would be even better to re-factor the model
management primitives to use a generic model handler (we stick to EMF so
far), in a similar way than ATL, so we could use EMF, MD3, KM3, the UML2
driver, etc..

> 5. When a weaved model is a Emf UML2 model and contains a multiplicity
> '*', the basic EMF connector is not able to load it. We could improve AMW
> model handler to extends basic connector for each specific meta models.
> Exception thrown :
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Value '*' is
> not legal.

I haven't experienced that error. You could add a bugzilla entry so we
could keep track on that.
One possible solution could be inspired in the job done by the Dually
plugin (http://www.eclipse.org/gmt/amw/usecases/dually/). This plug-in
contribute with nice extensions to better handle UML2 models with AMW.

> 6. Configuration : how to define a strategy when a meta class is defined
> twice, for example : load or not the second meta model, ignore new
> definition, ...

You mean when the KM3 extension is loaded? In this case, the input
metamodel should follow the spec of KM3. If the metamodel is not
correct, it should not be loaded.

> ATL model handler for AMW :
> 7. When an AMW model has been written, the associated properties file
> should have been written also.

I didn't get this issue..


Regards,

Marcos.
Re: AMW evolution wishes [message #469133 is a reply to message #468676] Thu, 04 December 2008 10:08 Go to previous message
Gabriel BARBIER is currently offline Gabriel BARBIER
Messages: 106
Registered: July 2009
Senior Member
Just for informations, even with a valid bugzilla account, I cannot edit
whishes page for AMW : 'group user' may be the point ...
Regards, Gabriel


Permission error
From Eclipsepedia
Jump to: navigation, search
You do not have permission to do that, for the following reason:
The action you have requested is limited to users in the group user.
Previous Topic:The sources of AMW have been committed
Next Topic:Export of AMW plugins
Goto Forum:
  


Current Time: Sat Aug 30 16:40:00 EDT 2014

Powered by FUDForum. Page generated in 0.09939 seconds