cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Looking for input on syntax to use for specifying plugin deps in config.xml
Date Wed, 23 Apr 2014 14:03:23 GMT
Jesse, while the config.xml's share the same name, I think that
input/output argument is invalid.  All of: defaults.xml, plugin.xml, and
application level config (sadly named config.xml) are all inputs with
slightly different specs that produce several platform level configs (named
config.xml) also with a slightly different spec.

The fact that the project level config.xml uses <feature/> tag is a valid
argument to consider (I hadn't considered it), I just wanted to correct the
specific reasoning since I think this naming situation bites us repeatedly
into making mistakes.

-Michal


On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage <purplecabbage@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.ercan@gmail.com>
> wrote:
> >
> >> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <agrieve@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.kadri@gmail.com>
> wrote:
> >>> I prefer <feature>.
> >>>
> >>>
> >>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <kamrik@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 <mmocny@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"
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message