cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <>
Subject Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Date Wed, 23 Apr 2014 14:07:43 GMT
I like the <param name="registry"> idea!

The main thing I don't like about <feature>, is that it already means
something different in platform config.xml:
    <feature name="LocalStorage">
        <param name="ios-package" value="CDVLocalStorage" />

This means that when JS makes an exec() for "LocalStorage", route it
to "CDVLocalStorage". JS-only plugins don't inject <feature>, and
<feature> does not contain plugin IDs. If a plugin has multiple exec()
targets, then it *must* inject multiple <feature> tags.

<dependency> is much closer, but the meaning is not as clear in
config.xml (e.g. apps depend on platforms as well).

So, how about using <cdv:plugin>? Name is quite clear :).

On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage <> wrote:
> I think consistency with input and output config.xml files makes more sense than consistency
with plugin.xml. So +1 <feature/>
> Sent from my iPhone
>> On Apr 22, 2014, at 8:06 PM, Gorkem Ercan <> wrote:
>>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <> wrote:
>>> Anis - Gorkem wants <feature> since it works with his IDE. *Why* do
>>> you prefer <feature>?
>> Just to be clear I am not trying to push for <feature> because it works on
>> the JBoss/Eclipse IDE now. I do not mind ripping it apart and implementing
>> a new editor if there is a good benefit. However I favor <feature> because
>> it allows validation and content assist due to its XSD (I think we have
>> discussed about this earlier) which is probably the only benefit of the xml
>> markup on a configuration file these days.
>> If we use dependency for defining the plugins to be restored it does not
>> mean that <feature> magically disappears. It is still used by the platform
>> runtimes and therefore the CLI generated config.xml files. I guess that
>> would mean we still need to keep the documentation etc for it around.
>> Also one thing that I have noticed when implementing the restore for
>> plugins because all the information is given as <param>s under feature it
>> is very easily extendible. For instance if someday we want to support
>> enterprise plugin registries, we could just add <param name="registry"
>> value="http://registry.acme.corp" /> and use the value on the
>> implementation. Same could be done to dependency by adding another
>> attribute which would break the validations etc.
>>>> On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI <>
>>>> I prefer <feature>.
>>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <>
>>>> wrote:
>>>>> I prefer the <dependency> syntax. It's shorter, more intuitive
>>>>> consistent with plugin.xml. I don't see much value in _partial_
>>> compliance
>>>>> with the w3c spec.
>>>>> On Tue, Apr 22, 2014 at 1:31 PM, Michal Mocny <>
>>> wrote:
>>>>>> Gorkem is adding awesome feature to restore plugins/platforms your
>>>>>> depends on.  There is some debate on the correct syntax to use in
>>>>>> config.xml file: do we use (a) plugin.xml style <dependency>
tags, or
>>> (b)
>>>>>> w3c widget spec <feature> tags?
>>>>>> Gorkem votes (b), arguing that using widget spec helps his tools
>>>>>> editing config.xml (existing gui editor, I assume?), and has
>>> implemented
>>>>> a
>>>>>> PR for it (
>>>>>> I vote (a), arguing that we already don't match widget spec, and
>>> already
>>>>>> have established syntax for for specifying plugin urls & versions
>>>>>> plugin.xml (with docs and examples), and its better for our CLI
>>>>>> implementation to use existing plugin deps handlers.
>>>>>> What do you think?
>>>>>> Background: read full thread titled "[GitHub] cordova-cli pull
>>> request:
>>>>>> CB-6469"

View raw message