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 purplecabbage@gmail.com
 designates 209.85.220.178 as permitted sender)
References: 
 <CABiQX1X+hRKP35hhr76_5eeXDijR5D9gTVGfDr9hFheAgkQjhQ@mail.gmail.com>
 <CD92EC13.1D11C%fil@adobe.com>
 <CAMk5LLnhQh7pCr3JjrVLk2zgmcZGuaFbxAjndA9-FwhUs3s4nw@mail.gmail.com>
From: Jesse MacFadyen <purplecabbage@gmail.com>
In-Reply-To: 
 <CAMk5LLnhQh7pCr3JjrVLk2zgmcZGuaFbxAjndA9-FwhUs3s4nw@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Date: Tue, 16 Apr 2013 12:29:21 -0700
Message-ID: <7310490772218074272@unknownmsgid>
Subject: Re: Plugman future branch work + update
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

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