Home » Modeling » Modeling (top-level project) » Build from source and Extentions to EMF and Ecore Editor
| Build from source and Extentions to EMF and Ecore Editor [message #378458] |
Mon, 22 January 2007 14:14  |
 Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Hi everybody!
I am working on a project in which we want to extend EMF to support more
complex model constraints than what EMFT OCL allows. The whole idea is to
write a plugin, a graphical editor, that is based on GMF (like the Ecore
editor) that is customizable by users and is independant on diagrammatic
notations. In the editor, constraints will be expressed on the arrows, not
the nodes, and constraints on multiple arrows, i.e. diagrams are allowed.
A short theoretical background for the project is explained and submitted
as a short talk to EclipseCon 2007 here:
http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=4072
My questions are:
1) I have got the source code for EMF, GMF and the graphical Ecore editor
(from CVS.) If I do changes to the source code, how can I build the source
and deploy the plug-ins such that I can test them in practise?
2) Is the procedure mentioned in question one a good and "standard" way to
do this kind of extention to eclipse plug-ins and technologies?
3) I will have to make small changes to the EMF metamodel also, and I
suppose that I can do that in the same way as in q1, am I write?
Cheers
Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #378461 is a reply to message #378458] |
Mon, 22 January 2007 14:29  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Adrian,
Comments below.
Adrian wrote:
> Hi everybody!
>
> I am working on a project in which we want to extend EMF to support
> more complex model constraints than what EMFT OCL allows. The whole
> idea is to write a plugin, a graphical editor, that is based on GMF
> (like the Ecore editor) that is customizable by users and is
> independant on diagrammatic notations. In the editor, constraints will
> be expressed on the arrows, not the nodes, and constraints on multiple
> arrows, i.e. diagrams are allowed.
>
> A short theoretical background for the project is explained and
> submitted as a short talk to EclipseCon 2007 here:
> http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=4072
>
> My questions are:
>
> 1) I have got the source code for EMF, GMF and the graphical Ecore
> editor (from CVS.) If I do changes to the source code, how can I build
> the source and deploy the plug-ins such that I can test them in practise?
How to deploy a plugin is a basic Eclipse question. You'd use
"File->Export...->Plug-in Development->Deployable features" or perhaps
"Deployable plug-in and fragments"
>
> 2) Is the procedure mentioned in question one a good and "standard"
> way to do this kind of extention to eclipse plug-ins and technologies?
It's not generally a great idea to change the source and if you do take
that approach, the resulting code is EPL and you are obligated to make
the source publicly available.
>
> 3) I will have to make small changes to the EMF metamodel also, and I
> suppose that I can do that in the same way as in q1, am I write?
Again, changes to the framework's source code should be avoided whenever
possible. Can't your goal be accomplished by annotating the Ecore model,
rather than modifying it?
>
>
> Cheers
> Adrian
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #378464 is a reply to message #378461] |
Mon, 22 January 2007 21:16 |
Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Ed Merks wrote:
>> My questions are:
>>
>> 1) I have got the source code for EMF, GMF and the graphical Ecore
>> editor (from CVS.) If I do changes to the source code, how can I build
>> the source and deploy the plug-ins such that I can test them in practise?
> How to deploy a plugin is a basic Eclipse question. You'd use
> "File->Export...->Plug-in Development->Deployable features" or perhaps
> "Deployable plug-in and fragments"
Sorry for my bad formulation, a better question would be; where do I find
information about changing/rebuilding EMF and EMFT and the technologies
realted to them?
Is there any other approach that can be used to make changes in EMF? One
way is to download the source from CVS, make changes, rebuild as a new
plug-in. But I didn't succeed in that because the procedure that you also
have described finds only the exmaples and the eclipse.gmf.ecore.editor
(none of deployable features or ... and fragments worked for me).
Therefore I used PDE Tools -> convert projects to plugin projects, and
this changes the project from a java project to a plugin project which I
have exported to a JAR file and tried to deploy in my eclipse workbench.
I don't think the way I have done it is a right way, because a) my plug-in
will have the same name and properties and will overwrite the original one
b) the plug-in does not appear in a new instance of eclipse as it should do
>>
>> 2) Is the procedure mentioned in question one a good and "standard"
>> way to do this kind of extention to eclipse plug-ins and technologies?
> It's not generally a great idea to change the source and if you do take
> that approach, the resulting code is EPL and you are obligated to make
> the source publicly available.
Well, all of the source code of our project will be EPLed and publicly
available.
>>
>> 3) I will have to make small changes to the EMF metamodel also, and I
>> suppose that I can do that in the same way as in q1, am I write?
> Again, changes to the framework's source code should be avoided whenever
> possible. Can't your goal be accomplished by annotating the Ecore model,
> rather than modifying it?
I will consider your suggestion, but since we want to exploit the code
generation facilities of EMF, we have to do some changes in the way in
which EMF generates the JET templates also.
Thank you for your help!
>>
>>
>> Cheers
>> Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #378468 is a reply to message #378464] |
Tue, 23 January 2007 14:53 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000405090003010102050109
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Adrian,
Comments below.
adrian wrote:
> Ed Merks wrote:
>
>>> My questions are:
>>>
>>> 1) I have got the source code for EMF, GMF and the graphical Ecore
>>> editor (from CVS.) If I do changes to the source code, how can I
>>> build the source and deploy the plug-ins such that I can test them
>>> in practise?
>> How to deploy a plugin is a basic Eclipse question. You'd use
>> "File->Export...->Plug-in Development->Deployable features" or
>> perhaps "Deployable plug-in and fragments"
>
> Sorry for my bad formulation, a better question would be; where do I
> find information about changing/rebuilding EMF and EMFT and the
> technologies realted to them? Is there any other approach that can be
> used to make changes in EMF?
I'm curious why you need to make changes. If a framework can't be used
as is, it should be made more flexible...
> One way is to download the source from CVS, make changes, rebuild as a
> new plug-in. But I didn't succeed in that because the procedure that
> you also have described finds only the exmaples and the
> eclipse.gmf.ecore.editor (none of deployable features or ... and
> fragments worked for me).
Extracting from CVS is how we do our development work and from this
result, it should be possible to export plugins. You'd need to extract
the features as well if you want to export based on features.
> Therefore I used PDE Tools -> convert projects to plugin projects, and
> this changes the project from a java project to a plugin project which
> I have exported to a JAR file and tried to deploy in my eclipse
> workbench.
They should already be plugin projects, so I'm not sure exactly what you
are doing. Did you follow the instructions on the EMF documentation
page for extracting from CVS?
> don't think the way I have done it is a right way, because a) my
> plug-in will have the same name and properties and will overwrite the
> original one b) the plug-in does not appear in a new instance of
> eclipse as it should do
When we do our builds, we use the PDE builder. We have public builds
set up on the eclipse servers for some of the EMFT projects. This link
would help with that:
<http://wiki.eclipse.org/index.php/EMFT_Procedures>
http://wiki.eclipse.org/index.php/EMFT_Procedures
>
>>>
>>> 2) Is the procedure mentioned in question one a good and "standard"
>>> way to do this kind of extention to eclipse plug-ins and technologies?
>> It's not generally a great idea to change the source and if you do
>> take that approach, the resulting code is EPL and you are obligated
>> to make the source publicly available.
>
> Well, all of the source code of our project will be EPLed and publicly
> available.
>
>>>
>>> 3) I will have to make small changes to the EMF metamodel also, and
>>> I suppose that I can do that in the same way as in q1, am I write?
>> Again, changes to the framework's source code should be avoided
>> whenever possible. Can't your goal be accomplished by annotating the
>> Ecore model, rather than modifying it?
>
> I will consider your suggestion, but since we want to exploit the code
> generation facilities of EMF, we have to do some changes in the way in
> which EMF generates the JET templates also.
Again, if the framework needs to be more flexible, that would seem a
better approach then making changes (and trying to keep your changes in
sync with our moving target). It's currently possible to override
templates and to plug-in new ones, so I'm not sure what else is needed
that requires changes to the framework itself...
>
> Thank you for your help!
>
>>>
>>>
>>> Cheers
>>> Adrian
>
>
--------------000405090003010102050109
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
<br>
adrian wrote:
<blockquote cite="mide31553108099a514f9780e8732dbf2b9$1@www.eclipse.org"
type="cite">Ed Merks wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">My questions are:
<br>
<br>
1) I have got the source code for EMF, GMF and the graphical Ecore
editor (from CVS.) If I do changes to the source code, how can I build
the source and deploy the plug-ins such that I can test them in
practise?
<br>
</blockquote>
How to deploy a plugin is a basic Eclipse question.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #378472 is a reply to message #378468] |
Tue, 23 January 2007 18:58 |
Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Ed Merks skrev:
> Adrian,
>
> Comments below.
>
>
> adrian wrote:
>
>>
>> Sorry for my bad formulation, a better question would be; where do I
>> find information about changing/rebuilding EMF and EMFT and the
>> technologies realted to them? Is there any other approach that can be
>> used to make changes in EMF?
> I'm curious why you need to make changes. If a framework can't be used
> as is, it should be made more flexible...
That's what I mean by changes, I want to make EMF more flexible, but
don't know where to start. I have read most of the documentations about
EMF and EMFT, but don't find how to put my ideas into work.
The idea starts from a mathematical formalism called Generalized
Sketches GS which is based on Category Theory. The claim is that all
specification techniques in software engineering can be seen as an
instance of the GS specification pattern.
In order to prove our claim, we need to design and implement a graphical
editor to draw diagrammatic specifications based on GS. The user should
be able to desing her/his own graphical notations and draw a model
diagram using those notations. Graphical otations should be chosen for
the essential properties of nodes, mappings and diagrams that may occur
in the model. For example, the Entity nodes are chosen to be
rectangular, the value nodes circular, total mappings to be arrows with
a dot in their start point, relations between two or more nodes to be an
Entity node representing tupling of values from the related nodes (with
necessary constraints placed on the arrows going from the relation node
to the related nodes; called diagarm constraints,) inclusion as a double
arrow ... and so on.
After this step, which we call for designing a SIGNATURE, the user will
be able to draw the diagram/specification, which we call for "a
visualization of a sketch". Our graphical tool will generate a .ecore
model out of the drawing. Then the .ecore model will be given as an
input to the EMF framework and Java code is generated (all this done
automatically, without bothering the user to start a new EMF project
....etc).
Well, this is the basics of the theory of our project, and the theory of
GS has the expressive power to express diagrammatic specifications in a
formal way without needing to write constraint notes and attaching them
to our model, and this makes MDA development more attractive.
In practise, we have to do "something" to make all this happen; my idea
was to look at the code of org.eclipse.gmf.ecore.editor, which is a
graphical editor based on GMF, and reuse it to implement our graphical
editor. Then implement an export functionality to the editor to make it
capable of generating .ecore out of the "pictures".
Then I found out that Ecore alone is not expressive enough to express
all kinds of constraints (like for eg. diagram constraints,) therefore
emft.ocl and emft.validation ...etc technologies are used together with
EMF to enhance model integrity. I have not tested these technologies
quite well yet, but I suppose that they are extentions on top of EMF
framework, to make EMF more applicable. It's also obvious that the EMF
OCL plug-in has made changes in the way in which EMF generates Java
code, since the generated code after installing OCL is different from
the one before.
The quetion is, how those "changes" are done? Are the other technologies
just extentions that build on the top of EMF with changing the (for
example) JET templates generated by EMF? Or do they use their own copy
of EMF? May be I don't know how to ask the question since I am lost in
the documentations of Eclipse and its plug-ins.
> They should already be plugin projects, so I'm not sure exactly what you
> are doing. Did you follow the instructions on the EMF documentation
> page for extracting from CVS?
I have read that, yes, and I do exactly what it says. But may be I have
to learn more about developing Plug-ins, something is missing and I
don't what it is; I get nothing to select when I choose Export ->
plug-in development -> deployable features, and I get only
org.eclipse.gmf when I choose deployable plug-ins and fragments.
>> don't think the way I have done it is a right way, because a) my
>> plug-in will have the same name and properties and will overwrite the
>> original one b) the plug-in does not appear in a new instance of
>> eclipse as it should do
> When we do our builds, we use the PDE builder. We have public builds
> set up on the eclipse servers for some of the EMFT projects. This link
> would help with that:
> <http://wiki.eclipse.org/index.php/EMFT_Procedures>
>
> http://wiki.eclipse.org/index.php/EMFT_Procedures
>
I have not access to that server, and the link is a little bit
intimidating. Is that a procedure for everybody, or only for Eclipse
commiters? Ofcourse we are intented to make an extention and make it
available to everybody, but at the start, we just want to test it by
ourselves, on a local server. That should be an easier task, isn't it?
>> I will consider your suggestion, but since we want to exploit the code
>> generation facilities of EMF, we have to do some changes in the way in
>> which EMF generates the JET templates also.
> Again, if the framework needs to be more flexible, that would seem a
> better approach then making changes (and trying to keep your changes in
> sync with our moving target). It's currently possible to override
> templates and to plug-in new ones, so I'm not sure what else is needed
> that requires changes to the framework itself...
If I can override the templates and plug-in new ones, then the code
generation part of my problem will be solved, and this is what I was
mistakingly meaning by making changes in the framework. But possible
changes in the Ecore metamodel may be necessary to express the diagram
constraints mentioned above. In all cases, I think I have to use the
same approach as the developers of emft.ocl have used, but I don't know
how and what they have done, I only see and can test the results.
There is certainly a tutorial hidden somewhere in the documentations
that I can use to learn what I need to know.
PS! diagam constraints may be as simple as [inv] which can be put on two
oppsite mappings between two Entities (modeled by eOpposite in Ecore.)
And as complex as ([1-1],3) which is put on a ternay relationship (i.e.
on the arrows emerging from the relation node to three Entities/Values;
this is used to express UML's association class,) for which Ecore has no
support.
Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #378476 is a reply to message #378472] |
Tue, 23 January 2007 20:11 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070402010007040109090609
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Adrian,
Comments below.
adrian rutle wrote:
> Ed Merks skrev:
>
>> Adrian,
>>
>> Comments below.
>>
>>
>> adrian wrote:
>>
>>
>>> Sorry for my bad formulation, a better question would be; where do I
>>> find information about changing/rebuilding EMF and EMFT and the
>>> technologies realted to them? Is there any other approach that can be
>>> used to make changes in EMF?
>>>
>> I'm curious why you need to make changes. If a framework can't be used
>> as is, it should be made more flexible...
>>
>
> That's what I mean by changes, I want to make EMF more flexible, but
> don't know where to start. I have read most of the documentations about
> EMF and EMFT, but don't find how to put my ideas into work.
>
> The idea starts from a mathematical formalism called Generalized
> Sketches GS which is based on Category Theory. The claim is that all
> specification techniques in software engineering can be seen as an
> instance of the GS specification pattern.
>
> In order to prove our claim, we need to design and implement a graphical
> editor to draw diagrammatic specifications based on GS. The user should
> be able to desing her/his own graphical notations and draw a model
> diagram using those notations. Graphical otations should be chosen for
> the essential properties of nodes, mappings and diagrams that may occur
> in the model. For example, the Entity nodes are chosen to be
> rectangular, the value nodes circular, total mappings to be arrows with
> a dot in their start point, relations between two or more nodes to be an
> Entity node representing tupling of values from the related nodes (with
> necessary constraints placed on the arrows going from the relation node
> to the related nodes; called diagarm constraints,) inclusion as a double
> arrow ... and so on.
>
> After this step, which we call for designing a SIGNATURE, the user will
> be able to draw the diagram/specification, which we call for "a
> visualization of a sketch". Our graphical tool will generate a .ecore
> model out of the drawing. Then the .ecore model will be given as an
> input to the EMF framework and Java code is generated (all this done
> automatically, without bothering the user to start a new EMF project
> ...etc).
>
> Well, this is the basics of the theory of our project, and the theory of
> GS has the expressive power to express diagrammatic specifications in a
> formal way without needing to write constraint notes and attaching them
> to our model, and this makes MDA development more attractive.
>
> In practise, we have to do "something" to make all this happen; my idea
> was to look at the code of org.eclipse.gmf.ecore.editor, which is a
> graphical editor based on GMF, and reuse it to implement our graphical
> editor. Then implement an export functionality to the editor to make it
> capable of generating .ecore out of the "pictures".
>
> Then I found out that Ecore alone is not expressive enough to express
> all kinds of constraints (like for eg. diagram constraints,) therefore
> emft.ocl and emft.validation ...etc technologies are used together with
> EMF to enhance model integrity. I have not tested these technologies
> quite well yet, but I suppose that they are extentions on top of EMF
> framework, to make EMF more applicable. It's also obvious that the EMF
> OCL plug-in has made changes in the way in which EMF generates Java
> code, since the generated code after installing OCL is different from
> the one before.
>
> The quetion is, how those "changes" are done? Are the other technologies
> just extentions that build on the top of EMF with changing the (for
> example) JET templates generated by EMF? Or do they use their own copy
> of EMF? May be I don't know how to ask the question since I am lost in
> the documentations of Eclipse and its plug-ins.
>
These other projects just extend the basic framework. Copying and
changing it generally not a good idea. It would probably use useful to
look at how org.eclipse.emf.examples.generator.validator extends EMF's
generator.
>
>
>> They should already be plugin projects, so I'm not sure exactly what you
>> are doing. Did you follow the instructions on the EMF documentation
>> page for extracting from CVS?
>>
>
> I have read that, yes, and I do exactly what it says. But may be I have
> to learn more about developing Plug-ins, something is missing and I
> don't what it is; I get nothing to select when I choose Export ->
> plug-in development -> deployable features, and I get only
> org.eclipse.gmf when I choose deployable plug-ins and fragments.
>
It sounds like you probably don't have any features in the workspace
then, only the plugins...
>
>>> don't think the way I have done it is a right way, because a) my
>>> plug-in will have the same name and properties and will overwrite the
>>> original one b) the plug-in does not appear in a new instance of
>>> eclipse as it should do
>>>
>> When we do our builds, we use the PDE builder. We have public builds
>> set up on the eclipse servers for some of the EMFT projects. This link
>> would help with that:
>> <http://wiki.eclipse.org/index.php/EMFT_Procedures>
>>
>> http://wiki.eclipse.org/index.php/EMFT_Procedures
>>
>>
>
> I have not access to that server, and the link is a little bit
> intimidating. Is that a procedure for everybody, or only for Eclipse
> commiters?
It's for folks setting up a CVS image that needs to be built and
packaged the same way we do EMF.
> Ofcourse we are intented to make an extention and make it
> available to everybody, but at the start, we just want to test it by
> ourselves, on a local server. That should be an easier task, isn't it?
>
Yeah. In fact, you should not need to deploy anything. You should just
be able to start a runtime workbench and try it out.
>
>>> I will consider your suggestion, but since we want to exploit the code
>>> generation facilities of EMF, we have to do some changes in the way in
>>> which EMF generates the JET templates also.
>>>
>> Again, if the framework needs to be more flexible, that would seem a
>> better approach then making changes (and trying to keep your changes in
>> sync with our moving target). It's currently possible to override
>> templates and to plug-in new ones, so I'm not sure what else is needed
>> that requires changes to the framework itself...
>>
>
> If I can override the templates and plug-in new ones, then the code
> generation part of my problem will be solved, and this is what I was
> mistakingly meaning by making changes in the framework. But possible
> changes in the Ecore metamodel may be necessary to express the diagram
> constraints mentioned above. In all cases, I think I have to use the
> same approach as the developers of emft.ocl have used, but I don't know
> how and what they have done, I only see and can test the results.
>
In general we recommend not extending the Ecore model (via derived
classes that extend EModelElement or anything below it). Since any
model element can be annotated and since any EAnnotation can contain or
reference any other EObject, annotating/decorating the Ecore model
should be sufficient.
> There is certainly a tutorial hidden somewhere in the documentations
> that I can use to learn what I need to know.
>
> PS! diagam constraints may be as simple as [inv] which can be put on two
> oppsite mappings between two Entities (modeled by eOpposite in Ecore.)
> And as complex as ([1-1],3) which is put on a ternay relationship (i.e.
> on the arrows emerging from the relation node to three Entities/Values;
> this is used to express UML's association class,) for which Ecore has no
> support.
>
It all sounds interesting. Good luck.
>
>
> Adrian
>
--------------070402010007040109090609
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
adrian rutle wrote:
<blockquote cite="midep5ls9$l72$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Merks skrev:
</pre>
<blockquote type="cite">
<pre wrap="">Adrian,
Comments below.
adrian wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Sorry for my bad formulation, a better question would be; where do I
find information about changing/rebuilding EMF and EMFT and the
technologies realted to them? Is there any other approach that can be
used to make changes in EMF?
</pre>
</blockquote>
<pre wrap="">I'm curious why you need to make changes. If a framework can't be used
as is, it should be made more flexible...
</pre>
</blockquote>
<pre wrap=""><!---->
That's what I mean by changes, I want to make EMF more flexible, but
don't know where to start. I have read most of the documentations about
EMF and EMFT, but don't find how to put my ideas into work.
The idea starts from a mathematical formalism called Generalized
Sketches GS which is based on Category Theory. The claim is that all
specification techniques in software engineering can be seen as an
instance of the GS specification pattern.
In order to prove our claim, we need to design and implement a graphical
editor to draw diagrammatic specifications based on GS. The user should
be able to desing her/his own graphical notations and draw a model
diagram using those notations. Graphical otations should be chosen for
the essential properties of nodes, mappings and diagrams that may occur
in the model. For example, the Entity nodes are chosen to be
rectangular, the value nodes circular, total mappings to be arrows with
a dot in their start point, relations between two or more nodes to be an
Entity node representing tupling of values from the related nodes (with
necessary constraints placed on the arrows going from the relation node
to the related nodes; called diagarm constraints,) inclusion as a double
arrow ... and so on.
After this step, which we call for designing a SIGNATURE, the user will
be able to draw the diagram/specification, which we call for "a
visualization of a sketch". Our graphical tool will generate a .ecore
model out of the drawing. Then the .ecore model will be given as an
input to the EMF framework and Java code is generated (all this done
automatically, without bothering the user to start a new EMF project
....etc).
Well, this is the basics of the theory of our project, and the theory of
GS has the expressive power to express diagrammatic specifications in a
formal way without needing to write constraint notes and attaching them
to our model, and this makes MDA development more attractive.
In practise, we have to do "something" to make all this happen; my idea
was to look at the code of org.eclipse.gmf.ecore.editor, which is a
graphical editor based on GMF, and reuse it to implement our graphical
editor. Then implement an export functionality to the editor to make it
capable of generating .ecore out of the "pictures".
Then I found out that Ecore alone is not expressive enough to express
all kinds of constraints (like for eg. diagram constraints,) therefore
emft.ocl and emft.validation ...etc technologies are used together with
EMF to enhance model integrity. I have not tested these technologies
quite well yet, but I suppose that they are extentions on top of EMF
framework, to make EMF more applicable. It's also obvious that the EMF
OCL plug-in has made changes in the way in which EMF generates Java
code, since the generated code after installing OCL is different from
the one before.
The quetion is, how those "changes" are done? Are the other technologies
just extentions that build on the top of EMF with changing the (for
example) JET templates generated by EMF? Or do they use their own copy
of EMF? May be I don't know how to ask the question since I am lost in
the documentations of Eclipse and its plug-ins.
</pre>
</blockquote>
These other projects just extend the basic framework.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #378478 is a reply to message #378476] |
Wed, 24 January 2007 13:08 |
Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Ed Merks skrev:
> Adrian,
>
> Comments below.
>
> adrian rutle wrote:
>>
>> The quetion is, how those "changes" are done? Are the other technologies
>> just extentions that build on the top of EMF with changing the (for
>> example) JET templates generated by EMF? Or do they use their own copy
>> of EMF? May be I don't know how to ask the question since I am lost in
>> the documentations of Eclipse and its plug-ins.
>>
> These other projects just extend the basic framework. Copying and
> changing it generally not a good idea. It would probably use useful to
> look at how org.eclipse.emf.examples.generator.validator extends EMF's
> generator.
I have looked at this now, I will continue exploring the code today. I
hope I succeed in doing something similar during today.
But, do you know about any tutorials that the authors of those projects
have followed to make those extentions? The procedure you sent me last
time seemed to be for professional Eclipse commiters or folks who have
been involved in Eclipse for a while. I may need something that explains
,step by step, the procedure of extending the basic framework, starting
from downloading the source, starting a new project ... through
deploying and testing the new extention on localhost (to start with.)
Am I asking for something that should be done? or does that kind of
tutorial exist already, but I havn't found it yet?
>>
>> I have read that, yes, and I do exactly what it says. But may be I have
>> to learn more about developing Plug-ins, something is missing and I
>> don't what it is; I get nothing to select when I choose Export ->
>> plug-in development -> deployable features, and I get only
>> org.eclipse.gmf when I choose deployable plug-ins and fragments.
>>
> It sounds like you probably don't have any features in the workspace
> then, only the plugins...
I have followed the instructions ;-/
>>
>>
>> If I can override the templates and plug-in new ones, then the code
>> generation part of my problem will be solved, and this is what I was
>> mistakingly meaning by making changes in the framework. But possible
>> changes in the Ecore metamodel may be necessary to express the diagram
>> constraints mentioned above. In all cases, I think I have to use the
>> same approach as the developers of emft.ocl have used, but I don't know
>> how and what they have done, I only see and can test the results.
>>
> In general we recommend not extending the Ecore model (via derived
> classes that extend EModelElement or anything below it). Since any
> model element can be annotated and since any EAnnotation can contain or
> reference any other EObject, annotating/decorating the Ecore model
> should be sufficient.
It seems that you understand me now ;-) Yes, I WILL use the eAnnotation
field of the EModelElement (and its desendants.) And I have been
thinking about different objects that this eAnnotation would refere to
in order to express/save the constraints that our modeling
pattern/language supports. But since I didn't udnerstand well the usage
of EAnnotation and didn't find too much about it in the EMF book nor the
Internet, I began to think about extending the Ecore metamodel.
I do agree with your recommendation and am sure that it is a good idea
to do it that way. So, I wonder if you know about any tutorial,
documentation or guidlines that I can use to learn about what I need in
order to start coding my graphical editor (to draw diagrams in the same
way as the gmf.ecore.editor, EclipseUML by Omondo or UML2, with
possibilities to export to .ecore models (with annotations))?
> It all sounds interesting. Good luck.
Thank you, and I appreciate your answers ;-)
Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #379632 is a reply to message #378478] |
Wed, 24 January 2007 15:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070307070002050708050102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Adrian,
Comments below.
adrian rutle wrote:
> Ed Merks skrev:
>
>> Adrian,
>>
>> Comments below.
>>
>> adrian rutle wrote:
>>
>>> The quetion is, how those "changes" are done? Are the other technologies
>>> just extentions that build on the top of EMF with changing the (for
>>> example) JET templates generated by EMF? Or do they use their own copy
>>> of EMF? May be I don't know how to ask the question since I am lost in
>>> the documentations of Eclipse and its plug-ins.
>>>
>>>
>> These other projects just extend the basic framework. Copying and
>> changing it generally not a good idea. It would probably use useful to
>> look at how org.eclipse.emf.examples.generator.validator extends EMF's
>> generator.
>>
>
> I have looked at this now, I will continue exploring the code today. I
> hope I succeed in doing something similar during today.
>
> But, do you know about any tutorials that the authors of those projects
> have followed to make those extentions?
All EMF documentation is on our documentation page, so if you don't see
it there, it doesn't exist.
> The procedure you sent me last
> time seemed to be for professional Eclipse commiters or folks who have
> been involved in Eclipse for a while.
Yes, instructions are intended for people who will be setting up a
Eclipse build. To set up an extension, you shouldn't need to do so many
complex things.
> I may need something that explains
> ,step by step, the procedure of extending the basic framework, starting
> from downloading the source, starting a new project ... through
> deploying and testing the new extention on localhost (to start with.)
>
You should not need to download the source for EMF nor should you need
to build it. If you follow one of our introductory tutorials you'll
see all the steps you typically need to create plugins and run them.
From there it's all "basic" Eclipse support to export these plugins and
deploy them.
> Am I asking for something that should be done? or does that kind of
> tutorial exist already, but I havn't found it yet?
>
>
>>> I have read that, yes, and I do exactly what it says. But may be I have
>>> to learn more about developing Plug-ins, something is missing and I
>>> don't what it is; I get nothing to select when I choose Export ->
>>> plug-in development -> deployable features, and I get only
>>> org.eclipse.gmf when I choose deployable plug-ins and fragments.
>>>
>>>
>> It sounds like you probably don't have any features in the workspace
>> then, only the plugins...
>>
>
> I have followed the instructions ;-/
>
>
>>>
>>>
>>> If I can override the templates and plug-in new ones, then the code
>>> generation part of my problem will be solved, and this is what I was
>>> mistakingly meaning by making changes in the framework. But possible
>>> changes in the Ecore metamodel may be necessary to express the diagram
>>> constraints mentioned above. In all cases, I think I have to use the
>>> same approach as the developers of emft.ocl have used, but I don't know
>>> how and what they have done, I only see and can test the results.
>>>
>>>
>> In general we recommend not extending the Ecore model (via derived
>> classes that extend EModelElement or anything below it). Since any
>> model element can be annotated and since any EAnnotation can contain or
>> reference any other EObject, annotating/decorating the Ecore model
>> should be sufficient.
>>
>
> It seems that you understand me now ;-) Yes, I WILL use the eAnnotation
> field of the EModelElement (and its desendants.) And I have been
> thinking about different objects that this eAnnotation would refere to
> in order to express/save the constraints that our modeling
> pattern/language supports. But since I didn't udnerstand well the usage
> of EAnnotation and didn't find too much about it in the EMF book nor the
> Internet, I began to think about extending the Ecore metamodel.
>
> I do agree with your recommendation and am sure that it is a good idea
> to do it that way. So, I wonder if you know about any tutorial,
> documentation or guidlines that I can use to learn about what I need in
> order to start coding my graphical editor (to draw diagrams in the same
> way as the gmf.ecore.editor, EclipseUML by Omondo or UML2, with
> possibilities to export to .ecore models (with annotations))?
>
Unfortunately documentation is often lacking, so the best things to do
are to look at other things that are very similar. Which is what you
are already doing...
>
>> It all sounds interesting. Good luck.
>>
>
> Thank you, and I appreciate your answers ;-)
>
> Adrian
>
--------------070307070002050708050102
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
adrian rutle wrote:
<blockquote cite="midep7lol$jng$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Merks skrev:
</pre>
<blockquote type="cite">
<pre wrap="">Adrian,
Comments below.
adrian rutle wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The quetion is, how those "changes" are done? Are the other technologies
just extentions that build on the top of EMF with changing the (for
example) JET templates generated by EMF? Or do they use their own copy
of EMF? May be I don't know how to ask the question since I am lost in
the documentations of Eclipse and its plug-ins.
</pre>
</blockquote>
<pre wrap="">These other projects just extend the basic framework. Copying and
changing it generally not a good idea. It would probably use useful to
look at how org.eclipse.emf.examples.generator.validator extends EMF's
generator.
</pre>
</blockquote>
<pre wrap=""><!---->
I have looked at this now, I will continue exploring the code today. I
hope I succeed in doing something similar during today.
But, do you know about any tutorials that the authors of those projects
have followed to make those extentions? </pre>
</blockquote>
All EMF documentation is on our documentation page, so if you don't see
it there, it doesn't exist.<br>
<blockquote cite="midep7lol$jng$1@utils.eclipse.org" type="cite">
<pre wrap="">The procedure you sent me last
time seemed to be for professional Eclipse commiters or folks who have
been involved in Eclipse for a while. </pre>
</blockquote>
Yes, instructions are intended for people who will be setting up a
Eclipse build.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586191 is a reply to message #378458] |
Mon, 22 January 2007 14:29 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Adrian,
Comments below.
Adrian wrote:
> Hi everybody!
>
> I am working on a project in which we want to extend EMF to support
> more complex model constraints than what EMFT OCL allows. The whole
> idea is to write a plugin, a graphical editor, that is based on GMF
> (like the Ecore editor) that is customizable by users and is
> independant on diagrammatic notations. In the editor, constraints will
> be expressed on the arrows, not the nodes, and constraints on multiple
> arrows, i.e. diagrams are allowed.
>
> A short theoretical background for the project is explained and
> submitted as a short talk to EclipseCon 2007 here:
> http://eclipsezilla.eclipsecon.org/show_bug.cgi?id=4072
>
> My questions are:
>
> 1) I have got the source code for EMF, GMF and the graphical Ecore
> editor (from CVS.) If I do changes to the source code, how can I build
> the source and deploy the plug-ins such that I can test them in practise?
How to deploy a plugin is a basic Eclipse question. You'd use
"File->Export...->Plug-in Development->Deployable features" or perhaps
"Deployable plug-in and fragments"
>
> 2) Is the procedure mentioned in question one a good and "standard"
> way to do this kind of extention to eclipse plug-ins and technologies?
It's not generally a great idea to change the source and if you do take
that approach, the resulting code is EPL and you are obligated to make
the source publicly available.
>
> 3) I will have to make small changes to the EMF metamodel also, and I
> suppose that I can do that in the same way as in q1, am I write?
Again, changes to the framework's source code should be avoided whenever
possible. Can't your goal be accomplished by annotating the Ecore model,
rather than modifying it?
>
>
> Cheers
> Adrian
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586205 is a reply to message #378461] |
Mon, 22 January 2007 21:16 |
Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Ed Merks wrote:
>> My questions are:
>>
>> 1) I have got the source code for EMF, GMF and the graphical Ecore
>> editor (from CVS.) If I do changes to the source code, how can I build
>> the source and deploy the plug-ins such that I can test them in practise?
> How to deploy a plugin is a basic Eclipse question. You'd use
> "File->Export...->Plug-in Development->Deployable features" or perhaps
> "Deployable plug-in and fragments"
Sorry for my bad formulation, a better question would be; where do I find
information about changing/rebuilding EMF and EMFT and the technologies
realted to them?
Is there any other approach that can be used to make changes in EMF? One
way is to download the source from CVS, make changes, rebuild as a new
plug-in. But I didn't succeed in that because the procedure that you also
have described finds only the exmaples and the eclipse.gmf.ecore.editor
(none of deployable features or ... and fragments worked for me).
Therefore I used PDE Tools -> convert projects to plugin projects, and
this changes the project from a java project to a plugin project which I
have exported to a JAR file and tried to deploy in my eclipse workbench.
I don't think the way I have done it is a right way, because a) my plug-in
will have the same name and properties and will overwrite the original one
b) the plug-in does not appear in a new instance of eclipse as it should do
>>
>> 2) Is the procedure mentioned in question one a good and "standard"
>> way to do this kind of extention to eclipse plug-ins and technologies?
> It's not generally a great idea to change the source and if you do take
> that approach, the resulting code is EPL and you are obligated to make
> the source publicly available.
Well, all of the source code of our project will be EPLed and publicly
available.
>>
>> 3) I will have to make small changes to the EMF metamodel also, and I
>> suppose that I can do that in the same way as in q1, am I write?
> Again, changes to the framework's source code should be avoided whenever
> possible. Can't your goal be accomplished by annotating the Ecore model,
> rather than modifying it?
I will consider your suggestion, but since we want to exploit the code
generation facilities of EMF, we have to do some changes in the way in
which EMF generates the JET templates also.
Thank you for your help!
>>
>>
>> Cheers
>> Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586230 is a reply to message #378464] |
Tue, 23 January 2007 14:53 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------000405090003010102050109
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Adrian,
Comments below.
adrian wrote:
> Ed Merks wrote:
>
>>> My questions are:
>>>
>>> 1) I have got the source code for EMF, GMF and the graphical Ecore
>>> editor (from CVS.) If I do changes to the source code, how can I
>>> build the source and deploy the plug-ins such that I can test them
>>> in practise?
>> How to deploy a plugin is a basic Eclipse question. You'd use
>> "File->Export...->Plug-in Development->Deployable features" or
>> perhaps "Deployable plug-in and fragments"
>
> Sorry for my bad formulation, a better question would be; where do I
> find information about changing/rebuilding EMF and EMFT and the
> technologies realted to them? Is there any other approach that can be
> used to make changes in EMF?
I'm curious why you need to make changes. If a framework can't be used
as is, it should be made more flexible...
> One way is to download the source from CVS, make changes, rebuild as a
> new plug-in. But I didn't succeed in that because the procedure that
> you also have described finds only the exmaples and the
> eclipse.gmf.ecore.editor (none of deployable features or ... and
> fragments worked for me).
Extracting from CVS is how we do our development work and from this
result, it should be possible to export plugins. You'd need to extract
the features as well if you want to export based on features.
> Therefore I used PDE Tools -> convert projects to plugin projects, and
> this changes the project from a java project to a plugin project which
> I have exported to a JAR file and tried to deploy in my eclipse
> workbench.
They should already be plugin projects, so I'm not sure exactly what you
are doing. Did you follow the instructions on the EMF documentation
page for extracting from CVS?
> don't think the way I have done it is a right way, because a) my
> plug-in will have the same name and properties and will overwrite the
> original one b) the plug-in does not appear in a new instance of
> eclipse as it should do
When we do our builds, we use the PDE builder. We have public builds
set up on the eclipse servers for some of the EMFT projects. This link
would help with that:
<http://wiki.eclipse.org/index.php/EMFT_Procedures>
http://wiki.eclipse.org/index.php/EMFT_Procedures
>
>>>
>>> 2) Is the procedure mentioned in question one a good and "standard"
>>> way to do this kind of extention to eclipse plug-ins and technologies?
>> It's not generally a great idea to change the source and if you do
>> take that approach, the resulting code is EPL and you are obligated
>> to make the source publicly available.
>
> Well, all of the source code of our project will be EPLed and publicly
> available.
>
>>>
>>> 3) I will have to make small changes to the EMF metamodel also, and
>>> I suppose that I can do that in the same way as in q1, am I write?
>> Again, changes to the framework's source code should be avoided
>> whenever possible. Can't your goal be accomplished by annotating the
>> Ecore model, rather than modifying it?
>
> I will consider your suggestion, but since we want to exploit the code
> generation facilities of EMF, we have to do some changes in the way in
> which EMF generates the JET templates also.
Again, if the framework needs to be more flexible, that would seem a
better approach then making changes (and trying to keep your changes in
sync with our moving target). It's currently possible to override
templates and to plug-in new ones, so I'm not sure what else is needed
that requires changes to the framework itself...
>
> Thank you for your help!
>
>>>
>>>
>>> Cheers
>>> Adrian
>
>
--------------000405090003010102050109
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
<br>
adrian wrote:
<blockquote cite="mide31553108099a514f9780e8732dbf2b9$1@www.eclipse.org"
type="cite">Ed Merks wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">My questions are:
<br>
<br>
1) I have got the source code for EMF, GMF and the graphical Ecore
editor (from CVS.) If I do changes to the source code, how can I build
the source and deploy the plug-ins such that I can test them in
practise?
<br>
</blockquote>
How to deploy a plugin is a basic Eclipse question.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586238 is a reply to message #378468] |
Tue, 23 January 2007 18:58 |
Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Ed Merks skrev:
> Adrian,
>
> Comments below.
>
>
> adrian wrote:
>
>>
>> Sorry for my bad formulation, a better question would be; where do I
>> find information about changing/rebuilding EMF and EMFT and the
>> technologies realted to them? Is there any other approach that can be
>> used to make changes in EMF?
> I'm curious why you need to make changes. If a framework can't be used
> as is, it should be made more flexible...
That's what I mean by changes, I want to make EMF more flexible, but
don't know where to start. I have read most of the documentations about
EMF and EMFT, but don't find how to put my ideas into work.
The idea starts from a mathematical formalism called Generalized
Sketches GS which is based on Category Theory. The claim is that all
specification techniques in software engineering can be seen as an
instance of the GS specification pattern.
In order to prove our claim, we need to design and implement a graphical
editor to draw diagrammatic specifications based on GS. The user should
be able to desing her/his own graphical notations and draw a model
diagram using those notations. Graphical otations should be chosen for
the essential properties of nodes, mappings and diagrams that may occur
in the model. For example, the Entity nodes are chosen to be
rectangular, the value nodes circular, total mappings to be arrows with
a dot in their start point, relations between two or more nodes to be an
Entity node representing tupling of values from the related nodes (with
necessary constraints placed on the arrows going from the relation node
to the related nodes; called diagarm constraints,) inclusion as a double
arrow ... and so on.
After this step, which we call for designing a SIGNATURE, the user will
be able to draw the diagram/specification, which we call for "a
visualization of a sketch". Our graphical tool will generate a .ecore
model out of the drawing. Then the .ecore model will be given as an
input to the EMF framework and Java code is generated (all this done
automatically, without bothering the user to start a new EMF project
....etc).
Well, this is the basics of the theory of our project, and the theory of
GS has the expressive power to express diagrammatic specifications in a
formal way without needing to write constraint notes and attaching them
to our model, and this makes MDA development more attractive.
In practise, we have to do "something" to make all this happen; my idea
was to look at the code of org.eclipse.gmf.ecore.editor, which is a
graphical editor based on GMF, and reuse it to implement our graphical
editor. Then implement an export functionality to the editor to make it
capable of generating .ecore out of the "pictures".
Then I found out that Ecore alone is not expressive enough to express
all kinds of constraints (like for eg. diagram constraints,) therefore
emft.ocl and emft.validation ...etc technologies are used together with
EMF to enhance model integrity. I have not tested these technologies
quite well yet, but I suppose that they are extentions on top of EMF
framework, to make EMF more applicable. It's also obvious that the EMF
OCL plug-in has made changes in the way in which EMF generates Java
code, since the generated code after installing OCL is different from
the one before.
The quetion is, how those "changes" are done? Are the other technologies
just extentions that build on the top of EMF with changing the (for
example) JET templates generated by EMF? Or do they use their own copy
of EMF? May be I don't know how to ask the question since I am lost in
the documentations of Eclipse and its plug-ins.
> They should already be plugin projects, so I'm not sure exactly what you
> are doing. Did you follow the instructions on the EMF documentation
> page for extracting from CVS?
I have read that, yes, and I do exactly what it says. But may be I have
to learn more about developing Plug-ins, something is missing and I
don't what it is; I get nothing to select when I choose Export ->
plug-in development -> deployable features, and I get only
org.eclipse.gmf when I choose deployable plug-ins and fragments.
>> don't think the way I have done it is a right way, because a) my
>> plug-in will have the same name and properties and will overwrite the
>> original one b) the plug-in does not appear in a new instance of
>> eclipse as it should do
> When we do our builds, we use the PDE builder. We have public builds
> set up on the eclipse servers for some of the EMFT projects. This link
> would help with that:
> <http://wiki.eclipse.org/index.php/EMFT_Procedures>
>
> http://wiki.eclipse.org/index.php/EMFT_Procedures
>
I have not access to that server, and the link is a little bit
intimidating. Is that a procedure for everybody, or only for Eclipse
commiters? Ofcourse we are intented to make an extention and make it
available to everybody, but at the start, we just want to test it by
ourselves, on a local server. That should be an easier task, isn't it?
>> I will consider your suggestion, but since we want to exploit the code
>> generation facilities of EMF, we have to do some changes in the way in
>> which EMF generates the JET templates also.
> Again, if the framework needs to be more flexible, that would seem a
> better approach then making changes (and trying to keep your changes in
> sync with our moving target). It's currently possible to override
> templates and to plug-in new ones, so I'm not sure what else is needed
> that requires changes to the framework itself...
If I can override the templates and plug-in new ones, then the code
generation part of my problem will be solved, and this is what I was
mistakingly meaning by making changes in the framework. But possible
changes in the Ecore metamodel may be necessary to express the diagram
constraints mentioned above. In all cases, I think I have to use the
same approach as the developers of emft.ocl have used, but I don't know
how and what they have done, I only see and can test the results.
There is certainly a tutorial hidden somewhere in the documentations
that I can use to learn what I need to know.
PS! diagam constraints may be as simple as [inv] which can be put on two
oppsite mappings between two Entities (modeled by eOpposite in Ecore.)
And as complex as ([1-1],3) which is put on a ternay relationship (i.e.
on the arrows emerging from the relation node to three Entities/Values;
this is used to express UML's association class,) for which Ecore has no
support.
Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586253 is a reply to message #378472] |
Tue, 23 January 2007 20:11 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070402010007040109090609
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Adrian,
Comments below.
adrian rutle wrote:
> Ed Merks skrev:
>
>> Adrian,
>>
>> Comments below.
>>
>>
>> adrian wrote:
>>
>>
>>> Sorry for my bad formulation, a better question would be; where do I
>>> find information about changing/rebuilding EMF and EMFT and the
>>> technologies realted to them? Is there any other approach that can be
>>> used to make changes in EMF?
>>>
>> I'm curious why you need to make changes. If a framework can't be used
>> as is, it should be made more flexible...
>>
>
> That's what I mean by changes, I want to make EMF more flexible, but
> don't know where to start. I have read most of the documentations about
> EMF and EMFT, but don't find how to put my ideas into work.
>
> The idea starts from a mathematical formalism called Generalized
> Sketches GS which is based on Category Theory. The claim is that all
> specification techniques in software engineering can be seen as an
> instance of the GS specification pattern.
>
> In order to prove our claim, we need to design and implement a graphical
> editor to draw diagrammatic specifications based on GS. The user should
> be able to desing her/his own graphical notations and draw a model
> diagram using those notations. Graphical otations should be chosen for
> the essential properties of nodes, mappings and diagrams that may occur
> in the model. For example, the Entity nodes are chosen to be
> rectangular, the value nodes circular, total mappings to be arrows with
> a dot in their start point, relations between two or more nodes to be an
> Entity node representing tupling of values from the related nodes (with
> necessary constraints placed on the arrows going from the relation node
> to the related nodes; called diagarm constraints,) inclusion as a double
> arrow ... and so on.
>
> After this step, which we call for designing a SIGNATURE, the user will
> be able to draw the diagram/specification, which we call for "a
> visualization of a sketch". Our graphical tool will generate a .ecore
> model out of the drawing. Then the .ecore model will be given as an
> input to the EMF framework and Java code is generated (all this done
> automatically, without bothering the user to start a new EMF project
> ...etc).
>
> Well, this is the basics of the theory of our project, and the theory of
> GS has the expressive power to express diagrammatic specifications in a
> formal way without needing to write constraint notes and attaching them
> to our model, and this makes MDA development more attractive.
>
> In practise, we have to do "something" to make all this happen; my idea
> was to look at the code of org.eclipse.gmf.ecore.editor, which is a
> graphical editor based on GMF, and reuse it to implement our graphical
> editor. Then implement an export functionality to the editor to make it
> capable of generating .ecore out of the "pictures".
>
> Then I found out that Ecore alone is not expressive enough to express
> all kinds of constraints (like for eg. diagram constraints,) therefore
> emft.ocl and emft.validation ...etc technologies are used together with
> EMF to enhance model integrity. I have not tested these technologies
> quite well yet, but I suppose that they are extentions on top of EMF
> framework, to make EMF more applicable. It's also obvious that the EMF
> OCL plug-in has made changes in the way in which EMF generates Java
> code, since the generated code after installing OCL is different from
> the one before.
>
> The quetion is, how those "changes" are done? Are the other technologies
> just extentions that build on the top of EMF with changing the (for
> example) JET templates generated by EMF? Or do they use their own copy
> of EMF? May be I don't know how to ask the question since I am lost in
> the documentations of Eclipse and its plug-ins.
>
These other projects just extend the basic framework. Copying and
changing it generally not a good idea. It would probably use useful to
look at how org.eclipse.emf.examples.generator.validator extends EMF's
generator.
>
>
>> They should already be plugin projects, so I'm not sure exactly what you
>> are doing. Did you follow the instructions on the EMF documentation
>> page for extracting from CVS?
>>
>
> I have read that, yes, and I do exactly what it says. But may be I have
> to learn more about developing Plug-ins, something is missing and I
> don't what it is; I get nothing to select when I choose Export ->
> plug-in development -> deployable features, and I get only
> org.eclipse.gmf when I choose deployable plug-ins and fragments.
>
It sounds like you probably don't have any features in the workspace
then, only the plugins...
>
>>> don't think the way I have done it is a right way, because a) my
>>> plug-in will have the same name and properties and will overwrite the
>>> original one b) the plug-in does not appear in a new instance of
>>> eclipse as it should do
>>>
>> When we do our builds, we use the PDE builder. We have public builds
>> set up on the eclipse servers for some of the EMFT projects. This link
>> would help with that:
>> <http://wiki.eclipse.org/index.php/EMFT_Procedures>
>>
>> http://wiki.eclipse.org/index.php/EMFT_Procedures
>>
>>
>
> I have not access to that server, and the link is a little bit
> intimidating. Is that a procedure for everybody, or only for Eclipse
> commiters?
It's for folks setting up a CVS image that needs to be built and
packaged the same way we do EMF.
> Ofcourse we are intented to make an extention and make it
> available to everybody, but at the start, we just want to test it by
> ourselves, on a local server. That should be an easier task, isn't it?
>
Yeah. In fact, you should not need to deploy anything. You should just
be able to start a runtime workbench and try it out.
>
>>> I will consider your suggestion, but since we want to exploit the code
>>> generation facilities of EMF, we have to do some changes in the way in
>>> which EMF generates the JET templates also.
>>>
>> Again, if the framework needs to be more flexible, that would seem a
>> better approach then making changes (and trying to keep your changes in
>> sync with our moving target). It's currently possible to override
>> templates and to plug-in new ones, so I'm not sure what else is needed
>> that requires changes to the framework itself...
>>
>
> If I can override the templates and plug-in new ones, then the code
> generation part of my problem will be solved, and this is what I was
> mistakingly meaning by making changes in the framework. But possible
> changes in the Ecore metamodel may be necessary to express the diagram
> constraints mentioned above. In all cases, I think I have to use the
> same approach as the developers of emft.ocl have used, but I don't know
> how and what they have done, I only see and can test the results.
>
In general we recommend not extending the Ecore model (via derived
classes that extend EModelElement or anything below it). Since any
model element can be annotated and since any EAnnotation can contain or
reference any other EObject, annotating/decorating the Ecore model
should be sufficient.
> There is certainly a tutorial hidden somewhere in the documentations
> that I can use to learn what I need to know.
>
> PS! diagam constraints may be as simple as [inv] which can be put on two
> oppsite mappings between two Entities (modeled by eOpposite in Ecore.)
> And as complex as ([1-1],3) which is put on a ternay relationship (i.e.
> on the arrows emerging from the relation node to three Entities/Values;
> this is used to express UML's association class,) for which Ecore has no
> support.
>
It all sounds interesting. Good luck.
>
>
> Adrian
>
--------------070402010007040109090609
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
adrian rutle wrote:
<blockquote cite="midep5ls9$l72$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Merks skrev:
</pre>
<blockquote type="cite">
<pre wrap="">Adrian,
Comments below.
adrian wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Sorry for my bad formulation, a better question would be; where do I
find information about changing/rebuilding EMF and EMFT and the
technologies realted to them? Is there any other approach that can be
used to make changes in EMF?
</pre>
</blockquote>
<pre wrap="">I'm curious why you need to make changes. If a framework can't be used
as is, it should be made more flexible...
</pre>
</blockquote>
<pre wrap=""><!---->
That's what I mean by changes, I want to make EMF more flexible, but
don't know where to start. I have read most of the documentations about
EMF and EMFT, but don't find how to put my ideas into work.
The idea starts from a mathematical formalism called Generalized
Sketches GS which is based on Category Theory. The claim is that all
specification techniques in software engineering can be seen as an
instance of the GS specification pattern.
In order to prove our claim, we need to design and implement a graphical
editor to draw diagrammatic specifications based on GS. The user should
be able to desing her/his own graphical notations and draw a model
diagram using those notations. Graphical otations should be chosen for
the essential properties of nodes, mappings and diagrams that may occur
in the model. For example, the Entity nodes are chosen to be
rectangular, the value nodes circular, total mappings to be arrows with
a dot in their start point, relations between two or more nodes to be an
Entity node representing tupling of values from the related nodes (with
necessary constraints placed on the arrows going from the relation node
to the related nodes; called diagarm constraints,) inclusion as a double
arrow ... and so on.
After this step, which we call for designing a SIGNATURE, the user will
be able to draw the diagram/specification, which we call for "a
visualization of a sketch". Our graphical tool will generate a .ecore
model out of the drawing. Then the .ecore model will be given as an
input to the EMF framework and Java code is generated (all this done
automatically, without bothering the user to start a new EMF project
....etc).
Well, this is the basics of the theory of our project, and the theory of
GS has the expressive power to express diagrammatic specifications in a
formal way without needing to write constraint notes and attaching them
to our model, and this makes MDA development more attractive.
In practise, we have to do "something" to make all this happen; my idea
was to look at the code of org.eclipse.gmf.ecore.editor, which is a
graphical editor based on GMF, and reuse it to implement our graphical
editor. Then implement an export functionality to the editor to make it
capable of generating .ecore out of the "pictures".
Then I found out that Ecore alone is not expressive enough to express
all kinds of constraints (like for eg. diagram constraints,) therefore
emft.ocl and emft.validation ...etc technologies are used together with
EMF to enhance model integrity. I have not tested these technologies
quite well yet, but I suppose that they are extentions on top of EMF
framework, to make EMF more applicable. It's also obvious that the EMF
OCL plug-in has made changes in the way in which EMF generates Java
code, since the generated code after installing OCL is different from
the one before.
The quetion is, how those "changes" are done? Are the other technologies
just extentions that build on the top of EMF with changing the (for
example) JET templates generated by EMF? Or do they use their own copy
of EMF? May be I don't know how to ask the question since I am lost in
the documentations of Eclipse and its plug-ins.
</pre>
</blockquote>
These other projects just extend the basic framework.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586265 is a reply to message #378476] |
Wed, 24 January 2007 13:08 |
Adrian Rutle
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Ed Merks skrev:
> Adrian,
>
> Comments below.
>
> adrian rutle wrote:
>>
>> The quetion is, how those "changes" are done? Are the other technologies
>> just extentions that build on the top of EMF with changing the (for
>> example) JET templates generated by EMF? Or do they use their own copy
>> of EMF? May be I don't know how to ask the question since I am lost in
>> the documentations of Eclipse and its plug-ins.
>>
> These other projects just extend the basic framework. Copying and
> changing it generally not a good idea. It would probably use useful to
> look at how org.eclipse.emf.examples.generator.validator extends EMF's
> generator.
I have looked at this now, I will continue exploring the code today. I
hope I succeed in doing something similar during today.
But, do you know about any tutorials that the authors of those projects
have followed to make those extentions? The procedure you sent me last
time seemed to be for professional Eclipse commiters or folks who have
been involved in Eclipse for a while. I may need something that explains
,step by step, the procedure of extending the basic framework, starting
from downloading the source, starting a new project ... through
deploying and testing the new extention on localhost (to start with.)
Am I asking for something that should be done? or does that kind of
tutorial exist already, but I havn't found it yet?
>>
>> I have read that, yes, and I do exactly what it says. But may be I have
>> to learn more about developing Plug-ins, something is missing and I
>> don't what it is; I get nothing to select when I choose Export ->
>> plug-in development -> deployable features, and I get only
>> org.eclipse.gmf when I choose deployable plug-ins and fragments.
>>
> It sounds like you probably don't have any features in the workspace
> then, only the plugins...
I have followed the instructions ;-/
>>
>>
>> If I can override the templates and plug-in new ones, then the code
>> generation part of my problem will be solved, and this is what I was
>> mistakingly meaning by making changes in the framework. But possible
>> changes in the Ecore metamodel may be necessary to express the diagram
>> constraints mentioned above. In all cases, I think I have to use the
>> same approach as the developers of emft.ocl have used, but I don't know
>> how and what they have done, I only see and can test the results.
>>
> In general we recommend not extending the Ecore model (via derived
> classes that extend EModelElement or anything below it). Since any
> model element can be annotated and since any EAnnotation can contain or
> reference any other EObject, annotating/decorating the Ecore model
> should be sufficient.
It seems that you understand me now ;-) Yes, I WILL use the eAnnotation
field of the EModelElement (and its desendants.) And I have been
thinking about different objects that this eAnnotation would refere to
in order to express/save the constraints that our modeling
pattern/language supports. But since I didn't udnerstand well the usage
of EAnnotation and didn't find too much about it in the EMF book nor the
Internet, I began to think about extending the Ecore metamodel.
I do agree with your recommendation and am sure that it is a good idea
to do it that way. So, I wonder if you know about any tutorial,
documentation or guidlines that I can use to learn about what I need in
order to start coding my graphical editor (to draw diagrams in the same
way as the gmf.ecore.editor, EclipseUML by Omondo or UML2, with
possibilities to export to .ecore models (with annotations))?
> It all sounds interesting. Good luck.
Thank you, and I appreciate your answers ;-)
Adrian
|
|
|
| Re: Build from source and Extentions to EMF and Ecore Editor [message #586520 is a reply to message #378478] |
Wed, 24 January 2007 15:15 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------070307070002050708050102
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Adrian,
Comments below.
adrian rutle wrote:
> Ed Merks skrev:
>
>> Adrian,
>>
>> Comments below.
>>
>> adrian rutle wrote:
>>
>>> The quetion is, how those "changes" are done? Are the other technologies
>>> just extentions that build on the top of EMF with changing the (for
>>> example) JET templates generated by EMF? Or do they use their own copy
>>> of EMF? May be I don't know how to ask the question since I am lost in
>>> the documentations of Eclipse and its plug-ins.
>>>
>>>
>> These other projects just extend the basic framework. Copying and
>> changing it generally not a good idea. It would probably use useful to
>> look at how org.eclipse.emf.examples.generator.validator extends EMF's
>> generator.
>>
>
> I have looked at this now, I will continue exploring the code today. I
> hope I succeed in doing something similar during today.
>
> But, do you know about any tutorials that the authors of those projects
> have followed to make those extentions?
All EMF documentation is on our documentation page, so if you don't see
it there, it doesn't exist.
> The procedure you sent me last
> time seemed to be for professional Eclipse commiters or folks who have
> been involved in Eclipse for a while.
Yes, instructions are intended for people who will be setting up a
Eclipse build. To set up an extension, you shouldn't need to do so many
complex things.
> I may need something that explains
> ,step by step, the procedure of extending the basic framework, starting
> from downloading the source, starting a new project ... through
> deploying and testing the new extention on localhost (to start with.)
>
You should not need to download the source for EMF nor should you need
to build it. If you follow one of our introductory tutorials you'll
see all the steps you typically need to create plugins and run them.
From there it's all "basic" Eclipse support to export these plugins and
deploy them.
> Am I asking for something that should be done? or does that kind of
> tutorial exist already, but I havn't found it yet?
>
>
>>> I have read that, yes, and I do exactly what it says. But may be I have
>>> to learn more about developing Plug-ins, something is missing and I
>>> don't what it is; I get nothing to select when I choose Export ->
>>> plug-in development -> deployable features, and I get only
>>> org.eclipse.gmf when I choose deployable plug-ins and fragments.
>>>
>>>
>> It sounds like you probably don't have any features in the workspace
>> then, only the plugins...
>>
>
> I have followed the instructions ;-/
>
>
>>>
>>>
>>> If I can override the templates and plug-in new ones, then the code
>>> generation part of my problem will be solved, and this is what I was
>>> mistakingly meaning by making changes in the framework. But possible
>>> changes in the Ecore metamodel may be necessary to express the diagram
>>> constraints mentioned above. In all cases, I think I have to use the
>>> same approach as the developers of emft.ocl have used, but I don't know
>>> how and what they have done, I only see and can test the results.
>>>
>>>
>> In general we recommend not extending the Ecore model (via derived
>> classes that extend EModelElement or anything below it). Since any
>> model element can be annotated and since any EAnnotation can contain or
>> reference any other EObject, annotating/decorating the Ecore model
>> should be sufficient.
>>
>
> It seems that you understand me now ;-) Yes, I WILL use the eAnnotation
> field of the EModelElement (and its desendants.) And I have been
> thinking about different objects that this eAnnotation would refere to
> in order to express/save the constraints that our modeling
> pattern/language supports. But since I didn't udnerstand well the usage
> of EAnnotation and didn't find too much about it in the EMF book nor the
> Internet, I began to think about extending the Ecore metamodel.
>
> I do agree with your recommendation and am sure that it is a good idea
> to do it that way. So, I wonder if you know about any tutorial,
> documentation or guidlines that I can use to learn about what I need in
> order to start coding my graphical editor (to draw diagrams in the same
> way as the gmf.ecore.editor, EclipseUML by Omondo or UML2, with
> possibilities to export to .ecore models (with annotations))?
>
Unfortunately documentation is often lacking, so the best things to do
are to look at other things that are very similar. Which is what you
are already doing...
>
>> It all sounds interesting. Good luck.
>>
>
> Thank you, and I appreciate your answers ;-)
>
> Adrian
>
--------------070307070002050708050102
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Adrian,<br>
<br>
Comments below.<br>
<br>
adrian rutle wrote:
<blockquote cite="midep7lol$jng$1@utils.eclipse.org" type="cite">
<pre wrap="">Ed Merks skrev:
</pre>
<blockquote type="cite">
<pre wrap="">Adrian,
Comments below.
adrian rutle wrote:
</pre>
<blockquote type="cite">
<pre wrap="">The quetion is, how those "changes" are done? Are the other technologies
just extentions that build on the top of EMF with changing the (for
example) JET templates generated by EMF? Or do they use their own copy
of EMF? May be I don't know how to ask the question since I am lost in
the documentations of Eclipse and its plug-ins.
</pre>
</blockquote>
<pre wrap="">These other projects just extend the basic framework. Copying and
changing it generally not a good idea. It would probably use useful to
look at how org.eclipse.emf.examples.generator.validator extends EMF's
generator.
</pre>
</blockquote>
<pre wrap=""><!---->
I have looked at this now, I will continue exploring the code today. I
hope I succeed in doing something similar during today.
But, do you know about any tutorials that the authors of those projects
have followed to make those extentions? </pre>
</blockquote>
All EMF documentation is on our documentation page, so if you don't see
it there, it doesn't exist.<br>
<blockquote cite="midep7lol$jng$1@utils.eclipse.org" type="cite">
<pre wrap="">The procedure you sent me last
time seemed to be for professional Eclipse commiters or folks who have
been involved in Eclipse for a while. </pre>
</blockquote>
Yes, instructions are intended for people who will be setting up a
Eclipse build.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 13:53:50 GMT 2024
Powered by FUDForum. Page generated in 0.04993 seconds |
] 
Search
Help
Register
Login
Home
