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"
> >>>
>

Reply via email to