Patrick, I strongly suggest NOT using FileInstall. It simply doesn't support what you want it to do. It does have some nice features but it doesn't sound like they match with what you want.
Note also that the reference: URL feature is specific to Equinox. This is partially why FileInstall doesn't support it... FileInstall comes from the Felix project and is designed to be used with any OSGi framework implementation. Regards, Neil On Tue, Nov 19, 2013 at 2:50 PM, Patrick Valsecchi <[email protected]>wrote: > Hi all, > > In the config.ini file, all my bundle paths start with "reference:". But > only the core ones are loaded like that. Looking at how my other bundles > are loaded, I found that this is done by org.apache.felix.fileinstall. > > I've looked at the documentation of this lib and found no way to make the > automatically installed bundle treated as references. > > I've started to look at the fileinstall code, and it's quite convoluted... > so I have trouble to find where to add the "reference:". I'll continue my > search tomorrow... > > The solution to remove my source bundles will be my last resort, I guess. > > Thanks everybody for your help. > > > > On 11/19/2013 03:14 PM, Thomas Watson wrote: > > 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 > > > > [image: Inactive hide details for Neil Bartlett ---11/19/2013 06:34:30 > AM---OSGi persists the state of all installed bundles in the Fra]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 <[email protected]> <[email protected]> > To: Equinox development mailing list > <[email protected]><[email protected]>, > Patrick Valsecchi <[email protected]> <[email protected]>, > Date: 11/19/2013 06:34 AM > Subject: Re: [equinox-dev] Can I avoid having all my OSDI containers > copied? > Sent by: [email protected] > ------------------------------ > > > > 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 > (*[email protected]*<//[email protected]/>) > 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 the > configuration/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 of > plugins/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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing > [email protected]https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > > _______________________________________________ > equinox-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/equinox-dev > >
<<image/gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
