[pde-ui-dev] Re: PDE Road Map - Development Models

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Scott, 

This was forwarded to me as I don't
normally read the PDE list (I do now)...  I'll try to outline the
direction here and point you at the vaporware articles that we are writing
this month for more details...

0) a meta/philisophical point.  We
really don't distinguish between plugins and bundles.  To the runtime
they are the same thing.  It happens that some have manifest.mfs and
some have plugin.xmls.  In the end the runtime autogens manifest.mf
files if needed so everything looks the same (to the runtime).  Users
should feel largely the same way... (now on with the answers)

1) There are no particular benefits
of using plugin.xml over manifest.mf or vice versa.  For Eclipse 3.0
we propose that people continue business as usual (i.e., use plugin.xml)
unless something forces the issue.  What could force it?  There
are certain runtime controls that are only available through the manifest.mf
file (e.g., Import-Package).  If you are in a situation where the
only way to get a class/package on your classpath is to use Import-Package,
then you will need to spec a manifest.mf rather than a plugin.xml.  These
cases are relatively rare and we are seeking to make them even more so.
 I expect that by 3.0 release they will be mostly eliminated.

Having said that, the long term direction
is to move the runtime information (e.g., prerequisite specifications,
library declarations, ...) out of the plugin.xml and into the manifest.mf.
 This shift is not on for 3.0.

2) Not quite sure what you are getting
at here but will stab.  There really are only two downsides I can
see with not embracing the manifest.mf approach.
a) plugins which supply only a plugin.xml
will have a manifest.mf generated for them by the runtime on first startup.
 This is a modest amount of overhead but overhead none the less.
b) certain capabilities (typically more
direct use of OSGi function) will not be available to you as outlined in
#1.

3) This is a good question.  Currently
we do not plan on doing this.  There is an off chance that we will
include manifest.mfs for all the plugins to eliminate some of the startup
overhead and to help with some other optimizations but the jury is still
out on the impact.

4) I'm not the right guy to answer this.

In the above answers I have assumed
that you characterize bundle vs. plugin relative to the form of the manifest
file (plugin.xml vs manifest.mf).  Let me know if that is off base.

Jeff

Scott Fairbrother <scottf@xxxxxxxxxx>
Sent by: pde-ui-dev-admin@xxxxxxxxxxx

01/07/2004 12:57 PM

Please respond to
pde-ui-dev

To	pde-ui-dev@xxxxxxxxxxx
cc
Subject	[pde-ui-dev] PDE Road Map - Development Models

1.      What
are the concrete benefits or motivation for plug-in developers to follow
a path of bundle development, starting anew (clean) or to port existing
plug-ins?  
2.      What
is the down side of not porting existing plug-in projects to clean or mixed
mode projects?  
3.      Should
we expect to see all the plug-ins in the Eclipse SDK ported to bundles?
4.       Will
there be a manifest editor for bundle project development and in what milestone?
        
  
Thanks, 
Scott Fairbrother

Thanks,
Scott Fairbrother
Eclipse/WebSphere Studio Jumpstart Team
N110/501
IBM Corp 
4205 South Miami Blvd.
RTP, NC 27709
Voice : 919-254-1488
TL : 8-444-1488

The Java Developer's Guide to Eclipse - http://www.aw.com/catalog/academic/product/1,4096,0321159640,00.html?type=PRE
WebSphere Studio - http://www.ibm.com/software/ad/adstudio
Ready for WebSphere Studio partner program - http://www.developer.ibm.com/websphere/ready.html