cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Fri, 08 Mar 2013 18:20:54 GMT
Here's the hangout link!

https://plus.google.com/hangouts/_/d769196db4691ea063c6787c6d660719e021e594
?authuser=0&hl=en


On 3/7/13 11:21 AM, "Jesse" <purplecabbage@gmail.com> wrote:

>Do we have a time set for this?
>I won't be able to attend in person, but I will be in the hangout.
>
>Cheers,
>  Jesse
>
>On Wed, Feb 27, 2013 at 4:42 PM, Al Harding <alharding600@gmail.com>
>wrote:
>
>> ...and the BlackBerry guys! :)
>>
>>
>>
>> On Wed, Feb 27, 2013 at 4:37 PM, Jeffrey Heifetz <jheifetz@rim.com>
>>wrote:
>>
>> > 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.
>> >
>>
>
>
>
>-- 
>@purplecabbage
>risingj.com


Mime
View raw message