Can we see a mock version of what this all would like in either case? I also withdraw my previous +1 for <feature/> after Michal's clarification.
Sent from my iPhone > On Apr 23, 2014, at 9:03 AM, Michal Mocny <mmo...@google.com> wrote: > > 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" >>
