| Cleaning up Virgo repository [message #829780] |
Mon, 26 March 2012 15:27  |
Eclipse User |
|
|
|
We are moving our monolithic application towards OSGI compatible form. Its build process and all dependencies are managed by Maven. When some bundle is extracted, it is deployed to Virgo to ensure that it will start/stop properly. Before bundle installation take place, we must ensure that all imported packages are available on server. However, after some time, it turns out that some bundles installed as dependencies from EBR all no longer needed - sometimes such orphans are detected, sometimes not. Is there any way to automate removal of unused bundles from Virgo repository? Is it considered as a good practice at all?
Every time application is deployed into another server we must copy Virgo along with its entire bundles repository first. What we'd like to avoid is having Virgo directory taking huge disk space and thus hard to manage.
|
|
|
|
|
| Re: Cleaning up Virgo repository [message #830102 is a reply to message #830077] |
Tue, 27 March 2012 03:38  |
| Eclipse User |
|
|
|
There seem to be three categories of unnecessary bundles in the repository, only one of which seems feasible to detect automatically as far as I can see.
- Bundles which are not installed at runtime. Trivial to detect by diffing the runtime state against the repository.
- Bundles which are installed but are not depended upon (NB. this includes all kinds of dependencies: package, service, bundle, fragment). Typically, bundled libraries do not publish or consume services, so that makes things a bit simpler. Not too bad to detect as the wiring can be inspected using standard OSGi APIs to detect orphaned groups of bundles. However, the "fly in the ointment" is as follows. Since these bundles were installed at all, some of them must have been explicitly deployed via pickup, deployer API, present in a deployed plan, etc.. I can't see how tooling could know which explicitly deployed bundles were intentionally present and which were unintentionally present. I think it is up to the user to trim back the list of explicitly deployed bundles according to their requirements.
- Bundles which are installed and which satisfy optional dependencies (which Spring, for example, has lots of) of necessary bundles but which aren't really needed. This also appears impossible to detect automatically.
Is there a flaw in my analysis?
|
|
|
Powered by
FUDForum. Page generated in 0.03216 seconds
Home
) but it's difficult to track all of them when porting existing application. We have to do a lot of experimentation, OSGIfying a lot of external libraries, and sometimes no longer needed bundles are left. It would be great if we could do garbage collecting - it may be done manually of course. The essential thing is to list all unused bundles. Is it possible to do with standard tooling?