Well, not my friends as much as my colleagues, but many, many of us are experiencing this. There was someone who wasn't a colleague of mine, Jason I think was his name, who complained about this a week or so ago as well. He logged a ticket on it as well.
John M. Wargo SAP | Charlotte, NC | USA Office: +1 704.321.0265 | Mobile: +1 704.249.7476 Email: john.wa...@sap.com Twitter: @johnwargo -----Original Message----- From: Filip Maj [mailto:f...@adobe.com] Sent: Wednesday, July 24, 2013 4:15 PM To: dev@cordova.apache.org Subject: Re: Consistent lazy Load problems It's mind-boggling that this is only an issue for your circle of friends, John :) Anyways, the patch looks good, and I commented as much on JIRA but will mention it here too: I will integrate that patch as soon as I can get a CLA from your colleague who wrote it up. Appreciate your patience and help thus far! On 7/24/13 1:09 PM, "Wargo, John" <john.wa...@sap.com> wrote: >I'm not sure we need a separate environment variable when git and npm >both already have their own proxy settings. A colleague of mine threw >together some code for using the existing settings, seems to me that this >is the best way to go. I posted his code to >https://issues.apache.org/jira/browse/CB-4322. > >Still need to code the CLI to recover more gracefully when the lazy load >doesn't work. It also needs to identify more clearly what failed so we >can better troubleshoot it. > >Please let me know how I can help. I'm happy to test away on this since >this has been killing me for the last few weeks. > >John M. Wargo >SAP | Charlotte, NC | USA >Office: +1 704.321.0265 | Mobile: +1 704.249.7476 >Email: john.wa...@sap.com >Twitter: @johnwargo > >-----Original Message----- >From: Filip Maj [mailto:f...@adobe.com] >Sent: Wednesday, July 24, 2013 2:24 PM >To: dev@cordova.apache.org >Subject: Re: Consistent lazy Load problems > >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" <csantan...@gmail.com> 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-authentic >>a >>tion-proxy-on-windows >> >>--Carlos >> >> >>On Wed, Jul 24, 2013 at 11:16 AM, Wargo, John <john.wa...@sap.com> 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 >><csantan...@gmail.com> >
