On Wed, Apr 23, 2014 at 1:51 PM, Gorkem Ercan <gorkem.er...@gmail.com> wrote: > 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>
Definitely useful to have at runtime. Currently app-harness tacks them onto cordova_plugins.js in an ugly way! I don't think they could be merged, because the app developer doesn't actually know the name="value" part, only the plugin does. E.g. what you'd actually see in top-level config.xml is: <feature> <param name=“id” value=“org.apache.cordova.console” /> <param name=“version” value=“0.2.7” /> </feature> or maybe: <feature name="org.apache.cordova.console"> <param name=“version” value=“0.2.7” /> </feature> or maybe: <feature name="org.apache.cordova.console@0.2.7" /> But the point is, the name="" attribute that you see in the platform config.xml is a token that us used in the bridge, and is known only by the plugin. > > > >> 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" >> > >> >> > >>
