The main use-case is knowing at install time that your app isn't going to
work.
You're right though that there is a use-case for platform-specific plugins.
E.g. if (cordova.plugins.somePlugin) { .. use it ... } else { ... don't use
it ... }
Maybe a good first step is to issue a warning?
On Tue, Apr 16, 2013 at 3:29 PM, Jesse MacFadyen <purplecabb...@gmail.com>wrote:
> If you specify --platform ios for a plugin that does not support ios
> it should be an error.
>
> Cheers,
> Jesse
>
> Sent from my iPhone5
>
> On 2013-04-16, at 12:12 PM, Braden Shepherdson <bra...@chromium.org>
> wrote:
>
> Why do you want errors when a plugin doesn't support a platform? Currently
> this silently does nothing, and this is by design. Some plugins only
> support some platforms, and that's fine. It just won't install on the
> others it doesn't support.
>
> Braden
>
>
> On Tue, Apr 16, 2013 at 2:53 PM, Filip Maj <f...@adobe.com> wrote:
>
> >
> >> Would like errors about trying to add a platform / plugin when the
> plugin
> >> doesn't support the platform.
> >
> > Error out and stop, or warn about a mismatch?
> >
> >> Idea: Add all plugins & platforms to config.xml, so instead of having to
> >> type "cordova plugin/platform add ..." for all plugins & platforms, you
> >> can
> >> list them in your config.xml and type "cordova prepare". Might make it
> >> easier to specify what versions of all the plugins / platforms you want
> to
> >> use.
> >
> > We'd be bastardizing the config.xml even more with that, but it does get
> > us a step closer to treating everything outside of www/merges/app folder
> > as build artifacts.
> >
> >>
> >>
> >> On Tue, Apr 16, 2013 at 2:44 PM, Filip Maj <f...@adobe.com> wrote:
> >>
> >>> We will summarize baseline use cases for plugin management w.r.t.
> >>> dependencies on a wiki article (once wiki is usable again). From these
> >>> we
> >>> can write tests that will drive our implementation work. Failure points
> >>> we
> >>> already know are:
> >>>
> >>> - asset collisions for native code and non-js web assets. We error out
> >>> noisily.
> >>> - dependencies and requiring two different versions of same plugin.
> >>> Due
> >>> to some of the native language constraints (i.e. Java) we cannot
> >>> (easily)
> >>> support this, so we agreed that we do not support different versions of
> >>> the same plugin in the app, therefore: fail noisily.
> >>>
> >>> Based on the above + other use cases, we will write tests. Then we
> write
> >>> code to fix tests. Once tests pass, we merge future branch back into
> >>> master and we are ready to roll out plugman/plugin.xml support to the
> >>> public. Thoughts on what kind of documentation we should offer with
> >>> this?
> >>> At a minimum we will need to revamp the plugin authoring guide.
> >>>
> >>> Anis and Braden will be doing a similar sort of thing with Plugin
> >>> Discovery.
> >>>
> >>> In the mean time, any other use cases the group can think of in terms
> of
> >>> plugin management and what plugman should support, feel free to post
> >>> them
> >>> here.
> >
> >
>
