|Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #589897]
||Tue, 27 July 2004 15:01
| Ed Burnette
Registered: July 2009
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
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
Powered by FUDForum
. Page generated in 0.01753 seconds