Thanks for bringing this up John. It's filed as CB-4322 and I will get to it as soon as I can.
On 7/24/13 8:56 AM, "Carlos Santana" <[email protected]> wrote: >Maybe putting proxy information some where > ~/.cordova/config.json >or npmrc >or enviroment variable `http_proxy` > >what about handling proxy authentication? >proxy = http://domain\\username:password@ip:port >or >proxy = http://username:password@ip:port > >reference: >http://superuser.com/questions/347476/how-to-install-npm-behind-authentica >tion-proxy-on-windows > >--Carlos > > >On Wed, Jul 24, 2013 at 11:16 AM, Wargo, John <[email protected]> wrote: > >> For weeks now I've been working with the CLI as it goes from version to >> version and a few weeks back a problem arose where the lazy load of the >> default www project fails or the lazy load of the Android or iOS >>project. >> I've documented this repeatedly, my most recent JIRA ticket is here: >> https://issues.apache.org/jira/browse/CB-4322. >> >> What's happening is that the CLI is trying to download an archive for >>some >> of the files it needs, but fails somehow. Using -d I can tell a little >>more >> about what is happening, but it is not always clear why its failing. I'm >> not sure if the download is not happening or the extraction of the >>download >> is failing, but the end result is that the CLI thinks it already has the >> files it needs (when it actually doesn't) because the folder it's >>looking >> for already exists. >> >> The CLI needs to report whether or not it is able to download the files >> and/or report that it's failing on the extraction - then act >>accordingly. >> Checking to see if the folder exists is not a valid check in this case >>as >> if the lazy load fails, the folder the CLI is checking for still exists >>- >> which breaks the process and leaves the CLI in an unworkable state. The >> target folder should not be created (or it should be deleted on fail) >> unless the files have been extracted to it. >> >> This particular problem is affecting my entire team, there are many of >>us >> here being affected by this. I thought at first that this must be a >>proxy >> problem, but I've now gotten back to my home office and I'm experiencing >> the exact same problem on my Mac Mini which isn't using a proxy and has >>no >> proxy settings. I've experienced this problem on our company network as >> well as in two different hotel networks and now my home office network. >> This is with three different computers on 4 different networks. >> >> On my MacBook and my windows laptop, I've configured npm and git with >>the >> appropriate proxy settings for my work network to no avail. With or >>without >> the settings, it fails. >> >> Two of my colleagues (in England and Germany) are experiencing the same >> problems; they're on different networks and have different proxy >>servers. >> They were able to get around this by manually forcing the proxy setting >>in >> the lazyload.js file: >> >> request.get({uri:url, proxy:'http://some_proxy_server:8080'}, >> function(err, req, body) { size = body.length; }) >> >> I would prefer to not have to modify the code to make this work. >> Unfortunately, the end result is our developers are ready to give up on >>the >> CLI since we can't make it work reliably simply for creating new >>projects >> or adding platforms to existing projects (both use lazy load). >> >> Is there a recommended fix for this? Anything I can do to help document >> this better? >> >> John M. Wargo >> Twitter: @johnwargo >> >> > > >-- >Carlos Santana ><[email protected]>
