cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Al Harding <alharding...@gmail.com>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Wed, 27 Feb 2013 23:26:04 GMT
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
> > >> >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message