Home » Language IDEs » ServerTools (WTP) » 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 #32948] |
Tue, 27 July 2004 11:01  |
Eclipse User |
|
|
|
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 #33021 is a reply to message #32948] |
Tue, 27 July 2004 11:23  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Ed,
I tend to agree. I think the pros do outweigh the cons. We'll
definitely follow up on this isse in the coming weeks. We've been
intending to move XSD from technology to tools, since it's well used and
some tools projects already depend on it. We should also discuss
inclusion in the platform and improved integration with GEF while we are
at it.
Ed Burnette wrote:
>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.
>
>
>
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #33058 is a reply to message #32948] |
Tue, 27 July 2004 11:42 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Ed,
I tend to agree. I think the pros do outweigh the cons. We'll
definitely follow up on this isse in the coming weeks. We've been
intending to move XSD from technology to tools, since it's well used and
some tools projects already depend on it. We should also discuss
inclusion in the platform and improved integration with GEF while we are
at it.
(Again, sorry if this appears multiple times. Messages seem to be going
missing.)
Ed Burnette wrote:
>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.
>
>
>
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #33093 is a reply to message #33058] |
Tue, 27 July 2004 13:16 |
| Eclipse User |
|
|
|
Originally posted by: anuj.andale.com
My 2 cents :
1. At least club-together EMF, GEF, XSD, SDO
Downloading all of them from all over the place was quiet a nuisance.
IDE's are meant to be userf-friendly at the core. I will love to build some
eclipse plugin one-day, but it turned out that unless I learn a number of
how-to's on plugins, I couldnt get started.
2. Have a better mechanism for defining pre-requisites and/or their
availability.
I could do with some greps and all, but the status of plugins shouldnt
show "Configured properly"
if there are missing dependencies. Also any failures to load a plugin should
be reported cleanly.
-anuj
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:ce5t2b$2od$1@eclipse.org...
> Ed,
>
> I tend to agree. I think the pros do outweigh the cons. We'll definitely
> follow up on this isse in the coming weeks. We've been intending to move
> XSD from technology to tools, since it's well used and some tools projects
> already depend on it. We should also discuss inclusion in the platform
> and improved integration with GEF while we are at it.
>
> (Again, sorry if this appears multiple times. Messages seem to be going
> missing.)
>
>
> Ed Burnette wrote:
>
>>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.
>>
>>
|
|
| |
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #33464 is a reply to message #33199] |
Tue, 27 July 2004 22:42 |
| Eclipse User |
|
|
|
"Ed Willink" <ed@willink.me.uk> wrote in message
news:ce68mt$mtt$1@eclipse.org...
> There is a case for:
>
> Eclipse project = Platform + JDT + PDE + (EMF+XSD)
>
> with XSD being absorbed into EMF.
> and possibly
>
> Eclipse project = Platform + JDT + PDE + (EMF+XSD) + GEF
>
> but neither is part of Platform.
If you read the charter for the Eclipse top level project and the Platform
project a case can be made for EMF, XSD, and GEF being subprojects under
Eclipse or components under the Platform subproject.
The Platform subproject says: 'The Platform defines the set of frameworks
and common services that collectively make up "integration-ware" required to
support a comprehensive tool integration platform. These services and
frameworks represent the common facilities required by most tool builders
including a standard workbench user interface and project model for managing
resources, portable native widget and user interface libraries, automatic
resource delta management for incremental compilers and builders,
language-independent debug infrastructure, and infrastructure for
distributed multi-user versioned resource management.'
EMF's description says: 'EMF is a modeling framework and code generation
facility for building tools and other applications based on a structured
data model.'.
So if you go by these charters then logically EMF (and by association, XSD)
would be a good fit in the Platform subproject. Logistically I could
understand if the PMCs wanted to have some new subproject under the Eclipse
project to split up Platform type components. Maybe, say, a Modeling
subproject. That's up to them.
GEF's description says it 'allows developers to create a rich graphical
editor from an existing application model. GEF uses the SWT-based drawing
plugin Draw2d to create a graphical environment within Eclipse. The
developer can then take advantage of the many common operations provided in
GEF and/or extend them for the specific domain. GEF employs an MVC
(model-view-controller) architecture which enables simple changes to be
applied to the model from the view.'
The Draw2d component clearly is a low level companion to SWT and so
logically I think it should belong in the Platform subproject. The GEF
(modeling) component I'm not as sure about. Again these details would be
worked out by the PMCs.
Looking beyond the exact details, what I'm saying is that it doesn't make
sense to me for these three projects (EMF, GEF, and XSD) to remain where
they are now and some reorganization should be considered so that the
versions can be aligned and they can be included in the SDK.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #33768 is a reply to message #32948] |
Wed, 28 July 2004 04:08 |
| Eclipse User |
|
|
|
Originally posted by: eostroukhov.hotmail.com
I disagree - if moving it into the Eclipse platform project implies simple
adding it to the eclipse SDK download and synchronizing release schedules.
I do think that the Eclipse platform is too monolitic - we have Eclipse text
framework, generic workbench, workspace, forms, JFace, SWT and other
frameworks - and the number is growing.
I think that what the tool builders need is a more finegrained definition of
these frameworks and the relations between them. The problems we had in our
project is finding the minimum set of the platform plugins we need to run
the application - at the start it is as simple as taking the platform
distribution and adding GEF runtime and our application runtime - but then
we have tough time removing update/text/resource framework plugins one by
one with the mandatory restart to see what the plugins are actually needed.
While I do think adding GEF/EMF/XSD to the platform could be beneficial if:
1. Platform frameworks (update/resource/text) are clearly separated and made
separate at the level GEF and EMF is. Platform must know how to download
these frameworks when the plugin is installed that needs one. BTW, sometimes
I get a feeling that the platform needs to distinguish between frameworks
and plugins - some projects built on GEF might not want to see the palette
view in the list of views - but the GEF plugin adds it there.
2. Platform will be refactored. I.e., we need single command infrastructure
that will work with all Eclipse frameworks (common command stack will allow
building multitab editors that are based on different framewors - like
source editor and GEF editor)
Eugene
"Ed Burnette" <ed.burnette@sas.com> wrote in message
news:ce5ql7$to8$1@eclipse.org...
> 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 #33836 is a reply to message #32948] |
Wed, 28 July 2004 04:56 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.com
sorry, i'm not a platform developer, but i can see another possible
advantage:
Pro#5. platform development itself could make usage of the mentioned
tools to make its own models easier to manage and use.
cheers
/eike
On Tue, 27 Jul 2004 11:01:31 -0400, "Ed Burnette"
<ed.burnette@sas.com> wrote:
>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.
|
|
|
| Re: Idea for addressing the prerequisites problem - move EMF, GEF, and XSD to Platform [message #34548 is a reply to message #32948] |
Thu, 29 July 2004 13:12 |
| Eclipse User |
|
|
|
Cons#5:
The release schedule will be limited by the slowest maturing technology.
The more you integrate, the more you need to wait.
I personally don't want to rely on an intermediate / nighly build of the whole
platform to deliver apps to my clients: the platform should have a longer
lifetime than the applications.
Maybe the concept of an "Extended Platform" is the key:
Define and Release a more integrated EMF/GEF/XXX bundle besides the core platform.
This should also help, even as a transitional step, manage the resources, while
creating the required synergies.
--
Christophe
|
|
|
Goto Forum:
Current Time: Thu Jul 03 20:26:05 EDT 2025
Powered by FUDForum. Page generated in 0.04889 seconds |
Home