We've already had a discussion about this very topic in the past [1]. The reason why I prefer <feature> is because it's already used in platforms. Therefore it would be the right path towards having a unique top-level config.xml and platforms as true build artifacts. On iOS and Android plugins are loaded on demand and <feature> tags that don't have a matching native implementation (ie JS-only plugins) should just get ignored. I actually don't care as much about IDE support or W3C spec conformity.
[1] http://callback.markmail.org/message/fydyv7gh47odpemk?q=list:org%2Eapache%2Eincubator%2Ecallback-dev+app+harness+%3Cfeature%3E On Wed, Apr 23, 2014 at 10:58 AM, Andrew Grieve <agri...@chromium.org>wrote: > 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" > >> > >> > >> > > >> >
