Home » General (non-technical) » Eclipse Foundation » Eclipse Roadmap Released!
|
| ENH: Links to definitions/external standards [message #16266 is a reply to message #16197] |
Thu, 03 March 2005 09:54   |
Eclipse User |
|
|
|
Originally posted by: markus.milleder.example.com
I have looked over the documents, and I find them quite informative.
However, there are several references to JSRs and some references to other
standards. For somebody not directly involved in the development of some
project these are quite uninformative.
So I'd like to ask that any reference to some standard be a link to a
short definition, and that this definition contain a link to the standard
itself.
|
|
|
| Re: Eclipse Roadmap Released! [message #16306 is a reply to message #16197] |
Thu, 03 March 2005 18:26 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Mike Milinkovich wrote:
> I am very happy to let everyone know that in yesterday's Board meeting
> version 1.0 of the Eclipse Roadmap was approved.
>
> You can read it here: http://www.eclipse.org/org/councils/roadmap.html
>
> If you are interested in a deep architectural dive on Eclipse today or where
> it is going in the future this is a "must read".
It's deep, all right. In fact, the "future Eclipse architecture view"
diagram is downright mystical. ;-}
The old diagram was oversimplified, like Modeling Frameworks and
Graphical Frameworks in the same level, as though either might depend on
the other.
The new diagram carries forward the same issues. Nobody looking at this
could imagine the huge grab-bag of feature content lumped under Project
Model. Editing, dialogs, a big chuck of JFace, etc., most of which seem
to have no earthly reason to be there except that once upon a time
Project Model was actually the root level of Eclipse.
Plus it adds new problems, like why are Multi-language Support and
Project Model in the same level? Why is Multi-language Support not in
the RCP?
And it's disappointing. Is there to be no extension to the RCP at all?
The RCP vision just talks about gilding the lillies that are already
there. How about migrating all of editing, most of JFace, etc. to the
RCP level where they belong?
But back to the diagram. What are those sandy-colored boxes at top,
which are supposedly "built on" Java Dev Tools, Test and Performance,
Web Tools, etc. But Java Dev Tools, etc. are not frameworks, they are
just things you can use on the road to building a Modeling Tool. So the
meaning of the chart as a software dependency model goes entirely out
the window. It seems more like a "30,000-feet" management overview.
Bob Foster
|
|
|
| Re: Eclipse Roadmap Released! [message #16347 is a reply to message #16306] |
Sat, 05 March 2005 17:05 |
 Mike Milinkovich
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
> It's deep, all right. In fact, the "future Eclipse architecture view"
> diagram is downright mystical. ;-}
Before I can explain the "future Eclipse architecture" it is important to
understand the disussion at the Architecture Council on the current Eclipse
architecture diagram.
Basically, we decided that a relatively simple, very high-level diagram was
what we wanted. We could have attempted to do something more technically
accurate, but the decision was that more detail or precision would result in
*less* information. So we freely admit that all of these high-level diagrams
can be criticized for various inaccuracies. But we do believe that they
impart a very important high-level view of how the various pieces in Eclipse
come together.
>
> The old diagram was oversimplified, like Modeling Frameworks and Graphical
> Frameworks in the same level, as though either might depend on the other.
That I don't quite understand :-). To my brain they look like peers. Or at
least that's what we meant to say. :-)
>
> The new diagram carries forward the same issues. Nobody looking at this
> could imagine the huge grab-bag of feature content lumped under Project
> Model. Editing, dialogs, a big chuck of JFace, etc., most of which seem to
> have no earthly reason to be there except that once upon a time Project
> Model was actually the root level of Eclipse.
Edit, JFace, etc. are in RCP. The list of "sub"-pieces shown under RCP is
not exhaustive
>
> Plus it adds new problems, like why are Multi-language Support and Project
> Model in the same level? Why is Multi-language Support not in the RCP?
Because Mulit-Language support is part of the Tools Platform, not the RCP.
RCP are the basic building blocks for building RCP applications. Anything
which is specific to IDE creation is in the Tools Platform. This is by
intent.
>
> And it's disappointing. Is there to be no extension to the RCP at all? The
> RCP vision just talks about gilding the lillies that are already there.
> How about migrating all of editing, most of JFace, etc. to the RCP level
> where they belong?
They are there. Well sort of. What do you mean by "all of editing"?
Language-specific editor features belong in the Tools Platform or in
JDT|CDT|*DT. Generic editing is part of the RCP.
>
> But back to the diagram. What are those sandy-colored boxes at top, which
> are supposedly "built on" Java Dev Tools, Test and Performance, Web Tools,
> etc. But Java Dev Tools, etc. are not frameworks, they are just things you
> can use on the road to building a Modeling Tool. So the meaning of the
> chart as a software dependency model goes entirely out the window. It
> seems more like a "30,000-feet" management overview.
Yep. That was exactly the intent.
But on the specifics of the sandy-colored boxes, the idea is not tha they
necessarily depend on JDT, CDT and the like. We ran out of horizontal space.
We don't actually know all of the dependencies at this point. Nor are we
even attempting to capture all of the dependencies. But for the roughest
level of interpretation, assume that they show that those boxes rely on the
Frameworks layer.
|
|
|
| Re: Eclipse Roadmap Released! [message #16373 is a reply to message #16347] |
Sat, 05 March 2005 19:49 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Hi Mike,
Thanks for the response. A few clarifications below.
Mike Milinkovich wrote:
>>It's deep, all right. In fact, the "future Eclipse architecture view"
>>diagram is downright mystical. ;-}
>
> Before I can explain the "future Eclipse architecture" it is important to
> understand the disussion at the Architecture Council on the current Eclipse
> architecture diagram.
>
> Basically, we decided that a relatively simple, very high-level diagram was
> what we wanted. We could have attempted to do something more technically
> accurate, but the decision was that more detail or precision would result in
> *less* information. So we freely admit that all of these high-level diagrams
> can be criticized for various inaccuracies. But we do believe that they
> impart a very important high-level view of how the various pieces in Eclipse
> come together.
>
>>The old diagram was oversimplified, like Modeling Frameworks and Graphical
>>Frameworks in the same level, as though either might depend on the other.
>
> That I don't quite understand :-). To my brain they look like peers. Or at
> least that's what we meant to say. :-)
JDT and CDT are peers. Note that they appear in separate modules. Things
that appear in the same module can have mutual interdependencies. In
fact, Modeling Frameworks do depend on Graphical Frameworks, but the
converse would be very surprising.
>>The new diagram carries forward the same issues. Nobody looking at this
>>could imagine the huge grab-bag of feature content lumped under Project
>>Model. Editing, dialogs, a big chuck of JFace, etc., most of which seem to
>>have no earthly reason to be there except that once upon a time Project
>>Model was actually the root level of Eclipse.
>
> Edit, JFace, etc. are in RCP. The list of "sub"-pieces shown under RCP is
> not exhaustive
No, actually most of Edit and JFace are not in RCP. There is just enough
for rudimentary text editing. Most of the good stuff is still in the IDE.
>>Plus it adds new problems, like why are Multi-language Support and Project
>>Model in the same level? Why is Multi-language Support not in the RCP?
>
> Because Mulit-Language support is part of the Tools Platform, not the RCP.
> RCP are the basic building blocks for building RCP applications. Anything
> which is specific to IDE creation is in the Tools Platform. This is by
> intent.
Having now heard the lofty Multi-language Support project ambitions at
EclipseCon, I see what you mean. That project is truly focused on making
it easier to drop all-singing, all-dancing JDT-quality support for new
languages into the IDE. The fact that much of this technology is
"generic" doesn't seem to be a factor in their thinking, and maybe it
shouldn't be.
>>And it's disappointing. Is there to be no extension to the RCP at all? The
>>RCP vision just talks about gilding the lillies that are already there.
>>How about migrating all of editing, most of JFace, etc. to the RCP level
>>where they belong?
>
> They are there. Well sort of. What do you mean by "all of editing"?
> Language-specific editor features belong in the Tools Platform or in
> JDT|CDT|*DT. Generic editing is part of the RCP.
Would that it were. There is nothing language-specific about showing
line numbers in files, displaying errors and error messages or
displaying quick-diff annotations about what changed in a file, but none
of these are in the RCP. There isn't anything language-specific about
text Search, but it's not in the RCP.
RCP needs more work, both to migrate more of the non-IDE-dependent
functionality down to its level and to shed more of its IDE-like
assumptions. For example, it's not supported to open a text editor
except in the blessed Editors view. This means that file Compare has to
make do with a very rudimentary editor. There are other like issues,
which are currently being attacked under the rubric of Components in the
Platform project. But there is certainly no intrinsic dependency of
Components on the IDE. The editor-related part of this project and the
basic component apparatus should be in the RCP.
In fact, every new project should ask the question, is this
intrinsically IDE/project model dependent? If no, it should be pushed
down in the architecture, where it will enrich both the IDE and the RCP
frameworks.
>>But back to the diagram. What are those sandy-colored boxes at top, which
>>are supposedly "built on" Java Dev Tools, Test and Performance, Web Tools,
>>etc. But Java Dev Tools, etc. are not frameworks, they are just things you
>>can use on the road to building a Modeling Tool. So the meaning of the
>>chart as a software dependency model goes entirely out the window. It
>>seems more like a "30,000-feet" management overview.
>
> Yep. That was exactly the intent.
Well, then, it works. ;-}
Bob
|
|
|
Goto Forum:
Current Time: Fri Apr 19 18:19:46 GMT 2024
Powered by FUDForum. Page generated in 0.03159 seconds |
] 
Search
Help
Register
Login
Home
