cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Plugman future branch work + update
Date Tue, 16 Apr 2013 21:29:35 GMT
I like fil's proposal. Either way, I don't think it should be an error, it
should just be a warning. If if it's an error then when you have n
platforms and one is not supported some of them might not get the plugin
because one of them didn't get it (because unsupported).


On Tue, Apr 16, 2013 at 1:31 PM, Filip Maj <fil@adobe.com> wrote:

> 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" <agrieve@chromium.org> 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
> ><purplecabbage@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 <braden@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 <fil@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 <fil@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.
> >> >
> >> >
> >>
>
>

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