Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.183 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Wed, 24 Jul 2013 13:15:21 -0700
Subject: Re: Consistent lazy Load problems
Thread-Topic: Consistent lazy Load problems
Thread-Index: Ac6IqojfYnxriWxYT4KM+FDXEi0zoA==
Message-ID: <CE1583BD.22E2E%fil@adobe.com>
In-Reply-To: 
 <5900F9BCB827854FB01CA94BA718810D0D218A42@USPHLEMB11A.global.corp.sap>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.5.130515
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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.wargo@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.wargo@sap.com
>Twitter: @johnwargo
>
>-----Original Message-----
>From: Filip Maj [mailto:fil@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" <csantana23@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 =3D http://domain\\username:password@ip:port
>>or
>>proxy =3D 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.wargo@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 =3D 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
>>>
>>>
>>
>>
>>--=20
>>Carlos Santana
>><csantana23@gmail.com>
>