[ 
https://issues.apache.org/jira/browse/CB-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16297127#comment-16297127
 ] 

Joe Bowser commented on CB-13647:
---------------------------------

[~goffioul] Everything will be using new paths coming forward.  The only reason 
that we support legacy paths is to not break plugins, and I'm wondering if the 
InAppBrowser's icons are missing post-install.  We're definitely not patching 
edit-config, since it's a hack anyway, and xml and java source files can both 
use new or legacy paths, since I'm not aware of any Koltin plugins out in the 
wild yet (and they should use new paths anyway)



> Incomplete plugin restoration
> -----------------------------
>
>                 Key: CB-13647
>                 URL: https://issues.apache.org/jira/browse/CB-13647
>             Project: Apache Cordova
>          Issue Type: Bug
>          Components: cordova-android
>    Affects Versions: 7.0.0
>            Reporter: Michael Goffioul
>            Assignee: Joe Bowser
>              Labels: android-next
>
> I'm having a problem with plugin restoration since cordova-android 7.0.0, 
> when plugins use a mix of config-file and edit-config on the same file (e.g. 
> AndroidManifest.xml) and only edit-config uses the real path to the file. 
> I've tried both cordova-cli 6.5.0 and 7.1.0 with the same result.
> 1) Create a new corodva project and enter top-level direcotyr
> 2) Create subfolder to contain a local plugin: mkdir -p 
> localplugins/testplugin1
> 3) Create the following files to define the local plugin:
> - plugin.xml (adds an attribute to <application> and a category to 
> <intent-filter>)
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <plugin xmlns="http://apache.org/cordova/ns/plugins/1.0"; 
> id="com.example.testplugin1" version="1.0.0">
>     <name>Test Plugin 1</name>
>     <platform name="android">
>         <config-file target="AndroidManifest.xml" 
> parent="/manifest/application/activity/intent-filter">
>             <category android:name="android.intent.category.HOME" />
>         </config-file>
>         <edit-config file="app/src/main/AndroidManifest.xml" 
> target="/manifest/application" mode="merge">
>             <application android:largeHeap="true" />
>         </edit-config>
>     </platform>
> </plugin>
> {code}
> - package.json
> {code}
> {
>         "name": "com.example.testplugin1",
>         "version": "1.0.0"
> }
> {code}
> 4) Add android platform: cordova platform add android@7.0.0 --save
> 5) Add local plugin: cordova plugin add localplugins/testplugin1 --save
> At this point, if you check 
> platforms/android/app/src/main/AndroidManifest.xml, it'll contain the 2 
> changes defined in the plugin.
> Now attempt to use platform/plugin restoration with thw following:
> {code}
> cordova platform rm android
> cordova prepare android
> {code}
> If you check again AndroidManifest.xml, it will only contain one of the 
> changes defined in the plugin (the attribute to <application>). The other 
> change is missing.
> If you use the real path to AndroidManifest.xml for the definition of 
> <config-file>, then the problem does not occur. BUT, the problem can also 
> occur when changes to AndroidManifest.xml are coming from multiple plugins, 
> including the standard cordova plugin, most of which do not use the real path 
> to AndroidManifest.xml yet.
> The problem can affect other files too. For instance I experienced incomplete 
> restoration of plugins trying to register themselves in res/xml/config.xml. 
> Only one plugin, out of 7, was using the real path 
> app/src/main/res/xml/config.xml and I ended up with only one plugin defined 
> in res/xml/config.xml, causing the application to fail to start.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org
For additional commands, e-mail: issues-h...@cordova.apache.org

Reply via email to