cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Changes to config.xml
Date Sun, 12 May 2013 18:31:38 GMT
I'll clarify why it fails and what we can do to change this behavior and
mitigate difficulty migrating plugin manifest files moving forward.

The issue is that a plugin.xml needs to specify, at a minimum, how it
injects itself into config.xml to hook the native code associated with the
plugin into cordova's bootup. Example:

<config-file target="config.xml" parent="plugins">
    <plugin name="Accelerometer"
value="org.apache.cordova.core.accelerometer" />

The above plugin.xml bit says "graft the contents of the <config-file>
element into the file config.xml at the Xpath selector 'plugins'."

One thing that happened with the move over to <features> instead of
<plugins> inside config.xml is that there is no longer a <plugins>
element. This is why plugin installation fails with plugman: the Xpath
selector cannot be resolved.

The plugin manifests are already growing unnecessarily because of changes
we are introducing into the underlying project. Take a look at the oldest
plugin in use on PhoneGap Build, ChildBrowser, to see that the manifest
contains several different <config-file> elements to address the changing
configuration surface in cordova [1]. Related to this, moving from a root
<cordova> element in config.xml to a root <widget> element caused similar
issues (but was mitigated by adding support for wildcard Xpaths, I.e.

I see a couple of options but they require further thought:

 - the plugin.xml spec currently has, as a requirement, to throw an error
if the Xpath selector cannot be resolved. With the <plugins> element gone,
any plugin.xml that has config.xml as the target and "plugins" as the
selector will fail. We can leave an empty <plugins> element in the
config.xml for backwards compatibility in this case. What will happen,
though, if the same plugin entry is added into both <features> and
 - we can change the behavior of throwing an error if the Xpath selector
fails to resolve (and simply ignore), but this doesn't solve the
underlying problem.

Hope that helps with understanding.


On 5/11/13 6:12 PM, "Joe Bowser" <> wrote:

>Does this break the plugin or plugman? It shouldn't break the plugin
>if the class is properly specified.
>On Fri, May 10, 2013 at 6:30 PM, Steven Gill <>
>> Hey All,
>> I noticed Andrew made some config.xml changes to help bring it up to
>> spec [1]. I wanted to make sure this was brought to the attention of
>> makers.
>> As Andrew states "This unifies the config.xml used by iOS and Android.
>> <feature> tags can be used to add plugins. The changes are
>>non-intrusive so
>> the older versions of the config.xml can still be used after this
>> The value of a param named "ios-package" determines the class for the
>> plugin. Also changes the config.xml with the unified one on the project
>> template"
>> I also wanted people to be aware that this seems like it will break
>> out there. It isn't a huge deal with 3.0.0 looming. People just need to
>> update their plugin.xml files. The device motion plugin [2] I am
>>working on
>> errors out when trying to install using plugman now. This is due to
>> to <feature>.
>> -Steve
>> [1]
>> [2]

View raw message