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" <bows...@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 <stevengil...@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
