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 17:26:22 GMT
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>

Food for thought.

-Michal

On Wed, Apr 23, 2014 at 12:19 PM, purplecabbage <purplecabbage@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 <mmocny@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" <agrieve@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 <
> 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