Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse.org-architecture-council] input to the Eclipse architecture
I like Wenfeng's idea about the structuring the Eclipse architecture pictures according to the use scenarios.
 
This picture below (from an old Eclise architecture document) is a start into the direction that Wenfeng has elaborated.
The interdependencies in the development tools sector are documented much better in the previous mails - but this picture is one good start anyway.
 
 
 
 
I am just wondering
- if there is use for Eclipse in additional use scenarios that we would like to highlight in our architecture documents
- if we should list the data formats (file structures) produced and used by Eclipse tools; the data representation formats (and the tools making conversions between these formats) are often documented in the architectural documents
- if we should anchor our Eclipse architecture council releases to Eclipse platform releases so that we would have clear targets for our work; our target would be to document (and plan) the architecture of eclipse releases 
 
Kai
 
 
-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx]On Behalf Of ext Wenfeng Li
Sent: 11 October, 2005 21:51
To: eclipse.org-architecture-council
Subject: [eclipse.org-architecture-council] input to the Eclipse architecture

Sorry I am late on the task, I need to drive to work after the conf call.  Following is my input to the components and layers...
 
A. Components to be reused in both desktop/designer environment and web/deployment environment:
  • OSGi
  • EMF
  • DTP/Model, DTP/Connectivity/ODA
  • BIRT/model, BIRT/report engine/chart engine
  • WTP/XML and WS runtime components, WTP/wst-server, WTP/jst-server components
  • TPTP/agents ...
 
B. Components to be reused in desktop/designer environment.
  • SWT
  • JSF
  • Help
  • Update
  • RCP
  • VE
  • Workbench
  • GEF
 
 
C.  Tools to be integrated in various designer applications (such as Java IDE, C/C++ IDE, Embedded App IDE, Web App IDE, Report IDE, test and performance IDE, Database admin tool, etc..)
  • ANT
  • JDT
  • Debug
  • CDT
  • WTP/JSP, _javascript_, HTML, XML editors.  WTP/app server adaptors.
  • DTP/SQL editor/query builder
  • BIRT/Reprot designer, Chart builder.
  • PDE
  • Team framework
Possible Dependency:  C --> B --> A
 
Started at 11 PST, with a couple of interruptions by people knocking on the door.  This is my 50 min. input.
 
Wenfeng
 
 
-----Original Message-----
From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx]On Behalf Of Bjorn Freeman-Benson
Sent: Tuesday, October 11, 2005 9:08 AM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Subject: [eclipse.org-architecture-council] Bjorn's view of the Eclipsearchitecture

(It was sooo tempting to return to my email or to make phone calls, but I said I'd do this so here it is...)

Major Eclipse Platform components:
  • OSGi plug-in loader
  • Ant
  • Update
  • Resource model including IWorkspace and IProject
  • Workbench User Interface including menus, editors, views, wizards, etc.
  • JDT Compiler and in-memory model
  • JDT User Interface (editors, views, wizards, debugger, etc)
  • Debug Framework
  • Team Framework including compare/difference engine and user interface
  • CVS Team Tools
  • PDE
  • Widgets (SWT and JFace)
  • Help System
We can use an automated tool to determine what the dependencies between the these components are. I'm playing around with Lattix for this purpose.  It doesn't break up as cleanly as I would like (the upper diagonal numbers are dependencies that violate my component structure):

Part of my problem is that I started from package names and the Platform has ui code mixed with core code under the same high level package, e.g., org.eclipse.foo.internal.ui... and org.eclipse.foo.internal... so I have to go through and separate out each of the dependent pieces.  I'm not complaining, I'm just stating that the packaging naming does not exactly match my idea of how the components are laid out.

Clearly there is a layout of the components that works or Eclipse couldn't load, so perhaps I should start from the plug-ins rather than the package names...

Anyway, my 30 minutes is up, so here's my input...
Bjorn

Back to the top