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

This is a multipart message in MIME format.
In general you want plugins to be packed.
 It keeps things together, compresses the information, and improves
classloading performance.  Unpacking is used in cases where you have
lots of data that needs to be directly in the file system.  For example,
executables, html files loaded by a browser, ...  This form is less
efficient on disk.

While technically feasible, as you imply,
it is not that great to take a packed plugin and treat it as unpacked.
 This will result in a mess of class files directly on disk.  It
iwll run but will be slower.  Similarly, taking an unpacked plugin
and treating it as packed will result in nested JARs and some inefficiency
at startup as well as larger disk footprint as the nested JARs are extracted.

Jeff

David M Williams <david_williams-r/Jw6+rmf7HQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx

03/28/2006 12:56 AM

Please respond to
Equinox development mailing list

To	Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Re: Suggestion: add Eclipse-UnpackBundlle:        to        manifest

The "override" could only go from "packed" to "unpacked",
right? And, what would the advantage be of using "unpacked"?
Faster disk loading? 

And, BTW ... I agree, the plugin should definitely "spec" if
its packed or not ... I've found its a bit difficult at times to "build
one jar" using PDE ... as I have to look at feature to see what it
should be, etc.

Jeff McAffer <Jeff_McAffer-G1DYhSM1WHTQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx

03/28/2006 12:44 AM

Please respond to
Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] Re: Suggestion: add Eclipse-UnpackBundlle: to        manifest

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.   

Jeff

Mel Martinez <melm-r/Jw6+rmf7HQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
Sent by: equinox-dev-bounces-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx

03/27/2006 11:27 AM

Please respond to
Equinox development mailing list

To	equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx
cc	Mel Martinez <melm-r/Jw6+rmf7HQT0dZR+AlfA@xxxxxxxxxxxxxxxx>
Subject	[equinox-dev] 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.
>

_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev-j9T/66MeVpFAfugRpC6u6w@xxxxxxxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev