Re: Suggestion: add Eclipse-UnpackBundlle: to manifest

+1

This would solve a problem we have worried about and improve the
development scoping.  Although it is certainly a 'best practice' to
construct one's plugin for deployment both packed or unpacked, the fact is
that it is not a hard requirement to support both models.   The feature
developer should not be dictating this over the plugin developer since the
latter may not be able to support the mode the feature developer imposes '
after the fact'.  The correct model is that the setting in the feature.xml
should be considered a feature level preference, but it should defer to the
requirements of the plugin.  The suggestion below gives us a path toward
this correct model.

"Alex Blewitt" <alex.blewitt-Re5JQEeQqe8AvxtiuMwx3w@xxxxxxxxxxxxxxxx> wrote on 
03/26/2006 12:00:07 PM:

> I'd like to propose an addition of Eclipse-UnpackBundle: to the
> Manfest.MF, in much the same way that Eclipse-AutoStart: is a
> documented entry in the manifest.
>
> The purpose would be to describe whether the bundle should be unpacked
> during installation, or left as a packed Jar file.
>
> Currently, the update manager determines whether a plugin/bundle
> should be unpacked based on an entry in its corresponding feature.xml.
> However, for bundles that are commonly shared between deployments
> (e.g. something like org.apache.log4j) it would be efficient to store
> this information in one place rather than many, since whether a bundle
> should be unpacked or not is a function of the bundle itself rather
> than the feature that hosts it.
>
> Since this entry would be unused at this time, perhaps it would be
> best described as a hint to the underlying platform rather than a
> mandatory entry. However, the PDE tooling could subsequently be
> updated to ensure that the feature.xml and bundle are in step with
> these values. Once the adoption becomes more widespread, an update
> manager that utilises this property would be able to install bundles
> and know whether to unpack them or not regardless of the feature(s)
> that they were associated with.
>