On Wed, Apr 23, 2014 at 1:26 PM, Michal Mocny <mmo...@chromium.org> wrote:
> 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> > > One could merge the params as below, if one day we actually have a single config.xml file. Although id and version are planned to be used at the build time at the moment I think something like app harness could appreciate their existence at the runtime. <feature name=“Console”> <param name="ios-package" value="CDVConsole" /> <param name=“id” value=“org.apache.cordova.console” /> <param name=“version” value=“0.2.7” /> </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" > > >> > > >
