only because the refresh was not executed as alluded to.

I think it's important to add for future reference that B may stay active, but this will not survive restart. After restart, B can not start because of missing dependencies.

This is the expected behavior.

Hey,

we can't expect a behavior different than the specification, so if the framework is doing what the spec says we can't do anything about it (except to push to change the spec).

Having said so, File Install is an Apache service that provides out of the spec functionality that leverages the OSGi framework.

In my eyes the behavior you describe is the expected one. If you install a bundle using file install and the uninstall it using file install you get your expected behavior. But if you use file install to install the bundle but then you use the gogo console to uninstall it then you are using a different layer, so you are uninstalling the bundle unbeknownst to file install. So file-install, when uninstalling a bundle, seems to refresh the framework. Gogo shell does not do that when issues uninstall command, you have another one to do that because commands are more granular. Besides, you should not expect gogo to remove the file from the filesystem when issuing uninstall command.

Your interface with file-install is the file system. So you communicate to it placing files and removing them from the file system. That is why, if you install using file system and then uninstall using gogo shell, the file is still there and, when you remove it from the file system, file-install will try and unsinstall it from the framework, because it had it tracked, therefore you get

09:08:56,010 WARN [fileinstall-/data/projects/Liferay/dev/ce/liferay-portal-7.0-ce-ga1/osgi/modules][org_apache_felix_fileinstall:103] Failed to uninstall bundle: /data/projects/Liferay/dev/ce/liferay-portal-7.0-ce-ga1/osgi/modules/MyGreatService-api-1.0.0.jar with id: 496. The bundle has already been uninstalled

When you update the file in the filesystem file-install does not install it, it tries to update it. That is why if you uninstall the bundle using gogo and copy a new bundle over the existing bundle in file install it will not install it, it will update it, but the bundle has not change from the previous version that file install has tracked, so nothing is done and you get

09:06:47,783 INFO [com.liferay.portal.kernel.deploy.auto.AutoDeployScanner][AutoDeployDir:250] Processing MyGreatService-api-1.0.0.jar

Everything you have described in the issue is the expected behavior of the tools you are using.

Expected behavior is not "by the spec" but by comparing to the result of the alternative approach which is fileinstall. In another words, if this is not a bug then (using the exact same reasoning) it is bug that fileinstall behaves differently.

Here is how this looks like from user perspective. Lets use 2 bundles

• MyGreatService-api

• MyGreatService-service
  such that MyGreatService-service imports packages form MyGreatService-api

Copy both file to deploy folder.
Logs:

result of lb

Remove MyGreatService-api from LIFERAY_HOME/osgi/modules
Logs:

result of lb

Deploy MyGreatService-api again:
Logs:

result of lb

Do uninstall 496

Logs:

result of lb

and MyGreatService-api.jar file is still in LIFERAY_HOME/osgi/modules folder

Do refresh
Logs:

result of lb

As an attempt to install it, copy MyGreatService-api.jar to deploy folder again
Logs:

result of lb

As an attempt to clear up things, remove MyGreatService-api.jar from LIFERAY_HOME/osgi/modules folder
Logs:

result of lb

As an attempt to install it, copy MyGreatService-api.jar to deploy folder again
Logs:

result of lb

Now try this:

now try to remove MyGreatService-api.jar from LIFERAY_HOME/osgi/modules folder
Logs:

result of lb