cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wargo, John" <>
Subject RE: Consistent lazy Load problems
Date Wed, 24 Jul 2013 20:09:05 GMT
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

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
Twitter: @johnwargo

-----Original Message-----
From: Filip Maj [] 
Sent: Wednesday, July 24, 2013 2:24 PM
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" <> 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
>proxy = http://username:password@ip:port
>On Wed, Jul 24, 2013 at 11:16 AM, Wargo, John <> 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
>> I've documented this repeatedly, my most recent JIRA ticket is here:
>> What's happening is that the CLI is trying to download an archive for
>> of the files it needs, but fails somehow. Using -d I can tell a little
>> 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
>> 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
>> 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
>> Checking to see if the folder exists is not a valid check in this case
>> 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
>> here being affected by this. I thought at first that this must be a
>> 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
>> 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
>> appropriate proxy settings for my work network to no avail. With or
>> 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
>> They were able to get around this by manually forcing the proxy setting
>> 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
>> CLI since we can't make it work reliably simply for creating new
>> 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

View raw message