Re: Re: Suggestion: add Eclipse-UnpackBundlle: to manifest

 Yes, I agree that you want the plugins to be packed. However, having
an entry in the bundle itself allows any update manager to know
whether the plugin's intention is to be packed or unpacked.

I thought David's point was that there's a combination of feature and
bundle specifiers:

1) feature: unpacked, bundle: packed
2) feature: unpacked, bundle: unpacked
3) feature: packed, bundle: packed
4) feature: packed, bundle: unpacked

(in this case, feature: packed means that the feature contains a
bundle, and as far as the feature is concerned, it's designed to be
packed)

2) and 3) are fine, because they agree. (Tooling should probably
check/suggest for this; if the classpath contains '.' in
Bundle-Classpath, it should probably hint for it to be packed)

4) is probably not going to work, since the bundle demands that it
should be unpacked for a reason. It's probably best to use the bundle
declaration in preference.

1) is the case that David was talking about. On the assumption that
any packed bundle can run as an unpacked bundle (though it's less
efficient to do so) the feature is asking for the bundle to be
unpacked. So, should the bundle's mandate be preferred (and it stays
packed) or should the bundle be unpacked as per the feature's request?
This is the only time that it's an issue, since 2 & 3 are OK and 4
probably has no options as to the correct behaviour.

I'm all for making the bundle's spec the required one, if it exists.
The tooling can then warn out-of-date features that they have the
wrong entry, as would be the case for 4.

Alex.

PS There might be reasons for wanting to unpack a bundle, if (for
example) it's going to be on a CD or a network share, where random
accesses to individual files might be faster than loading from a Jar.