Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.21 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Tue, 16 Apr 2013 14:39:19 -0700
Subject: Re: Plugman future branch work + update
Thread-Topic: Plugman future branch work + update
Thread-Index: Ac466tv4/wYf31fmTR6LB3o5X0wFbQ==
Message-ID: <CD93130D.1D155%fil@adobe.com>
In-Reply-To: 
 <CANpVHHzVcDvXNEgq2unj=5eY400nrJq6T8u=7hH-s4dQcFPYEA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Yay wiki is back up so I will summarize this stuff in a new article there

On 4/16/13 2: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.
>> >> >
>> >> >
>> >>
>>
>>