Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Top Ten Architectural Problems in all of Eclipse
This page is stale, and represents only some initial ideas expressed in 2006 and not fully fleshed out. Some of these issues are no longer applicable or no longer critical. For example Eclipse now supports source plugins rather than source features, and several enhancments have been made to better support nested projects. Take what you read here with a grain of salt. Volunteers to update the document are welcome.
Introduction and Purpose of this Document
Ok, maybe more, maybe less than 10, but the purpose of this page is for AC members to begin to articulate what we as a group think the architectural problems are in Eclipse. At first, this page will have a form of "online brainstorming" ... anything can be listed ... but over the next few weeks, we'll polish, refine, categorize and abstract issue to the "root" problem. Then, during the January meeting, we'll discuss them more and priorities them and hopefully get commitments from within our group to work on them.
At our 12/14/2006 phone meeting, we agreed that Eclipse Architectural Problems were:
- Some issue or difficulty (or, perhaps some opportunity) that spans more than 2 projects. Issues that exist between only two projects is not large enough to justify our investment in it, since presumably those two project could solve it themselves.
- It has to be a problem where the people or projects calling it a problem all agree that they would be willing to work on solving it -- in some capacity, documenting use cases, creating designs, reviews, tests, or, hopefully even code submitted in bugzilla as patches!
Top X Opportunities
- 'Source goes with plugins, not features.' Currently, "source" is associated with features, instead of the plugin they directly relate to. This is architecturally wrong and often complicates proper componentization. In the best case, if someone wanted to "recombine" plugins into new features, they have to create twice as many features, one for the code (runtime) and another for the SDK (source). Plus, one much needed user scenario is that someone should be able to install only the runtime of many features, but then as their interest and debugging needs change they should be able to say "just install the source for these 3 plugins that are causing me trouble ... not all 250". As it is now ... how many people would even know how to trace back which features those plugins came from, then which project, then go hunt up which SDKs they wanted, likely being forced to install much more than they really needed.
- What's an API? How should we (our projects) specify and test their API's and our use of others API's. There is currently, I think, several methods and several tools, some nicely built in to the PDE or JDT ... some built in to build processes. The strategy and details of these definitions seem uncoordinated and many are not well educated in their use.
- Java. The architecture and the concept of many projects and the platform is Java oriented. Is that right? shouldn't we make it more generic? Is it right that JDT is part of the basic Eclipse?
- Entire Eclipse architecture - relations, dependencies. We're missing that. Is it possible to create one big diagram that summarize it? This will give a new user/committer the opportunity to understand the big picture.
- The eclipse Project model and nested projects: when developers lay out the directory structure on non-eclipse projects, they often use a tree where some directories represent projects. Those projects are "nested". This is also often related to the way the files are stored in a configuration management system. Unfortunately eclipse does not really support this real-world setup [bug 35973]