As Pascal and others have
mentioned, Equinox (and Felix) support "reference" installs
which is just a form of a file: URL that has reference:
prepended to it (e.g. reference:file:/path/to/bundle.jar). I
imagine you already have your own custom launcher, or at least
our own "provisioning" bundle that is doing the installs for
your. Reference installs are the way to go if your
provisioning bundle has a managed storage area where it is
downloading and storing the bundle artifacts before actually
installing them AND you are happy with the framework using the
content from this managed storage area at runtime. This is
how the Eclipse platform (with p2) manages the installed
bundles in Eclipse (i.e. the bundles are stored in the
plugins/ folder) without having duplicates on disk. But if
you do not have that kind of provisioning storage area then
you should consider Neil's suggestion.
Note that if you do not want to
use the simple BundleContext.installBundle(String location)
method which requires the bundle location to be a proper URL
(e.g. reference:file:/path/to/bundle.jar), but instead you
want to control your location strings to be something else
then you can use the installBundle(String location,
InputStream content) like this:
bc.instsallBundle("mylocation", new
URL("reference:file:/path/to/bundle.jar").openstream());
Tom
Neil Bartlett ---11/19/2013
06:34:30 AM---OSGi persists the state of all installed bundles
in the Framework storage directory; by default in E
From: Neil Bartlett
<njbartlett@xxxxxxxxx>
To: Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>, Patrick Valsecchi
<pvalsecc@xxxxxxxxx>,
Date: 11/19/2013 06:34 AM
Subject: Re: [equinox-dev] Can I avoid
having all my OSDI containers copied?
Sent by: equinox-dev-bounces@xxxxxxxxxxx
OSGi persists the state of all
installed bundles in the Framework storage directory; by default
in Equinox this is 'configuration/org.osgi.eclipse'. Therefore,
once the bundles are installed they are no longer needed in the
external "plugins" directory.
You might want to consider writing
a custom OSGi launcher. On first use it could download the
bundles from a URL or temporary filesystem. The
BundleContext.installBundle() method can read bundles from any
InputStream, so local files are not necessarily required. This
will cache the bundles into the framework storage dir. Then on
subsequent uses the framework will start up with all the same
bundles in the same state.
Alternatively you could pre-cache
the bundles as part of the install process before shipping the
device to users. This has the advantage that Equinox will
persist the resolution state, which may improve start-up time.
Regards
Neil
On 19 November 2013
at 08:21:03, Patrick Valsecchi (pvalsecc@xxxxxxxxx) wrote:
Hi,
I'm running on a platform that has
very limited disk space and I was looking at disk usage of
OpenDaylight.
The biggest directories are the plugins and configuration/org.eclipse.osgi/bundlesdirectories. The plugins directory
is where all my bundles are, so I'm OK with it. But theconfiguration/org.eclipse.osgi/bundles directory seems to contain mostly
copies of my bundles.
For example configuration/org.eclipse.osgi/bundles/117/1/bundlefile is an exact copy ofplugins/org.opendaylight.controller.clustering.services-implementation-0.4.0.jar. That is a big waste of disk space.
I've tried to find a configuration
option to disable that and found nothing. Is there something?
I've looked at the Equinox source
code as well and didn't find anything. Can somebody point me
to the location in the code where this is done? I'd like to
disable that or at least replace it by a hard link.
Thanks
_______________________________________________
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
