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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 > >> >> ><[email protected]>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 > >> >> >> > >> >> > >> >> > >> > >> > >
