cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Heifetz <jheif...@rim.com>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Thu, 28 Feb 2013 00:37:32 GMT
Actually I'm lucky enough to be heading down to join in on the fun, looking forward to meeting
all of you.

On 2013-02-27, at 6:26 PM, Al Harding wrote:

> Awesome! We've got a room booked at Adobe SF with projector, camera, beer,
> so we can loop anyone in who is remote.
> 
> Look forward to meeting the Google guys!
> 
> -Al
> 
> 
> 
> 
> On Wed, Feb 27, 2013 at 2:44 PM, Michal Mocny <mmocny@chromium.org> wrote:
> 
>> Oh sweet, we were just saying how we still haven't met most of you.
>> 
>> Sadly, Braden is not coming on this trip, but Andrew, Max and I will be
>> there (and working from Adobe Friday) we will have time to chat.  Can bring
>> Braden in via Hangout.
>> 
>> -Michal
>> 
>> 
>> On Wed, Feb 27, 2013 at 5:40 PM, Filip Maj <fil@adobe.com> wrote:
>> 
>>> Yep! There's an online code review planned for March 22nd for both the
>> cli
>>> tools as well as the plugman tool.
>>> 
>>> Also: next week most Adobe cordova folk will be in SF, and so will you
>>> Googlers ya? We can talk specifics and hash out our ideas better then and
>>> bring it back to the list.
>>> 
>>> On 2/27/13 2:26 PM, "Michal Mocny" <mmocny@chromium.org> wrote:
>>> 
>>>> I think we have a hangout scheduled for that conversation (among others)
>>>> right?  Its good that Braden is setting up topics of conversation :)
>>>> 
>>>> -Michal
>>>> 
>>>> 
>>>> On Wed, Feb 27, 2013 at 4:37 PM, Filip Maj <fil@adobe.com> wrote:
>>>> 
>>>>> I think this is a good conversation to have.
>>>>> 
>>>>> Note that, if we do split up how plugins are treated and when we copy
>>>>> files around (I.e. Move the www assets on every prepare, but the
>> native
>>>>> files only on platform/plugin adds), then the plugman tool will either
>>>>> need finer-grained support for these types of actions or we need to
>>>>> assimilate/couple the plugman code closer to cordova-cli.
>>>>> 
>>>>> On 2/27/13 1:32 PM, "Braden Shepherdson" <braden@chromium.org>
wrote:
>>>>> 
>>>>>> I'm on the fence about native plugin code. I think iOS has some
>>>>>> complications there.
>>>>>> 
>>>>>> Over the course of my work on the installation prototype, I've
>> actually
>>>>>> moved to copying plugin www files on every prepare, that works great.
>>>>>> 
>>>>>> For native code, I wonder if that's best done on add/remove. I was
>>>>> mostly
>>>>>> thinking about www files for the original proposal.
>>>>>> 
>>>>>> Braden
>>>>>> 
>>>>>> 
>>>>>> On Wed, Feb 27, 2013 at 4:24 PM, Filip Maj <fil@adobe.com>
wrote:
>>>>>> 
>>>>>>> Couple notes before I add some comments:
>>>>>>> 
>>>>>>> - in general plugin add and rm is COMPLETELY delegated to the
>> plugman
>>>>>>> tool. See [1]. Most of the code linked is error checking, otherwise
>>>>> it
>>>>>>> shells out to plugman.. With one exception..
>>>>>>> - what happens in [2]. Which is the point Braden brought up about
>>>>>>> polluting the user's www. Totally agree this should change. At
the
>>>>> time
>>>>>>> of
>>>>>>> writing that I dropped a TODO [3] that this was a likely bad
>>>>> assumption.
>>>>>>> - the "what plugins are installed" code is already a `ls plugins/`
>>>>> run
>>>>>>> [4].
>>>>>>> 
>>>>>>> Now going back to your proposal:
>>>>>>> 
>>>>>>> 1. Never pollute user's www. I completely agree with this. Time
to
>>>>>>> refactor that out.
>>>>>>> 2. Use existence of directories under the ./plugins dir to identify
>>>>>>> which
>>>>>>> plugins are installed. Yep. Already does that as shown in [4].
>>>>>>> 
>>>>>>> If I understand correctly, you are proposing we run a plugin
>>>>>>> installation
>>>>>>> (I.e. Copy over appropriate files and edit config files) every
time
>>>>>>> cordova prepare is run. This would mean that every time we run
>>>>> prepare,
>>>>>>> we
>>>>>>> have to recreate a native cordova project (otherwise we'd be
>>>>> installing
>>>>>>> plugin files into the native project on every command). I'm not
>> sure
>>>>> I
>>>>>>> agree with this.. I have to think more about it..
>>>>>>> 
>>>>>>> I think this conversation boils down to: should we be recreating
>>>>> cordova
>>>>>>> projects on every command, or keep the native projects "persistent"
>>>>>>> across
>>>>>>> commands (which is currently how it operates).
>>>>>>> 
>>>>>>> [1]
>>>>> https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L72
>>>>>>> [2]
>>>>> https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L116
>>>>>>> [3]
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>> https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L117-L118
>>>>>>> [4]
>>>>>>> 
>>>>> 
>> https://github.com/apache/cordova-cli/blob/master/src/plugin.js#L51-L52
>>>>>>> 
>>>>>>> On 2/25/13 8:24 AM, "Michal Mocny" <mmocny@chromium.org>
wrote:
>>>>>>> 
>>>>>>>> Just to clarify this in my head:
>>>>>>>> 
>>>>>>>> * Since we have a prepare step now, you propose moving some
of the
>>>>>>> logic
>>>>>>>> that used to run on plugin add out into the prepare step.
 That
