Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Re: Suggestion: add Eclipse-UnpackBundle: to manifest 
Jeff,
You write that nested JARs in a packed bundle are extracted to the file system. Could you elaborate? 

For example, where are they extracted, when, and by what layer?
I've been wondering about the performance implications in both time and resources between two polar opposites of runtime approach (I know this description is a bit crude):
1) The Eclipse model, where the update configurator installs all bundles in the bundle store, and then relies on the application configuration (perhaps with the extension registry) to bring the system up.
2) The OSGi model, where some external operator process installs and starts certain bundles whose runtime state and start level are persisted across invocations.
In my use case I want to have a single bundle store with tens/ hundreds/thousands of bundles, including multiple versions of the same bundle, and have multiple runtime processes use the bundle store concurrently. The primary goal of this use case is to leverage the OSGi dependency metadata and methodologies to componentize our many overlapping runtimes. However, I don't see this use case discussed-- it is always a single runtime tied to a single bundle store.
- It would be a waste of space if each runtime configuration would maintain a separate cache of these nested JARs. There may be disk locking implications if multiple runtimes share the same cache.
- If each runtime uses the update configurator, how much processing is wasted if each runtime uses only a small subset of all the bundles in the bundle store, but all are installed for each runtime?
Feel free to move this to a different thread, as it is more related to your extraction comment than the unpack-bundle manifest entry. I also have related questions about how to best express internal dependencies (e.g. Class.forName() and service provider support) that I've asked on the osgi-dev mailing list. Do you also monitor that list? (See Indirect Dependencies in OSGi/Equinox.) I want to be a good citizen and not cross-post... 

/djk


Date: Tue, 28 Mar 2006 08:50:51 -0500
From: Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Subject: Re: [equinox-dev] Re: Suggestion: add  Eclipse-UnpackBundlle:
        to      manifest
To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Message-ID:
<OF6308F01C.9AA9E420-ON8525713F.004B43C5-8525713F. 004C0D1D@xxxxxxxxxx> 
Content-Type: text/plain; charset="us-ascii"

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@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
03/28/2006 12:56 AM
Please respond to
Equinox development mailing list


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
03/28/2006 12:44 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
03/27/2006 11:27 AM

Please respond to
Equinox development mailing list



To
equinox-dev@xxxxxxxxxxx
cc
Mel Martinez <melm@xxxxxxxxxx>
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@xxxxxxxxx> 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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eclipse.org/pipermail/equinox-dev/attachments/ 20060328/5681be52/attachment.html 

------------------------------

_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


End of equinox-dev Digest, Vol 11, Issue 28
*******************************************

Back to the top