Re: [platform-core-dev] Bundle of questions

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Ed, 

Sorry for the delay in responding.  We
have been updating the story and I didn't want to lie to you.

The porting guide is not yet updated
but the summary is that OSGi requires a JAR manifest (META-INF/MANIFEST.MF).
 This file contains all the information needed to construct the classloader
network for an OSGi bundle (aka Eclipse plugin).  As such, we are
moving the <runtime> and <requires> related info from plugin.xml
to MANIFEST.MF.   This leaves just the <extension> and <extension-point>
elements.  Note that both of these are the same flavour regardless
of whether they are from a plugin or a fragment.

With this in mind, we are moving the
<extension> and <extension-point> elements into a new file
called "eclipse.xml".  The top level element of this XML
file will be <eclipse> to leave room for future expansion as this
file really contains the Eclipse-specific portions of a plugin.  So,
yes, the plugin.xml and fragment.xml files are being deprecated for 3.0.

Similarly, the plugin.properties file
is being renamed "eclipse.properties".  It will continue
to hold the NL messages for both the MANIFEST.MF and the eclipse.xml.

As with the vast majority of the runtim
changes, 2.1 style plugins will continue to function and plugin.xml files
continue to be read.  

As for PDE tooling, of course we will
be maintaining our support for plugin developers.  I actually do not
expect too much change here in that the high level editor pages still show
the same sorts of relationships.  The only thing that has really changed
is the format of the stored data.  The source editor will of course
need to be updated.  I'm sure the PDE folks can give you more detail
there.

The new runtime does not force any particular
functional changes on Update/Install though it does open up a number of
possibilities.  Coincident with the runtime changes we are doing a
number of things to make Eclipse installs more configurable and flexible.
 You have seen the first steps on this with the move of the configuration
information out of the workspace.   A further part of this is some
work to separate branding issues from features.  This is still in
discussion but should solidify soon.  In any event, no regressions
or loss of function is expected.  RCP usecases are really driving
us to generalize and open things up to more possibilities.

Jeff

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: platform-core-dev-admin@xxxxxxxxxxx

12/01/2003 02:12 PM

Please respond to
platform-core-dev

To	<platform-core-dev@xxxxxxxxxxx>
cc
Subject	[platform-core-dev] Bundle of questions

The platform-core-home/runtime/adoption.html document
says:

"The OSGi specification mandates the use of manifest.mf files to define
the execution of a plug-in. This conflicts with the Eclipse notion of plugin.xml
as far as <runtime> and <requires> elements are concerned.
The easiest way to update your plugin.xml or fragment.xml is to use the
PDE Migration Tool (PDE Tools->Convert to OSGi bundle).

"Current build structures (e.g., PDE, custom builds done by product
teams, ...) are based on plug-ins, fragments and features. While the new
runtime supports these components, it is bundle based. To support existing
build structures we (and other bundle developers) must take care to include
plugin.xml and fragment.xml files (as appropriate) for all bundles.

"By maintaining the plugin.xml content, tooling and build mechanisms
will continue to function. As these are updated to handle the new structures,
the need to maintain plugin.xml and fragment.xml files will diminish."


Ignoring the compatability layer, the way I read this is that plugin.xml
and fragment.xml are being deprecated in favor of manifest.mf. Is this
correct? What is the plan for the PDE manifest editor - will it be changed
to edit manifest.mf instead of or in addition to plugin.xml for pure 3.0
and RCP applications? Can bundles be updated by an update site? Where does
branding info go in the new scheme?

Thanks,
--Ed
_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev