cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lucas Holmquist <lholm...@redhat.com>
Subject Re: Plugman future branch work + update
Date Wed, 17 Apr 2013 12:49:56 GMT
I like this idea,  the user might be confused if nothing happens if a plugin isn't compatible.

+ 1 for a Warning

On Apr 16, 2013, at 5:29 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> 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
View raw message