cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: <plugins> tag, and accessing the plugin list
Date Wed, 13 Nov 2013 19:54:56 GMT
Adding this to iOS and Android only is kind of mean.  What ends up
happening is the high profile platforms (ie. the ones that get ALL the
attention) get a new feature and the others 'appear' to be behind.  I think
we should focus on remaining consistent to some degree, otherwise you end
up just making more work for the other platform developers.

This does not seem like it would be hard for you to implement on windows
phone and blackberry as well, and having you spend a few minutes in those
platforms would probably be a good thing anyway.

I too am also not sure why the existing feature tag in config.xml is not
enough.



@purplecabbage
risingj.com


On Wed, Nov 13, 2013 at 11:38 AM, Gorkem Ercan <gorkem.ercan@gmail.com>wrote:

> Hey Braden,
> Why is not the current <feature> tags sufficient for this?
> --
> Gorkem
>
>
> On Wed, Nov 13, 2013 at 2:32 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Hey folks,
> >
> > We've been kicking around the idea of getting at which plugins/versions
> are
> > installed, at runtime. In order to make that happen, I've taken the first
> > step of having plugman prepare insert a tag into config.xml for each
> > plugin. It will look like this:
> >
> > <plugins>
> >   <plugin id="org.apache.cordova.file" version="0.2.5" />
> >   <plugin id="org.apache.cordova.file-transfer" version="0.3.4" />
> > </plugins>
> >
> > NB that Plugman is injecting this automatically, and this tag should NOT
> > appear in the plugin.xml's <config-file> tags.
> >
> > Now I'll be adding logic to the config.xml parser on Android and iOS, but
> > other platform maintainers will have to step in for the other platforms.
> >
> > Tracking the progress here:
> https://issues.apache.org/jira/browse/CB-5379
> >
> > (If you're wondering why we have motivation for this, it's to make the
> > AppHarness more informative, and more robust, by warning the user when an
> > app they've installed is looking for plugins the harness can't provide,
> or
> > where versions mismatch.)
> >
> > Braden
> >
>

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