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