Caused by: org.eclipse.virgo.kernel.osgi.framework.UnableToSatisfyBundleDependenciesException: Unable to satisfy dependencies of bundle 'com.rits.derby' at version '1.0.0': Import-Bundle with symbolic name 'com.rits.databases' in version range '[0.0.0, oo)' could not be satisfied
at org.eclipse.virgo.kernel.userregion.internal.importexpansion.ImportExpansionHandler.getBundlePackageImports(ImportExpansionHandler.java:271)
at org.eclipse.virgo.kernel.userregion.internal.importexpansion.ImportExpansionHandler.getAdditionalPackageImports(ImportExpansionHandler.java:236)
at org.eclipse.virgo.kernel.userregion.internal.importexpansion.ImportExpansionHandler.expandImports(ImportExpansionHandler.java:206)
at org.eclipse.virgo.kernel.userregion.internal.importexpansion.ImportExpansionHandler.expandImportsIfNecessary(ImportExpansionHandler.java:174)
at org.eclipse.virgo.kernel.userregion.internal.importexpansion.ImportExpansionHandler.expandImports(ImportExpansionHandler.java:112)

The order of installation of bundles in the pickup directory is not defined, so when they install in the "wrong" order you see the error.

The only ordering guarantee we make is that if you carefully drop artifacts in the pickup directory in the "right" order, allowing each to deploy before dropping the next, Virgo respects the order when it warm starts. However, on a cold start it is as if all the files in the pickup directory were placed there at once and the deployment order is no longer guaranteed.

There are better ways of providing dependencies.

You could place both bundles in repository/usr and then deploy a plan in pickup which refers to both bundles. The plan defines the order of install, but plan contents are installed before being started, so the order isn't crucial for simple package dependencies. (The start order might be significant though and again this is in the order the artifacts are specified in the plan.)

You could package the bundles in a PAR file so that they are both installed before being started and then deploy the PAR file in pickup.

Or you could put bundle B in repository/usr and deploy bundle A to pickup. Virgo will "fault in" bundle B while calculating the dependencies of bundle A.

Glyn, I suppose if the bundles are under usr directory, then they won't be reloaded automatically. And since I am developing those bundles, I want them to reload on every change I make, hence I placed them under pickup directory.

I need to try a plan with the plan+bundles under the pickup.

I think a way for all the bundle/clean issues to go away would be if virgo was re-scanning the repositories once (and updating it's cache) before throwing UnableToSatisfyBundleDependenciesException

If you want to reload either bundle as soon as you change it, I would recommend changing the interface between the bundles to be a service dependency with the service interface package stored in some other (relatively stable) bundle. Then the order of deployment won't matter. (This should also help unit testing as you can mock or stub the service interface.)

If you want to reload either bundle as soon as you change it, I would recommend changing the interface between the bundles to be a service dependency with the service interface package stored in some other (relatively stable) bundle. Then the order of deployment won't matter. (This should also help unit testing as you can mock or stub the service interface.)

Hi Glyn, that would require more work per service, especially for interfaces that will have 1 and only 1 impl. Also changing the interface means restarting the server.

I would like to find a simple way to make it work without compromise...

this works and though it is ok for deploying the bundles, it is too much work to do during development.

I've configured my eclipse to build the bundle's jar/war whenever I change a single file. That is convenient and works nicely and allows me to quickly change and test my code. It only works via the pickup dir though.

Also if I do a clean-build, the virgo/work directory is cleaned up which is equivalent to -clean (I think....) .

That means that all jars/wars are available after a -clean restart of virgo. I've checked he docs and virgo won't pick bundles of a plan file from the pickup => I am stuck cause I can't order the way they are loaded.

A question is why virgo doesn't "index" the bundles of the pickup directory before actually loading them? This way it would know that the required B bundle is available when trying to start A.

A question is why virgo doesn't "index" the bundles of the pickup directory before actually loading them? This way it would know that the required B bundle is available when trying to start A.

We seriously considered this option a couple of years ago but were put off by the complexity and potential unreliability. The main problem is that some file systems (e.g. on Windows) are not very helpful and it is quite hard to determine when a file has "stabilised" and is ready for deployment. Encouraging users to drop related groups of bundles into pickup would make this problem quite a lot harder. How would we know when the group was complete so we could index it?

Also, this indexing is far from straightforward as we cannot really tell bundle dependencies until we drive the OSGi resolver. What we would actually need to do is spot a group and make sure they are deployed together.

We are considering an extension to plans which may help solve this problem: allowing a plan to refer to artifacts by URI. This would allow the artifacts to be updated more easily as they would not need to be in a repository.

See bug 327538 for more information (including the bugs it blocks, which are the enhancements we currently see - please feel free to raise another to cover your use case).

A question is why virgo doesn't "index" the bundles of the pickup directory before actually loading them? This way it would know that the required B bundle is available when trying to start A.

We seriously considered this option a couple of years ago but were put off by the complexity and potential unreliability. The main problem is that some file systems (e.g. on Windows) are not very helpful and it is quite hard to determine when a file has "stabilised" and is ready for deployment. Encouraging users to drop related groups of bundles into pickup would make this problem quite a lot harder. How would we know when the group was complete so we could index it?

Also, this indexing is far from straightforward as we cannot really tell bundle dependencies until we drive the OSGi resolver. What we would actually need to do is spot a group and make sure they are deployed together.

We are considering an extension to plans which may help solve this problem: allowing a plan to refer to artifacts by URI. This would allow the artifacts to be updated more easily as they would not need to be in a repository.

See bug 327538 for more information (including the bugs it blocks, which are the enhancements we currently see - please feel free to raise another to cover your use case).

ok, sounds like a solution. How will it work? I.e. if a plan is "touch"ed will virgo check for modification to all URI's?

We'll probably offer operations via JMX, which can ultimately be driven by the development tooling, to either refresh the whole plan or to refresh a specific artifact of a plan, although I am yet to work out the details.

If you raise an enhancement bug to cover your use case, you can capture specific requirements there for posterity.

We'll probably offer operations via JMX, which can ultimately be driven by the development tooling, to either refresh the whole plan or to refresh a specific artifact of a plan, although I am yet to work out the details.

If you raise an enhancement bug to cover your use case, you can capture specific requirements there for posterity.

Hi, no I am happy with the JMX solution it is more proper than probing for a changed file in the filesystem every sec.

I was suggesting that you raise an enhancement bug to capture your requirement. Unfortunately, it is hard to say when we will satisfy particular requirements until we have done more planning. We will be holding a Virgo F2F around the end of this month, so please would you raise your requirement by then so we can take it into account.

I was suggesting that you raise an enhancement bug to capture your requirement. Unfortunately, it is hard to say when we will satisfy particular requirements until we have done more planning. We will be holding a Virgo F2F around the end of this month, so please would you raise your requirement by then so we can take it into account.

Hi, I am happy to go for the JMX solution, it's just what I need. I was just wondering when abouts it will be ready.