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