To be clear: we are talking about plugman as functionality on its own. Understandably the CLI will consume plugman and thus this is a good behavior to make explicit.
So, how about this: if you specify installing a plugin into a platform it doesn't support, the user will be WARNED, but plugman will not "error" out per se (I.e. Will exit with code 0). On 4/16/13 12:36 PM, "Andrew Grieve" <[email protected]> wrote: >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 ><[email protected]>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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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. >> > >> > >>
