yes, this is an interesting direction.
Looking at this a bit more generally there has been discussion of
"overrides". Under this model, the producer of a component
(bundle, feature, ...) gets to spec what they think is the reasonable way
to run/use/deploy/... their product but some outer scope defined by the
consumer is able to override those values.
Mel Martinez <melm@xxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
03/27/2006 11:27 AM
Please respond to
Equinox development mailing list
Mel Martinez <melm@xxxxxxxxxx>
[equinox-dev] Re: Suggestion:
add Eclipse-UnpackBundlle: to manifest
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
that it is not a hard requirement to support both models. The feature
developer should not be dictating this over the plugin developer since
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
requirements of the plugin. The suggestion below gives us a path
this correct model.
"Alex Blewitt" <alex.blewitt@xxxxxxxxx> wrote on 03/26/2006
> 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.
equinox-dev mailing list