Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates
 64.18.1.77 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Tue, 16 Apr 2013 13:31:02 -0700
Subject: Re: Plugman future branch work + update
Thread-Topic: Plugman future branch work + update
Thread-Index: Ac464VJf623UqgY2TzmlCCMvox47hg==
Message-ID: <CD93023F.1D13D%fil@adobe.com>
In-Reply-To: 
 <CABiQX1UpKtktvbd5D_z_R+Wj6UDKX4rpEjHtwp7wELFwSk5tFw@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

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