Wednesday, May 10, 2006

The Road Ahead

Today, the topic of my weekly call with Jeff McAffer, Eclipse PMC and Equinox/RCP Lead, was 3.3 planning.

When planning for a release, we like to have high-impact items that are also fun to work on.

Here are some general ideas/themes that came up today in the very first session of PDE 3.3 planning.

In no particular order:

1. PDE having a broader mandate. Think beyond plug-ins. Think components.

2. Extreme Self-Hosting: Implement a Remote Agent that controls a running Eclipse/OSGi application. Test the dynamic behaviour of your plug-in and product. Update manifest files and see changes in the runtime workbench without restarting,...

3. Plug-in Dependency Visualization

4. OSGi/Runtime tooling, e.g. declarative services, new application model, and every etcetera in between.

5. Update Manager Tooling

6. User Assistance authoring tools (e.g. cheatsheets, context-sensitive help, tables of contents, ...)

I am soliciting opinions on this list.

How would you rate/prioritize this list?
Which item is your favourite?
Is there an item missing from the list that you would like to see addressed in 3.3?

If you have input on the subject matter, please send me an email.
My email address is wassimm at ca dot ibm dot com


zx said...

Did Mr. McAffer also budget the PDE team to grow by 3-fold to get these items done :)?

AlBlue said...

I think it's time to get rid of the separate features, and merge them in to become first-class bundles. The can still be called features (and the user interface need look no differently) but we can get rid of the implementation that has features depending on other features and including plugins, simply by changing those references to bundle dependencies.

That would make the update manager's job sweet; it wouldn't need to be restricted to just being able to update features. You could update any bundle, and have all of its dependencies updated as well.

See also my post on EclipseZone, and bug 126732. This kind of seismic shift needs to be planned early if it's to make it into an Eclipse build, because of the number of factors that this would hit.


Gunnar said...

That's my ranking:


I intend to work on PDE enhancements for RSP. So hopefully we can identify some worthwhile contributions for 3.3.

Abel MuiƱo said...

I would vote for #6. Plug-ins should be easy to use... which means easy to document by the author.

Ed Burnette said...

I think #5 update manager tooling should be at or near the top. I was trying to explain to somebody how to keep their plug-ins and eclipse install separate just yesterday and it was a major pain.

Anonymous said...

Is subversion support on your list?

Bull said...

I would also add tighter integration between JDT and PDE. For many new (and experienced programmers) UID for plugins and extension points cause a lot of problems. A misspelling of a UID in a plugin XML file, or in your java code can be a nightmare to debug. Context assist for these UIDs would be nice.

Anonymous said...

I think that helping out those nice Harmony folks has got to be a major priority :-)

Erik Bengtson said...

one more item for your list:

Plugins development should not force the plugin.xml to be hosted in root, neither other files like the schema or manifest files. It should allow in IDE configuring the place these files are located. However, when built the files goes where it should be as today.

This feature is quite important for allowing non eclipse plugins with same format to use the PDE tools to develop their plugins.

For example, I work in a JDO 2 implementation, JPOX, and it has extension points, but not for eclipse. The XSD files are eclipse like, and the PDE IDE tool allow us to develop plugins for JPOX.
The registry and loading of plugins is done by JPOX, since we dont use the OSGi. OSGi is too large for JPOX needs.

Another point of the idea, is that since JPOX and JPOX plugins are using the same format as eclipse, they are also eclipse plugins. It means, ready to be deployed as plugins for eclipse osgi apps.

The whole idea can be compared to App Server(Heavy) vs Spring(Light) and Eclipse(Heavy) vs Non managed by Eclipse(Light)