[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] Suggestion: add Eclipse-UnpackBundlle: to manifest
- From: "Alex Blewitt" <alex.blewitt@xxxxxxxxx>
- Date: Sat, 25 Mar 2006 18:22:09 -0800
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=hLgj8pA7sm9nmO2ZcbRlvIVhaeKyhE3GM1Nox/+pPWMxmHUXbi30mUwA2kDTIAhfQsqYbadzIpUMUNAxh2HPfv78F1djT25ULtANuQbhnj+gNyFldXLc7vnW0EC0z1sxgmbnfT0dwUOq3WHbqSPlLEV0IjQv0yKlbauFeMzEr2I=
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.