cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: cordova-cli plugin add/remove/prepare proposal
Date Wed, 27 Feb 2013 22:26:31 GMT
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