Actually I don't think of platforms as dependencies. Your app doesn't need android to run on iOS. It needs plugins. Plugin deps may be specific to certain platforms, but platforms are targets.
So I think dependency is not ambiguous with platforms.. Though your app may have more deps than just Cordova plugins. On 23 Apr 2014 10:08, "Andrew Grieve" <agri...@chromium.org> wrote: > 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" /> > </feature> > > 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 <purplecabb...@gmail.com> > 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 <gorkem.er...@gmail.com> > wrote: > >> > >>> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <agri...@chromium.org> > 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 <anis.ka...@gmail.com> > wrote: > >>>> I prefer <feature>. > >>>> > >>>> > >>>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <kam...@google.com > > > >>>> wrote: > >>>> > >>>>> I prefer the <dependency> syntax. It's shorter, more intuitive and > >>>>> 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 <mmo...@google.com> > >>> wrote: > >>>>> > >>>>>> Gorkem is adding awesome feature to restore plugins/platforms your > app > >>>>>> depends on. There is some debate on the correct syntax to use in > the > >>>>>> 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 > with > >>>>>> editing config.xml (existing gui editor, I assume?), and has > >>> implemented > >>>>> a > >>>>>> PR for it (https://github.com/apache/cordova-cli/pull/165). > >>>>>> > >>>>>> I vote (a), arguing that we already don't match widget spec, and > >>> already > >>>>>> have established syntax for for specifying plugin urls & versions in > >>>>>> 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" > >>> >