Changes to config.xml

[Steven Gill <st...@gmail.com>]

Hey All,

I noticed Andrew made some config.xml changes to help bring it up to widget
spec [1]. I wanted to make sure this was brought to the attention of plugin
makers.

As Andrew states "This unifies the config.xml used by iOS and Android. Now
<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 change.
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 plugins
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 switch
to <feature>.

-Steve

[1] https://issues.apache.org/jira/browse/CB-1108
[2]
https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-device-motion.git

Re: Changes to config.xml

[Filip Maj <fi...@adobe.com>]

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" />
</config-file>

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.
/*/plugins).

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
<plugins>?
 - 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.

[1] 
https://github.com/phonegap-build/ChildBrowser/blob/master/plugin.xml#L22-L
32

On 5/11/13 6:12 PM, "Joe Bowser" <bo...@gmail.com> 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 <st...@gmail.com>
>wrote:
>> Hey All,
>>
>> I noticed Andrew made some config.xml changes to help bring it up to
>>widget
>> spec [1]. I wanted to make sure this was brought to the attention of
>>plugin
>> makers.
>>
>> As Andrew states "This unifies the config.xml used by iOS and Android.
>>Now
>> <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
>>change.
>> 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
>>plugins
>> 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
>>switch
>> to <feature>.
>>
>> -Steve
>>
>> [1] https://issues.apache.org/jira/browse/CB-1108
>> [2]
>> 
>>https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-device-motion.gi
>>t

Re: Changes to config.xml

[Joe Bowser <bo...@gmail.com>]

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 <st...@gmail.com> wrote:
> Hey All,
>
> I noticed Andrew made some config.xml changes to help bring it up to widget
> spec [1]. I wanted to make sure this was brought to the attention of plugin
> makers.
>
> As Andrew states "This unifies the config.xml used by iOS and Android. Now
> <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 change.
> 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 plugins
> 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 switch
> to <feature>.
>
> -Steve
>
> [1] https://issues.apache.org/jira/browse/CB-1108
> [2]
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-device-motion.git

Re: Changes to config.xml

[Gorkem Ercan <go...@gmail.com>]

This was actually my change.
I think this would possibly cause a break only if the plugin is already
defined as <feature> tag and plugin.xml defines it again with <plugin> tag.
Is that the case? If so we can do a priority selection until the <plugin>
tag is completely retired.
--
Gorkem

--
Gorkem


On Fri, May 10, 2013 at 9:30 PM, Steven Gill <st...@gmail.com> wrote:

> Hey All,
>
> I noticed Andrew made some config.xml changes to help bring it up to widget
> spec [1]. I wanted to make sure this was brought to the attention of plugin
> makers.
>
> As Andrew states "This unifies the config.xml used by iOS and Android. Now
> <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 change.
> 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 plugins
> 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 switch
> to <feature>.
>
> -Steve
>
> [1] https://issues.apache.org/jira/browse/CB-1108
> [2]
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-device-motion.git
>