cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Thu, 07 Mar 2013 19:21:59 GMT
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