Gorkem has an initial implementation posted here: https://github.com/apache/cordova-cli/pull/165 -- but its missing a change previously discussed to support explicit "cordova restore" instead of auto-restore-on-prepare. He also made us a video: https://www.youtube.com/watch?v=bc60WAQdOjE
The syntax for deps in that patch currently uses <feature> tags and looks like this: <feature name=“Console”> <param name=“id” value=“org.apache.cordova.console” /> <param name=“version” value=“0.2.7” /> </feature> Whereas plugin.xml <dependency> tags look like: <dependency id="org.apache.cordova.file" version="1.0.1" /> And the current platform config.xml feature tags look like: (note the caveat Andrew mentions that these are intended to solve a different problem) <feature name=“Console”> <param name="ios-package" value="CDVConsole" /> </feature> Food for thought. -Michal On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <purplecabb...@gmail.com>wrote: > 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" > >> >
