Home » Eclipse Projects » GEF » Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform
| Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #144597] |
Tue, 27 July 2004 15:01  |
 Ed Burnette
Messages: 279
Registered: July 2009 |
Senior Member |
|
|
As you may know, IBM's contribution to the Web Tools Project
( http://www.eclipse.org/webtools/initial-contribution/IBM/Get ting%20Started.
html), and almost certainly the final WTP itself, has some hefty
prerequisites including (*):
- Eclipse SDK (Eclipse project = Platform + JDT + PDE)
- EMF SDK (Tools subproject)
- GEF SDK (Tools subproject)
- XSD SDK (Technology subproject)
I believe it is time to put the last three in the Eclipse Platform project.
In this post I'll lay out some Pros and Cons and then ask for more input and
direction. Here are the Pros I can think of:
Pro#1. Many other projects are depending on them. They provide basic
enabling functionality. Isn't that the definition of Platform?
Pro#2. According to www.eclipse.org/projects, the Tools project is "a focal
point for diverse tool builders" (CDT is a good example). The Technology
project is for "research, incubators, and education" (EXESIS and CME are
good examples). Neither is a good fit any more for EMF, GEF, and XSD. The
Eclipse project provides a "platform for the develpment of highly integrated
tools". In particular, Eclipse Platform is for "common services required by
most tool builders". I'm not sure about "most" but "many" is becoming true
for EMF, GEF, and XSD.
Pro#3. In the past it has been challenging to get the right versions of
these three projects, especially during the times of Integration and
Milestone builds. You have to carefully check the prereqs and get the exact
version needed. This is a major hassle for users as you can tell from
looking at the newsgroup posts. Having them be part of the SDK would
eliminate the problem.
Pro#4. If multiple projects require different versions of the EMF, GEF, and
XSD, that is going to cause a problem if you try to use them at the same
time. Having them in Platform would synchronize their versions and build
schedules.
I can think of these arguments against doing it, but obviously I think the
Pros outweigh the Cons:
Con#1. EMF, GEF, and XSD are all done by different teams than the current
Platform team. This could lead to some organizational problems.
(Counterargument: Platform is already geographicly diverse and I think they
could handle it).
Con#2. The logistics of integrating the builds and plans could be difficult
to overcome. (Counterargument: These logistics are already being duplicated
for the individual projects now so maybe some of that effort could be
redirected into Platform).
Con#3. The Eclipse SDK download is already 85MB. This would make it about
110MB, putting additional strain on servers and bandwidth. (Counterargument:
there has already been some discussion of using update sites or something to
enable incremental installs rather than a big monolithic one, maybe this
would accelerate that process).
Con#4. The Platform is fairly focused now, and moving 3 new projects into it
might cause it to lose focus. (Counterargument: It's pretty diverse now with
Update and Help being fairly different from, say, Core. This is something
that should be discussed with the PMCs. One possibility is to have some be
under Platform and some be in sibling projects under the Eclipse project).
Anybody agree/disagree? Have arguments pro/con to add?
What is the right way to start a discussion about this with the PMCs and try
to get those projects migrated for 3.1? Is this post enough?
(*) Note VEP is also currently required by the IBM contribution. I haven't
investigated the VEP dependencies but I'm guessing it's because of the IBM
plug-ins that are in VEP that aren't yet open source so that will be a short
term requirement, not in the final WTP. Correct me if I'm wrong.
--
Ed Burnette, co-author, Eclipse in Action
www.manning.com/gallardo
www.eclipsepowered.org
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #144695 is a reply to message #144597] |
Tue, 27 July 2004 21:04  |
Eclipse User |
|
|
|
Originally posted by: andreynech.yahoo.com
Hi Ed,
Ed Burnette wrote:
[snip]
> - EMF SDK (Tools subproject)
> - GEF SDK (Tools subproject)
> - XSD SDK (Technology subproject)
>
> I believe it is time to put the last three in the Eclipse Platform project.
> In this post I'll lay out some Pros and Cons and then ask for more input and
> direction. Here are the Pros I can think of:
I am completely agree with your suggestion. In addition to your
arguments I would like to say that growing interest to the Model Driven
Development will probably increase the interest to the *combination* of
EMF and GEF. But unfortunately, EMF and GEF are not really integrated
with each other (please see "Integrating GEF editor in EMF editor"
thread for the example of difficulties integrating EMF with GEF). That
is why, if there are somebody who have time and enough knowledge about
EMF and GEF, I would suggest first to really integrate these two
projects and then put them in the Eclipse Platform project. I believe
that this step will increase the adoption of these two projects much
more than putting them in default Eclipse bundle (but again - I am
totally agree that this step is also necessary).
Regards,
Andrey.
|
|
| |
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #144841 is a reply to message #144717] |
Wed, 28 July 2004 13:30 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040808060309030708040204
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Yes, I agree. EMF and GEF are cool by themselves and are even cooler
in combination. And that combination could be significantly improved...
Sean Woodhouse wrote:
>+1 for me for the integration of these three projects into the Eclipse
>Platform project.
>
>I also think EMF and GEF should at the very least work better together. We
>spent a good chunk of time doing just that, and it seems to be a common
>story amongst other people on this list.
>
>Cheers
>
>Sean.
>
>"Andrey Nechypurenko" <andreynech@yahoo.com> wrote in message
>news:ce6fsn$40m$1@eclipse.org...
>
>
>>Hi Ed,
>>
>>Ed Burnette wrote:
>>
>>[snip]
>>
>>
>>
>>>- EMF SDK (Tools subproject)
>>>- GEF SDK (Tools subproject)
>>>- XSD SDK (Technology subproject)
>>>
>>>I believe it is time to put the last three in the Eclipse Platform
>>>
>>>
>project.
>
>
>>>In this post I'll lay out some Pros and Cons and then ask for more input
>>>
>>>
>and
>
>
>>>direction. Here are the Pros I can think of:
>>>
>>>
>>I am completely agree with your suggestion. In addition to your
>>arguments I would like to say that growing interest to the Model Driven
>>Development will probably increase the interest to the *combination* of
>>EMF and GEF. But unfortunately, EMF and GEF are not really integrated
>>with each other (please see "Integrating GEF editor in EMF editor"
>>thread for the example of difficulties integrating EMF with GEF). That
>>is why, if there are somebody who have time and enough knowledge about
>>EMF and GEF, I would suggest first to really integrate these two
>>projects and then put them in the Eclipse Platform project. I believe
>>that this step will increase the adoption of these two projects much
>>more than putting them in default Eclipse bundle (but again - I am
>>totally agree that this step is also necessary).
>>
>>
>>Regards,
>>Andrey.
>>
>>
>
>
>
>
--------------040808060309030708040204
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Yes, I agree. EMF and GEF are cool by themselves and are even cooler
in combination. And that combination could be significantly improved...<br>
<br>
<br>
Sean Woodhouse wrote:<br>
<blockquote cite="midce6prj$hh7$1@eclipse.org" type="cite">
<pre wrap="">+1 for me for the integration of these three projects into the Eclipse
Platform project.
I also think EMF and GEF should at the very least work better together. We
spent a good chunk of time doing just that, and it seems to be a common
story amongst other people on this list.
Cheers
Sean.
"Andrey Nechypurenko" <a class="moz-txt-link-rfc2396E" href="mailto:andreynech@yahoo.com"><andreynech@yahoo.com></a> wrote in message
<a class="moz-txt-link-freetext" href="news:ce6fsn$40m$1@eclipse.org">news:ce6fsn$40m$1@eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Hi Ed,
Ed Burnette wrote:
[snip]
</pre>
<blockquote type="cite">
<pre wrap="">- EMF SDK (Tools subproject)
- GEF SDK (Tools subproject)
- XSD SDK (Technology subproject)
I believe it is time to put the last three in the Eclipse Platform
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->project.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">In this post I'll lay out some Pros and Cons and then ask for more input
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->and
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">direction. Here are the Pros I can think of:
</pre>
</blockquote>
<pre wrap="">I am completely agree with your suggestion. In addition to your
arguments I would like to say that growing interest to the Model Driven
Development will probably increase the interest to the *combination* of
EMF and GEF. But unfortunately, EMF and GEF are not really integrated
with each other (please see "Integrating GEF editor in EMF editor"
thread for the example of difficulties integrating EMF with GEF). That
is why, if there are somebody who have time and enough knowledge about
EMF and GEF, I would suggest first to really integrate these two
projects and then put them in the Eclipse Platform project. I believe
that this step will increase the adoption of these two projects much
more than putting them in default Eclipse bundle (but again - I am
totally agree that this step is also necessary).
Regards,
Andrey.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------040808060309030708040204--
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #144857 is a reply to message #144717] |
Wed, 28 July 2004 13:41 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
I have written a GEF application before based on EMF and didn't have much
difficulty. The notification mechanism is a bit tricky at first. What
problems are you are experiencing? Are you perhaps using EMF.Edit also?
There was a 3.0 [plan item] bugzilla for putting commands and CommandStack
into the platform. But it got deferred yet again. CC yourself to the
bugzilla.
"Sean Woodhouse" <swoodhouse@agentissoftware.com> wrote in message
news:ce6prj$hh7$1@eclipse.org...
> +1 for me for the integration of these three projects into the Eclipse
> Platform project.
>
> I also think EMF and GEF should at the very least work better together. We
> spent a good chunk of time doing just that, and it seems to be a common
> story amongst other people on this list.
>
> Cheers
>
> Sean.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #144956 is a reply to message #144857] |
Wed, 28 July 2004 14:52 |
| Eclipse User |
|
|
|
Originally posted by: andreynech.yahoo.com
Randy Hudson wrote:
> I have written a GEF application before based on EMF and didn't have much
> difficulty. The notification mechanism is a bit tricky at first. What
> problems are you are experiencing? Are you perhaps using EMF.Edit also?
Yes the most problems were from EMF.Edit side and notification
mechanism. I was trying to use as much of generated implementation as
possible. For example the set of ItemProviderAdapter based classes to
display properties, context menus, etc. I was trying simply to add
GEF-based graphical editor page to those ones generated by EMF and
*reuse* all these property editors, popup menus, actions, etc. It was
hard in particular while EMF.Edit providers implementing
IItemPropertySource in contrast to IPropertySource used by GEF. There
are also org.eclipse.emf.edit.domain.EditingDomain vs.
org.eclipse.gef.EditDomain and so on. So finally I simply gave up and
implement GEF-editor as a separate plugin using EMF only (without
EMF.edit) which is not really the best way to go.
Regards,
Andrey.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #144972 is a reply to message #144695] |
Wed, 28 July 2004 14:45 |
Frank Budinsky
Messages: 478
Registered: July 2009 |
Senior Member |
|
|
Folks,
First of all let me say that we are painfully aware of both of these
issues - poor GEF/EMF integration and the tool/technology project status
of the three projects. We've actually always planned for these projects
to be part of the platform some day, it was just a matter of time. They
were initially added as tools/technology projects so that we could avoid
process and red tape and get them up and running quickly. The plan was
that once they were established and successful, they could be promoted
to the platform. As Ed pointed out in his list of pros, they are basic
enabling functionality and therefore well suited for the platform.
Regarding the EMF/GEF integration problem, there has been some ongoing
prototyping work to make them work together. This even includes support
for generating GEF views in a generated EMF editor. However, as anyone
that has tried to do something like this manually will know, the first
and biggest problem is the fact that EMF and GEF both have their own
command framework. People have tired various synchronization techniques
to make them work together, but the best solution would be to have one
command framework in the platform that both frameworks would use. Moving
both EMF and GEF to the platform would certainly force that issue.
So, to summarize, we need a couple of things to happen if we think the
time is now right to promote these projects to the platform:
1) we need to make the proposal to the Eclipse Board/PMC - and then
follow through the process.
2) we'll need to clean up a few things (like the GEF/EMF incompatibilities)
Personally I agree that the time is right, but I'm just one vote :-)
Frank Budinsky, EMF Project Lead (for those who didn't know that)
Andrey Nechypurenko wrote:
> Hi Ed,
>
> Ed Burnette wrote:
>
> [snip]
>
>> - EMF SDK (Tools subproject)
>> - GEF SDK (Tools subproject)
>> - XSD SDK (Technology subproject)
>>
>> I believe it is time to put the last three in the Eclipse Platform
>> project.
>> In this post I'll lay out some Pros and Cons and then ask for more
>> input and
>> direction. Here are the Pros I can think of:
>
>
> I am completely agree with your suggestion. In addition to your
> arguments I would like to say that growing interest to the Model
> Driven Development will probably increase the interest to the
> *combination* of EMF and GEF. But unfortunately, EMF and GEF are not
> really integrated with each other (please see "Integrating GEF editor
> in EMF editor" thread for the example of difficulties integrating EMF
> with GEF). That is why, if there are somebody who have time and enough
> knowledge about EMF and GEF, I would suggest first to really integrate
> these two projects and then put them in the Eclipse Platform project.
> I believe that this step will increase the adoption of these two
> projects much more than putting them in default Eclipse bundle (but
> again - I am totally agree that this step is also necessary).
>
>
> Regards,
> Andrey.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #145019 is a reply to message #144956] |
Wed, 28 July 2004 18:19 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
"Andrey Nechypurenko" <andreynech@yahoo.com> wrote in message
news:ce8efc$7pa$1@eclipse.org...
> Randy Hudson wrote:
> Yes the most problems were from EMF.Edit side and notification
> mechanism. I was trying to use as much of generated implementation as
> possible. For example the set of ItemProviderAdapter based classes to
> display properties, context menus, etc. I was trying simply to add
> GEF-based graphical editor page to those ones generated by EMF and
> *reuse* all these property editors, popup menus, actions, etc. It was
> hard in particular while EMF.Edit providers implementing
> IItemPropertySource in contrast to IPropertySource used by GEF. There
IPropertySource is used by Eclipse, not GEF. EMF is "rewrapping the wheel".
> are also org.eclipse.emf.edit.domain.EditingDomain vs.
> org.eclipse.gef.EditDomain and so on. So finally I simply gave up and
Ignore the fact that the names are the same. I dont' think the classes
overlap. GEF's EditingDomain is a collection of EditPartViewers, and active
tool, and a command stack (we're all aware of the issues with the last one).
But, assuming the command stacks were the same, you simple share the same
stack across both "domains".
> implement GEF-editor as a separate plugin using EMF only (without
> EMF.edit) which is not really the best way to go.
Why is that?
> Regards,
> Andrey.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #145055 is a reply to message #144972] |
Wed, 28 July 2004 23:47 |
Sean Woodhouse
Messages: 45
Registered: July 2009 |
Member |
|
|
Well, I think you can count another 5 from this thread. How many do you
need? ;-)
Sean.
"Frank Budinsky" <frankb@ca.ibm.com> wrote in message
news:ce8ep2$8gp$1@eclipse.org...
> Folks,
>
> First of all let me say that we are painfully aware of both of these
> issues - poor GEF/EMF integration and the tool/technology project status
> of the three projects. We've actually always planned for these projects
> to be part of the platform some day, it was just a matter of time. They
> were initially added as tools/technology projects so that we could avoid
> process and red tape and get them up and running quickly. The plan was
> that once they were established and successful, they could be promoted
> to the platform. As Ed pointed out in his list of pros, they are basic
> enabling functionality and therefore well suited for the platform.
>
> Regarding the EMF/GEF integration problem, there has been some ongoing
> prototyping work to make them work together. This even includes support
> for generating GEF views in a generated EMF editor. However, as anyone
> that has tried to do something like this manually will know, the first
> and biggest problem is the fact that EMF and GEF both have their own
> command framework. People have tired various synchronization techniques
> to make them work together, but the best solution would be to have one
> command framework in the platform that both frameworks would use. Moving
> both EMF and GEF to the platform would certainly force that issue.
>
> So, to summarize, we need a couple of things to happen if we think the
> time is now right to promote these projects to the platform:
>
> 1) we need to make the proposal to the Eclipse Board/PMC - and then
> follow through the process.
> 2) we'll need to clean up a few things (like the GEF/EMF
incompatibilities)
>
> Personally I agree that the time is right, but I'm just one vote :-)
>
> Frank Budinsky, EMF Project Lead (for those who didn't know that)
>
>
> Andrey Nechypurenko wrote:
>
> > Hi Ed,
> >
> > Ed Burnette wrote:
> >
> > [snip]
> >
> >> - EMF SDK (Tools subproject)
> >> - GEF SDK (Tools subproject)
> >> - XSD SDK (Technology subproject)
> >>
> >> I believe it is time to put the last three in the Eclipse Platform
> >> project.
> >> In this post I'll lay out some Pros and Cons and then ask for more
> >> input and
> >> direction. Here are the Pros I can think of:
> >
> >
> > I am completely agree with your suggestion. In addition to your
> > arguments I would like to say that growing interest to the Model
> > Driven Development will probably increase the interest to the
> > *combination* of EMF and GEF. But unfortunately, EMF and GEF are not
> > really integrated with each other (please see "Integrating GEF editor
> > in EMF editor" thread for the example of difficulties integrating EMF
> > with GEF). That is why, if there are somebody who have time and enough
> > knowledge about EMF and GEF, I would suggest first to really integrate
> > these two projects and then put them in the Eclipse Platform project.
> > I believe that this step will increase the adoption of these two
> > projects much more than putting them in default Eclipse bundle (but
> > again - I am totally agree that this step is also necessary).
> >
> >
> > Regards,
> > Andrey.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #145478 is a reply to message #145019] |
Thu, 29 July 2004 13:21 |
Marcelo Paternostro
Messages: 602
Registered: July 2009 |
Senior Member |
|
|
Comments below.
Cheers,
Marcelo.
"Randy Hudson" <none@us.ibm.com> wrote in message
news:ce8qk2$vac$1@eclipse.org...
>
> "Andrey Nechypurenko" <andreynech@yahoo.com> wrote in message
> news:ce8efc$7pa$1@eclipse.org...
> > Randy Hudson wrote:
>
> > Yes the most problems were from EMF.Edit side and notification
> > mechanism. I was trying to use as much of generated implementation as
> > possible. For example the set of ItemProviderAdapter based classes to
> > display properties, context menus, etc. I was trying simply to add
> > GEF-based graphical editor page to those ones generated by EMF and
> > *reuse* all these property editors, popup menus, actions, etc. It was
> > hard in particular while EMF.Edit providers implementing
> > IItemPropertySource in contrast to IPropertySource used by GEF. There
>
> IPropertySource is used by Eclipse, not GEF. EMF is "rewrapping the
wheel".
>
Now that I am thinking about this, I guess we've just created something...
Let's call it "tire"! :-P
> > are also org.eclipse.emf.edit.domain.EditingDomain vs.
> > org.eclipse.gef.EditDomain and so on. So finally I simply gave up and
>
> Ignore the fact that the names are the same. I dont' think the classes
> overlap. GEF's EditingDomain is a collection of EditPartViewers, and
active
> tool, and a command stack (we're all aware of the issues with the last
one).
> But, assuming the command stacks were the same, you simple share the same
> stack across both "domains".
>
If GEF & EMF end up in the Eclipse core, I don't believe we will be able to
ignore that we are using the same name for different things.
> > implement GEF-editor as a separate plugin using EMF only (without
> > EMF.edit) which is not really the best way to go.
>
> Why is that?
>
Because most of the users are interested on the benefits provided by the
EMF.edit framework. Besides this, EMF.edit was designed to be a bridge
between any UI and the modeled domain so probably it should be considered
when discussing using GEF to represent/manipulate EMF models.
> > Regards,
> > Andrey.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #145854 is a reply to message #145019] |
Fri, 30 July 2004 16:08 |
| Eclipse User |
|
|
|
Originally posted by: andreynech.yahoo.com
Hi Randy,
>>implement GEF-editor as a separate plugin using EMF only (without
>>EMF.edit) which is not really the best way to go.
>
>
> Why is that?
As Marcelo already mentioned, because EMF.edit framework supposed to
serve as the basis for custom editors (at least this is my
understanding). And in case of GEF it does not work and as a result
there is a need to manualy duplicate the generated code to achieve the
same functionality integrated with GEF.
Regards,
Andrey.
|
|
|
Goto Forum:
Current Time: Thu Apr 25 06:19:14 GMT 2024
Powered by FUDForum. Page generated in 0.04446 seconds |
] 
Search
Help
Register
Login
Home