>>>>> sounds
>>>>>>>> good.
>>>>>>>> * You want to fix how we track which plugins are installed
by
>> going
>>>>> to
>>>>>>>> source instead of some config file.  That sounds good.
>>>>>>>> * You want to fix a bunch of stuff with the prepare step
>> (including
>>>>> the
>>>>>>>> current add logic).  I can't really comment on specifics
here,
>> but I
>>>>>>> guess
>>>>>>>> this is not as radical of a change as I thought on first
pass.
>>>>>>>> 
>>>>>>>> I briefly asked you offline but wanted to bring it into the
ML:
>> How
>>>>>>> does
>>>>>>>> this proposal affect our current plan for plugin upgrading?
 (Your
>>>>>>> answer,
>>>>>>>> paraphrasing, was that prepare step should ideally be stateless
>> and
>>>>>>> start
>>>>>>>> from any clean state.  Thus, upgrade is simply an rm &
add &
>>>>> prepare)
>>>>>>>> 
>>>>>>>> -Michal
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Feb 25, 2013 at 10:32 AM, Braden Shepherdson
>>>>>>>> <braden@chromium.org>wrote:
>>>>>>>> 
>>>>>>>>> I'm running into several problems with the current
>> implementation
>>>>> of
>>>>>>>>> cordova-cli:
>>>>>>>>> 
>>>>>>>>> * There's no single source of truth for what plugins
are
>>>>> installed.
>>>>>>> It
>>>>>>>>> uses
>>>>>>>>> the presence of a plugin's name in the www/config.xml
currently.
>>>>> This
>>>>>>>>> doesn't work for JS-only plugins, and there are some,
especially
>>>>> on
>>>>>>>>> other
>>>>>>>>> platforms.
>>>>>>>>> * It's polluting (maybe clobbering!) the user's www/
during
>> plugin
>>>>>>> add.
>>>>>>>>> * It expects plugins to have a www/ directory it copies
whole
>> into
>>>>>>> the
>>>>>>>>> top-level www/, rather than honouring <asset> tags
as per docs.
>>>>>>>>> 
>>>>>>>>> My proposal is to rewire cordova-cli according to two
>> principles:
>>>>>>>>> 
>>>>>>>>> 1. We never pollute the user's www/ with anything. Full
stop.
>>>>>>>>> Everything we
>>>>>>>>> do automagically goes into the platform directories at
cordova
>>>>>>> prepare
>>>>>>>>> time.
>>>>>>>>> 2. We use the existence of absence of directories in
plugins/ as
>>>>> the
>>>>>>>>> source
>>>>>>>>> of truth for what is or isn't installed.
>>>>>>>>> 
>>>>>>>>> Under this model, plugin add/rm become fancy aliases
for cp -R
>>>>> and rm
>>>>>>>>> -rf.
>>>>>>>>> No magic or copying of JS or native files or config editing
or
>>>>>>> anything
>>>>>>>>> else happens on plugin add: We just copy the directory
into
>>>>> plugins/.
>>>>>>>>> 
>>>>>>>>> Then on cordova prepare, we copy native files into the
>> platforms,
>>>>>>> edit
>>>>>>>>> platform-specific config files to include <plugin>
tags and
>>>>>>> permissions
>>>>>>>>> and
>>>>>>>>> list the native files.
>>>>>>>>> 
>>>>>>>>> iOS makes this hard, since it has a project file that
lists all
>>>>>>> native
>>>>>>>>> files in the project. We can get around this by putting
all
>> plugin
>>>>>>> files
>>>>>>>>> into a subdirectory like src/plugins. Then on cordova
prepare we
>>>>> can
>>>>>>> get
>>>>>>>>> every file in that directory, remove them from the project
file,
>>>>>>> delete
>>>>>>>>> them, then copy every plugin's native files and add them
to the
>>>>>>> project
>>>>>>>>> file. Then the project file always matches the current
load of
>>>>>>> plugins.
>>>>>>>>> 
>>>>>>>>> I'm volunteering to do the work required for this. I
just want
>> to
>>>>> run
>>>>>>>>> the
>>>>>>>>> idea past people before I start fundamentally changing
how the
>>>>> tool
>>>>>>>>> works.
>>>>>>>>> I think this will make many parts of the code simpler
to read
>> and
>>>>>>>>> document,
>>>>>>>>> and make the behavior of the tool much clearer and less
magical
>> to
>>>>>>>>> users.
>>>>>>>>> 
>>>>>>>>> Braden
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> 
>> 


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information by anyone other than the
intended recipient is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

Mime
View raw message