Responses in-line below. On 1/15/13 1:35 PM, "Andrew Grieve" <agri...@chromium.org> wrote:
>Okay, I'm feeling the need to reboot a bit on this. I'd like to think this >through in terms of cordova-cli commands. > >First thing I'd like to clarify is where things go when we run "cordova >platform add" vs "cordova plugin add"? >I *think* currently how it works is that "cordova platform add ios": >- Downloads cordova-ios (either from git or from a tar) into a cached >location: "cordova-cli/lib" >- Runs cordova-cli/lib/cordova-ios/bin/create project-path/platforms/ios >com.company.app AppName > >Is this correct? Yes. >Now, what are the plans for "cordova plugin add"? Will it: >- Download the plugin source to "cordova-cli/lib" as well? Or does it put >it in project/plugins? Puts the plugin source under the ./plugins directory of your project dir. >Once it's downloaded the source, FYI it may download but it doesn't have to if you point it to a local path. > it uses plugman to copy source files into >project/platforms/ios. How does "cordova plugin remove" work? Does it rely >on the original plugin.xml file to tell it which files to delete? or does >it write a manifest when it installs the plugin? It also uses plugman to do removal (plugman does both). I'm not sure how plug man does it, but I think yes, it uses plugin.xml to reverse the operations that an install would do. >I remember hearing that there were plans to use npm to install plugins, >but >looking at the docs, npm doesn't support installing to directories other >than node_modules. Do we still plan to use this? Maybe just let it install >into node_modules and then move them out of there? Maybe we have a >project/plugins/node_modules directory? I'm not sure. Max Ogden wrote one that uses npm. We are going with a manifest + tool route separate from npm. The discovery of plugins may use NPM, though. >Here's the cordova-packager workflow. The lines suffixed with *** are the >ones that are different from existing cordova-cli behaviour: > >"cordova project create": >- Creates project template > >"cordova platform add ios" >- Downloads cordova-ios (either from git or from a tar) into >cordova-cli/lib >- Since this is the first platform being added, this will trigger a >similar >download of cordova-js into cordova-cli/lib >- Runs cordova-ios/bin/create platforms/ios com.company.app AppName >- Copy cordova-cli/lib/cordova-js --> project/platforms/cordova-js *** >- Removes platforms/ios/www > >"cordova plugin add file" >- Download plugin files >- copy scripts listed in plugin.xml into >platforms/cordova-js/lib/$COMMON_OR_PLATFORM/plugin/$PLUGIN_NAME/... *** > >"cordova build": >- run cordova packager for the added platforms. *** >- copy resulting JS into platform/www directories. > > >Notes about this workflow: >-The only change to the require paths (and cordova-js directory structure) >in the workflow is the addition of the plugin-name directory under >lib/common/plugin. >-This should be pretty easy to debug since it's just automating the dev. >workflow >-This will eliminate the need to commit pre-built .js files into platform >repos. >-This will make it easier to have projects that build against >cordova-js/master since it doesn't require pre-built .js files. > > > >Here's the "prebuild things" workflow. The lines suffixed with *** are the >ones that are different from existing cordova-cli behaviour: > >"cordova project create": >- Creates project template > >"cordova platform add ios" >- Downloads cordova-ios (either from git or from a tar) into >cordova-cli/lib >- Runs cordova-ios/bin/create platforms/ios com.company.app AppName >- Removes platforms/ios/www > >"cordova plugin add file" >- Download plugin files >- copy script listed in plugin.xml into >platforms/ios/plugin-js/file-ios.js > >"cordova build": >- copy prebuilt cordova.ios.js from platforms/ios/CordovaLib -> >platforms/ios/www/cordova.js >- concat platforms/ios/plugin-js/* into >platforms/ios/www/cordova-plugins.js > > >Notes about this workflow: >-Then change to the require path will be more significant. Maybe >"cordovaplugin/file/Entry" >-We would need to build and commit each plugin's .js file >-Packaging within the plugin when developing may have to be done either >way >in order to run its unit tests. >-This eliminates the need to download the cordova-js repo, but does >require >that each platform have a pre-built version of cordova.js in them. >-In order to run against cordova-js/master, you'll have to manually build >the .js file and clobber platform/ios/CordovaLib/cordova.ios.js. >-Changes to the packager will mean having to re-build all plugins, or >remaining backwards-compatible with plugins built with old packager >versions > > > > >How we deal with mapping module -> symbol is tangental (I think) to which >approach we take. My guess to this is to have cordova-cli record a list of >all plugins that it has installed, and for each plugin to have a >symbols.js >file that will provide this info. If there is a dependency from one plugin >on another, then it can require() the other plugin's symbols file to >ensure >that it gets loaded first. > > > >Phew! so, lots of questions & suggestions in there. I'm less sure than >ever >as to which approach is better, although I think I'm somewhat leaning >towards the second one now instead of the first one. > > >I'm going to hold off on moving any files around until we get a better >grasp on this. Instead, I think I'll first work on creating a symbols.js >file for each plugin. Sounds good. > > > > > > > > > > > > > > > > > > >On Mon, Jan 14, 2013 at 8:40 PM, Jesse <purplecabb...@gmail.com> wrote: >> >> >> Where do you see it overwriting things? I see a few clobbers / merges >>> >> ... >> Sorry, off topic ... >> >> >> Are you sure? I just tested this ... >> Yeah, I was wrong about cordova.plugin, I thought I saw it somewhere, >>but >> indeed, they are destroyed when bootstrapped. >> One thing I did notice is that our API does not have a method to state >that >> for example, >> "cordova/plugin/accelerometer" needs to be mapped to >> navigator.accelerometer, although I am not sure this should be the job >>of >> the 'define' function. Still chewing on this ... >> >> >> On Mon, Jan 14, 2013 at 1:42 PM, Andrew Grieve <agri...@chromium.org> >wrote: >> >> > Are you sure? >> >> >> >> >> >> -- >> @purplecabbage >> risingj.com
