[
https://issues.apache.org/jira/browse/CB-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13797392#comment-13797392
]
Peter commented on CB-5016:
---------------------------
FYI - In case you have this same problem and cannot wait for 3.2 here is a
workaround which worked for me...
Removal of file plugin fails because of filetransfer needs it
{code}
D:\MYDIR>cordova plugin rm org.apache.cordova.file
[Error: Another top-level plugin (org.apache.cordova.file-transfer) relies on
plugin org.apache.cordova.file, therefore aborting uninstallation.]
{code}
So remove the filetransfer plugin
{code}
D:\MYDIR>cordova plugin rm org.apache.cordova.file-transfer
{code}
Then try remove file plugin again, but now it breaks :(
{code}
D:\MYDIR>cordova plugin rm org.apache.cordova.file
[Error: Plugin "org.apache.cordova.file" not added to project.]
{code}
And can't remove anything else either because whole environment is broken :( :(
{code}
D:\MYDIR>cordova plugin rm org.apache.cordova.geolocation
{ [Error: ENOENT, no such file or directory
'D:\MYDIR\plugins\org.apache.cordova.file\plugin.xml']
errno: 34,
code: 'ENOENT',
path: 'D:\\MYDIR\\plugins\\org.apache.cordova.
file\\plugin.xml',
syscall: 'open' }
{code}
A *WORKAROUND* at this point is just add the file plugin again on top of the
partially broken one (below I add it from my local filesystem copy of the
plugin)
{code}
D:\MYDIR>cordova plugin add C:\3.x\cordova-plugin-file
{code}
And now the file plugin can be removed successfully and environment is OK again
:)
{code}
D:\MYDIR>cordova plugin rm org.apache.cordova.file
{code}
Hope it helps somebody.
> add then rm of dependent plugin as top level plugin breaks environment
> -----------------------------------------------------------------------
>
> Key: CB-5016
> URL: https://issues.apache.org/jira/browse/CB-5016
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugman
> Environment: Windows 7
> Reporter: Mike Billau
> Fix For: 3.2.0
>
>
> Removing a dependent plugin that was installed as a default top level plugin
> breaks the environment because during plugin add, the plugin name gets added
> to plugins/platform.json under "installed_plugins" and not under
> "dependent_plugins". However, in plugin rm, the plugin code gets fully
> removed from the work space but the name is left in "installed_plugins"
> because the tools search for it in "dependent_plugins."
> *Scenario 1* - Install the dependent plugin first
> cordova create Sample && cd Sample
> cordova platform add android
> cordova plugin add org.apache.cordova.file
> cordova plugin add org.apache.cordova.file-transfer (depends on File)
> cordova plugin ls
> [org.apache.cordova.file, org.apache.cordova.file-transfer]
> *Now if you look at platforms/android.json, you will see that both plugins
> were added to "installed_plugins"*:
> cat platforms/android.json
> {noformat}
> "installed_plugins": {
> "org.apache.cordova.file": {
> "PACKAGE_NAME": "io.cordova.hellocordova"
> },
> "org.apache.cordova.file-transfer": {
> "PACKAGE_NAME": "io.cordova.hellocordova"
> }
> },
> "dependent_plugins": {}
> {noformat}
> This leaves us in an invalid state when you go to remove the file-transfer
> plugin because for some reason it removes both the file-transfer and file
> plugin code, but it does not remove the file entry from "installed_plugins".
> cordova plugin rm org.apache.cordova.file-transfer
> cat platforms/android.json:
> {noformat}
> "installed_plugins":{"org.apache.cordova.file":{"PACKAGE_NAME":"io.cordova.hellocordova"}},"dependent_plugins":{}}
> {noformat}
> but:
> cordova plugin ls
> [No plugins added. Use cordova plugin add <plugin>]
> and:
> cordova build (and cordova prepare, etc.)
> [Error: ENOENT, no such file or directory,
> "C:\.........plugins\org.apache.cordova.file]
> *Scenario 2* - Install the lower level plugin and let plugman automatically
> install the dependencies:
> cordova create Sample2 && cd Sample2
> cordova platform add android
> cordova plugin add org.apache.cordova.file-transfer (depends on File, it will
> automatically get pulled down and installed)
> cordova plugin ls
> [org.apache.cordova.file, org.apache.cordova.file-transfer]
> *Now if you look, /platforms/android.json will be different than in Scenario
> 1*
> cat platforms/android.json:
> {noformat}
> "installed_plugins": {
> "org.apache.cordova.file-transfer": {
> "PACKAGE_NAME": "io.cordova.hellocordova"
> }
> },
> "dependent_plugins": {
> "org.apache.cordova.file": {
> "PACKAGE_NAME": "io.cordova.hellocordova"
> }
> }
> {noformat}
> You can see that now the File plugin is listed as a dependent_plugin. This is
> great, because now when you remove file-transfer, it will also remove file
> plugin:
> cordova plugin rm org.apache.cordova.file-transfer
> cat plugins/android.js:
> {noformat}
> "installed_plugins": {},
> "dependent_plugins": {}
> {noformat}
> and cordova build android will work just fine.
> So the problem here seems to be that if a dependent plugin was added
> manually, it will be added under installed_plugins and not dependent_plugins.
> Later when the consuming plugin is deleted, the tools delete the plugin code
> from the workspace but are not able to remove this plugin from the
> installed_plugins entry (presumably because it searches in the
> dependent_plugin object.) This leaves the project in a broken state because
> *plugin ls* does not show the installed plugin, but the tools will try to
> copy the file at MyApp/plugins/org.apache.cordova.****, whatever is listed in
> plugins/android.json file.
> I think the fix would be: When doing plugin uninstall, only remove plugins
> from the workspace if:
> 1) the plugin is detected to be a dependent plugin, (already being done since
> *cordova plugin rm org.apache.cordova.file-transfer removes the
> org.apache.cordova.file code) and
> 2. the plugin is listed in "dependent_plugins" section of
> /plugins/platform.json
--
This message was sent by Atlassian JIRA
(v6.1#6144)
