A poor man's symlink ;) On 7/4/13 11:08 AM, "Anis KADRI" <anis.ka...@gmail.com> wrote:
>Oh that kinda symlinks :-) > > >On Thu, Jul 4, 2013 at 2:00 PM, Filip Maj <f...@adobe.com> 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" <anis.ka...@gmail.com> 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 <mmo...@chromium.org> >>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 <f...@adobe.com> 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" <mmo...@chromium.org> wrote: >> >> > >> >> > >On Wed, Jul 3, 2013 at 1:13 PM, Tyler Wilson >> >> > ><twil...@pulse-robotics.com>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 >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> >> >>
