cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorin Beer <lorin.beer....@gmail.com>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Fri, 08 Mar 2013 20:07:03 GMT
Thanks! Will try to drop in once I'm stationary


On Fri, Mar 8, 2013 at 10:20 AM, Filip Maj <fil@adobe.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message