Issue updating bundles with dependencies using a package

[ebaggs]

I am using AEM 6.0 with Service Pack 1.  I ran into an issue where I am updating existing OSGi bundles using a package and putting them into the /app/<product-name>/install folder.  I have one bundle (A) that has a dependency upon another bundle (B).  When I update both bundles using a package, both bundle ID's are updated in system/console/bundles. This is fine, but bundle (A) shows in the system/console/bundles still dependent upon the old bundle B ID number (###) before the update.  If I click on the bundle ID number it says the bundle doesn't exist.  If I install the bundles via the sling install instead of a JCR install, I don't have this problem at all.  The result is that the classes in bundle B when accesses receive a ClassCastException and state that class BBB cannot be cast to class BBB.  Installing updates to these bundles using sling doesn't fix the problem nor does a restart or deleting one or both bundles from /system/console/bundles and then re-adding them.  

The only way to solve the problem is to go to the crx-quickstart/launchpad/felix folder.  There I find a folder with the old bundle B ID number (bundle###) and delete it manually.  I then restart the AEM instance.  This fixes the problem until I once again update the bundles using a package and the jcr install folder.  It appears when there are dependencies that the package install of bundles might get messed up.

Is this a bug in the AEM software 6.0 service pack 1?  Am I missing something here with regards to bundles and dependencies?

[ebaggs · Accepted solution]

I discovered that when I change the name of bundle B's jar file to be alphabetically before bundle A's jar file the problem doesn't occur any more.  It seems as if the bundles are removed alphabetically by jar name before the new bundles are installed, and if a bundle has a dependency on it when it is removed, it doesn't get removed.  Instead the new bundles are installed, and the old bundle gets left around in felix to mess things up.  Changing the names of the jar files fixes the problem; this, however, seems like a hokey solution.