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 Thu, 28 Feb 2013 00:42:26 GMT
...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.
>

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