Oh that kinda symlinks :-)
On Thu, Jul 4, 2013 at 2:00 PM, Filip Maj <[email protected]> wrote: > Windows has symlinks, the "Shortcut" stuff. See [1]. > > And no, --link throws if you try to use with a URL. See [2]. > > [1] > http://nodejs.org/docs/v0.10.0/api/fs.html#fs_fs_symlink_srcpath_dstpath_ty > pe_callback > [2] https://github.com/apache/cordova-plugman/blob/master/src/fetch.js#L21 > > On 7/4/13 10:57 AM, "Anis KADRI" <[email protected]> wrote: > > >does --link work for URLs ? > > > >Also bad idea because no symlinks on Windoz. > > > > > >On Thu, Jul 4, 2013 at 1:40 PM, Michal Mocny <[email protected]> wrote: > > > >> Either way, I now think real symlinking is a bad idea. We currently > >>must > >> keep a copy of the files as they existed at "fetch" time so that we can > >>use > >> them for upgrade/uninstall. Symlinks break that. Conceptually, we > >>already > >> have "links" in that we remember the original source locations, and we > >> could improve the "prepare" step to add the ability to auto-upgrade all > >> plugins. > >> > >> Not sure if that is the best solution, but seems feasible. > >> > >> > >> On Thu, Jul 4, 2013 at 1:27 PM, Filip Maj <[email protected]> wrote: > >> > >> > The --link options actually exists in plugman, but it is only an > >>option > >> > for the `fetch` command. All it does is copy the plugin code from > >><your > >> > location or URL> to a plugins directory. With --link, instead it will > >> > symlink. It does not actually create symlinks for native or web plugin > >> > code. > >> > > >> > Would that even work, I wonder? For compiling, etc. > >> > > >> > On 7/3/13 10:32 AM, "Michal Mocny" <[email protected]> wrote: > >> > > >> > >On Wed, Jul 3, 2013 at 1:13 PM, Tyler Wilson > >> > ><[email protected]>wrote: > >> > > > >> > >> Good day, > >> > >> > >> > >> Just wanted to publicise that I have had success with the cli, a > >> custom > >> > >> plugin and an iOS build. I must say once everything is set up it is > >> > >>pretty > >> > >> nice being able to add/remove components and it appears to handle > >> things > >> > >> just fine. Just a couple notes: > >> > >> > >> > > > >> > >Awesome! > >> > > > >> > > > >> > >> > >> > >> - The default build created has two config.xml files in the > >>project (I > >> > >>am > >> > >> using Xcode) - one at the root, and one within the www folder. Is > >>this > >> > >> expected? > >> > >> > >> > > > >> > >This is expected, but not desired. It is a result of us having a > >> > >config.xml inside your www/ folder and copying that whole folder on > >> > >prepare. For now, if you can add it to your workflow, I would remove > >> the > >> > >config.xml from "platforms/ios/www" after every "cordova prepare" > >> > > (actually, not removing it causes a race condition that rarely but > >> > >occasionally causes an app launch failure, so we will need to solve > >>this > >> > >issue upstream). > >> > > > >> > > > >> > >> > >> > >> - I was having issue installing my plugin with plugman. Then I > >> realized > >> > >> that the cordova cli command handles plugin installs and removal. > >>It > >> is > >> > >> confusing with many references to plugman. Perhaps there should be > >>a > >> > >> 'modern' Getting Started guide for the CLI version that also > >>installs > >> a > >> > >> plugin as an example? I have read this one - > >> > >> > >> > >> > >> > > >> > >> > http://cordova.apache.org/docs/en/2.9.0/guide_cli_index.md.html#The%20Cor > >> > >>dova%20Command-line%20Interface- but perhaps another matching one > >>for > >> > >>plugin developers? (And put a NOTE > >> > >> on this page about the issue with npm 1.3.x versionsŠ) > >> > >> > >> > > > >> > >Thanks for pointing that out. > >> > > > >> > > > >> > >> > >> > >> - I referenced this before, but I think an option to install a > >>plugin > >> > >>via > >> > >> symlinks would make development a lot easier, since in most cases > >>you > >> > >>will > >> > >> be editing the copy that was created during the install, not the > >> > >>original. > >> > >> I will do it manually for now of course. > >> > >> > >> > > > >> > >We discussed adding a --link option to plugin add before, but since > >>we > >> > >need > >> > >to have the original assets around in order to do proper install, I > >> think > >> > >the current plan was to support in-place upgrading (sorta like > >>cordova > >> > >prepare, but for plugins). Fil/Braden, maybe you can add more on > >>this. > >> > > > >> > >For now, (cordova plugin rm ... && cordova plugin add ...) as a form > >>of > >> > >in-place plugin upgrade works only for updating web assets at the > >> moment. > >> > > > >> > >As far as modifying the copy -- yes, during plugin development I do > >>that > >> > >too, its just a lot easier to get rapid iteration -- but after I'm > >>done > >> I > >> > >*do* copy those assets back out to the original location. Also, for > >> > >plugin > >> > >consumers, not the original authors, they will not be making changes > >>to > >> > >the > >> > >plugin copies. > >> > > > >> > > > >> > >> > >> > >> Great job everybody. > >> > >> > >> > >> Thank you, > >> > >> Tyler > >> > >> > >> > >> > >> > >> > >> > >> > >> > > >> > > >> > >
