Thanks, Simon,
I've been trying to upgrade all my apps to use 2.4 in an attempt to
avoid any conflicts, but it looks like I was being too optimistic to
think that this was possible.
I'm still in the process of trying to get rid of older stuff, so I'll
hopefully have more information soon.
In a
The map file has been updated for the following Bug changes:
+ Bug 184283. Remove ServiceFactory code for StartLevel implementation
(FIXED)
+ Bug 185952. EnviromentInfo defaults ws to motif on solaris and linux
(FIXED)
+ Bug 187203. Define value for osgi.os for Symbian OS (Epoc32) (FIXED)
+ Bug 1
As more and more people are contributing to Equinox (Thanks!) we thought
it would make sense to point out the Equinox coding conventions:
http://www.eclipse.org/equinox/documents/coding.php
In some ways these sort of guidelines can show up as restricting one's
freedom of artistic code formattin
Maybe I have made a bad assumption here. I understand that IUs can be used
as simply a list of IUs. I like that. That fits in with what we need to do.
The problem that I am trying to resolve is how do we make a contract
between this IU object and our tooling. This appears to be the point tha
The intention is that the UI would be more general and could be used in
RCP apps.
To support this concept, most of the pieces actually live in
org.eclipse.equinox.prov.ui.
The sdk part is simply the plugin that registers the menu command, puts
the UI in a dialog, and uses the "feature" terminol