This is certainly bizarre. I've verified that my local repo copy of the cordova-ios 4.0.x branch does have those modules, then ran "npm pack" on the repo folder (which coho create-archive calls):
---- [cordova-ios (4.0.x)]$ npm pack --verbose npm info it worked if it ends with ok npm verb cli [ '/Users/shazron/.nvm/versions/node/v0.12.7/bin/node', npm verb cli '/Users/shazron/.nvm/versions/node/v0.12.7/bin/npm', npm verb cli 'pack', npm verb cli '--verbose' ] npm info using npm@2.11.3 npm info using node@v0.12.7 npm verb cache add spec . npm verb addLocalDirectory /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz not in flight; packing npm verb tar pack [ '/Users/shazron/.npm/cordova-ios/4.0.0/package.tgz', npm verb tar pack '/Users/shazron/Documents/git/apache/cordova-ios' ] npm verb tarball /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz npm verb folder /Users/shazron/Documents/git/apache/cordova-ios npm info prepublish cordova-ios@4.0.0 npm verb addLocalTarball adding from inside cache /Users/shazron/.npm/cordova-ios/4.0.0/package.tgz npm verb afterAdd /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json not in flight; writing npm verb afterAdd /Users/shazron/.npm/cordova-ios/4.0.0/package/package.json written cordova-ios-4.0.0.tgz npm verb exit [ 0, true ] npm info ok --- After expanding the .tgz I found that the modules mentioned are *not* there, but I don't know why. However, when I check out a fresh copy of cordova-ios and "npm pack" the 4.0.x branch there, the modules *are* there in the .tgz! Chalk this one up to the C-Files (cue X-Files theme). On Mon, Dec 7, 2015 at 6:05 PM, Carlos Santana <csantan...@gmail.com> wrote: > Currently finding a discrepancy when recreating the archive > > The tgz dist/ [1] is missing 3 node modules, they are located in git [2] > Running the command coho create-archive --tag 4.0.0 -r ios --dest test-ios4/ > I ran with npm@2.11.3 and npm@3.3.12 and was able to get all three in > expected location > > bin/node_modules/cordova-common/node_modules/glob > bin/node_modules/cordova-common/node_modules/q > bin/node_modules/ios-sim/node_modules/nopt > > [1]: > https://dist.apache.org/repos/dist/dev/cordova/CB-10147/cordova-ios-4.0.0.tgz > [2]: https://github.com/apache/cordova-ios/tree/4.0.0/bin/node_modules > > > > > On Mon, Dec 7, 2015 at 7:12 PM Carlos Santana <csantan...@gmail.com> wrote: > >> Currently working on it... >> >> - Carlos >> @csantanapr >> >> > On Dec 7, 2015, at 6:50 PM, Steven Gill <stevengil...@gmail.com> wrote: >> > >> > both ios@4 and cordova-plugin-wkwebviewengine need 1 more vote. Someone >> > step up so Shaz can wrap up the vote threads and publish these! >> > >> >> On Fri, Dec 4, 2015 at 2:07 PM, Carlos Santana <csantan...@gmail.com> >> wrote: >> >> >> >> +1 >> >> >> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron <shaz...@gmail.com> wrote: >> >>> >> >>> After working out some bridge improvements and fixing some Platform >> >>> API bugs and testing, I believe it's ready. I'll start a [VOTE] thread >> >>> soon. >> >>> >> >>> On Thu, Dec 3, 2015 at 5:19 PM, Carlos Santana <csantan...@gmail.com> >> >>> wrote: >> >>>> +1 let's move forward this items with WKWebview I don't see holding up >> >>> the >> >>>> platform. >> >>>> >> >>>> Don't see any changes going on the platform, if any they will go into >> >> the >> >>>> pluggable webview plugin or creating new plugin to handle. >> >>>>> On Wed, Dec 2, 2015 at 8:40 PM Shazron <shaz...@gmail.com> wrote: >> >>>>> >> >>>>> Regarding Platform API, Vladimir Kotikov and Sergey Grebnov agree in >> >>>>> the PR comments that the changes can go in to cordova-ios-4.x: >> >>>>> https://github.com/apache/cordova-ios/pull/176 >> >>>>> >> >>>>>> On Wed, Dec 2, 2015 at 5:38 PM, Shazron <shaz...@gmail.com> wrote: >> >>>>>> Also, check footnote 3 above. >> >>>>>> >> >>>>>> Yes, WebKit defines window.openDatabase but it doesn't do anything. >> >>>>>> Not sure why their tests didn't catch this... (see footnote for the >> >>>>>> bug) >> >>>>>> >> >>>>>> With CSP off to rule things out: >> >>>>>> XHR to yourself of course works, but doesn't really make sense for >> >>>>>> real-world use. XHR to a sibling file, parent file, or any child >> >> file >> >>>>>> results in the error ""Cross origin requests are only supported for >> >>>>>> HTTP”. >> >>>>>> >> >>>>>> To illustrate: >> >>>>>> >> >>>>>> | >> >>>>>> parent.xml >> >>>>>> | >> >>>>>> www >> >>>>>> |---- index.html (file currently loaded) >> >>>>>> |---- sibling.xml >> >>>>>> |---- child-folder >> >>>>>> | |---- child.xml >> >>>>>> >> >>>>>> index.html is the currently loaded file in the WebView. From it, you >> >>>>>> can't load parent.xml, sibling.xml nor child.xml using XHR according >> >>>>>> to my tests. >> >>>>>> >> >>>>>> Regarding *why* we have these storage tests, that is out of scope >> >> for >> >>>>>> this discussion, but I agree. >> >>>>>> >> >>>>>> >> >>>>>> On Wed, Dec 2, 2015 at 6:37 AM, Carlos Santana < >> >> csantan...@gmail.com> >> >>>>> wrote: >> >>>>>>> I'm guessing "pending" is the same as skipping the test. >> >>>>>>> I'm guessing WKWebView doesn't support Web SQL, but >> >>> window.openDatabase >> >>>>>>> exist but it doesn't do anything? >> >>>>>>> I ask because I only saw the pending for wkwebview spec.18 for >> >> using >> >>> it, >> >>>>>>> not for spec.9 where it checks that exists. >> >>>>>>> Anyway after all questions, why the we are still testing for >> >> storage >> >>>>> APIs? >> >>>>>>> Cordova doesn't supported code to provide this storage APIs. >> >>>>>>> I think we should remove the storage tests all together, this is >> >>>>>>> webview/browser testing space. >> >>>>>>> >> >>>>>>> As for local xhr, is the problem only with specifying "../" >> >> relative >> >>>>> path >> >>>>>>> in the xhr url and not local resources? >> >>>>>>> I see that doing xhr "index.html" that's a local resource and it >> >>> works, >> >>>>> and >> >>>>>>> also "./" also passes. >> >>>>>>> Aren't all this relative paths transform into full urls, and they >> >>> will >> >>>>> have >> >>>>>>> file:// in the final path used? >> >>>>>>> This means that xhr "folder1/data.json" works, but xhr >> >>>>>>> "../someparent/data.json" doesn't? >> >>>>>>> >> >>>>>>> >> >>>>>>>> On Wed, Dec 2, 2015 at 4:52 AM Shazron <shaz...@gmail.com> wrote: >> >>>>>>>> >> >>>>>>>> Marked the two known failures as pending. Now everything is green >> >>> (and >> >>>>>>>> yellow) across the board for UIWebView and WKWebView. >> >>>>>>>> >> >>>>>>>> On Tue, Dec 1, 2015 at 11:49 PM, Jesse <purplecabb...@gmail.com> >> >>>>> wrote: >> >>>>>>>>>>> Or should I just let it fail still? >> >>>>>>>>> It depends how long it'll be until we fix them. The build will >> >> be >> >>>>> broken >> >>>>>>>>> in the CI until it is fixed so probably marking them as pending >> >> is >> >>>>> the >> >>>>>>>>> better option. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> @purplecabbage >> >>>>>>>>> risingj.com >> >>>>>>>>> >> >>>>>>>>> On Tue, Dec 1, 2015 at 10:42 PM, Shazron <shaz...@gmail.com> >> >>> wrote: >> >>>>>>>>> >> >>>>>>>>>> Couldn't wait. All file-transfer specs now pass for uiwebview >> >> and >> >>>>>>>>>> wkwebview. >> >>>>>>>>>> >> >>>>>>>>>> For those two WKWebView tests that are failing, but are >> >> expected >> >>> to >> >>>>>>>>>> fail -- I'll try to modify the tests to mark the test as >> >> pending >> >>> if >> >>>>>>>>>> the platform is iOS and the WKWebView bridge is found. >> >>>>>>>>>> >> >>>>>>>>>> Or should I just let it fail still? >> >>>>>>>>>> >> >>>>>>>>>> On Tue, Dec 1, 2015 at 9:49 PM, Shazron <shaz...@gmail.com> >> >>> wrote: >> >>>>>>>>>>> Thanks! - yeah after I posted it, of course I realized it is >> >>> all >> >>>>> open >> >>>>>>>>>>> source (duh) and I can run a local server or throw it on a >> >>>>>>>>>>> digitalocean instance or something :) >> >>>>>>>>>>> I'll do that tomorrow... >> >>>>>>>>>>> >> >>>>>>>>>>> On Tue, Dec 1, 2015 at 9:24 PM, Carlos Santana < >> >>>>> csantan...@gmail.com> >> >>>>>>>>>> wrote: >> >>>>>>>>>>>> For a second I read "the bar is clear", but then I went to >> >> my >> >>>>> fridge >> >>>>>>>> and >> >>>>>>>>>>>> saw I still have some beer left :-) >> >>>>>>>>>>>> >> >>>>>>>>>>>> How long before the INFRA provides the VM for the file >> >>> transfer, >> >>>>> I >> >>>>>>>>>> looked >> >>>>>>>>>>>> the JIRA and it mentioned something like "complete" and "we >> >>> are >> >>>>> in >> >>>>>>>>>> holding >> >>>>>>>>>>>> because of capacity" in the same comment, and I was like >> >>> stupid >> >>>>>>>> because >> >>>>>>>>>> I >> >>>>>>>>>>>> didn't understand :-( >> >>>>>>>>>>>> >> >>>>>>>>>>>> If it's going to take a long time, can we do the test with a >> >>>>> local >> >>>>>>>>>> machine >> >>>>>>>>>>>> and vet that it works? >> >>>>>>>>>>>> >> >>>>>>>>>>>> For local xhr loading, I left a comment in the JIRA. I >> >> don't >> >>>>> think >> >>>>>>>> it's >> >>>>>>>>>>>> need it but I'm curios on how local xhr loading works when >> >>>>> fetching >> >>>>>>>>>> normal >> >>>>>>>>>>>> files on a web app, meaning dynamically loading js, css, >> >> html >> >>> in >> >>>>> SPA >> >>>>>>>>>> using >> >>>>>>>>>>>> a typical js framework like angular, etc.. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Platform API is [5], I think is nice to have but not >> >> required >> >>>>> for the >> >>>>>>>>>> 4.0 >> >>>>>>>>>>>> release. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Oh by the way GREAT PROGRESS !!! and I cheers , I'm having a >> >>> beer >> >>>>>>>> now. >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> On Tue, Dec 1, 2015 at 8:38 PM Shazron <shaz...@gmail.com> >> >>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>>> The board is almost clear [1]. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> UIWebView mobile-spec passes, just waiting for INFRA-10831 >> >>> [2] >> >>>>> for >> >>>>>>>> the >> >>>>>>>>>>>>> file-transfer tests. >> >>>>>>>>>>>>> Ditto for WKWebView, it essentially just fails two tests, >> >>> which >> >>>>> are >> >>>>>>>>>>>>> expected [3] >> >>>>>>>>>>>>> (filed a feature request issue [4] for local xhr loading, >> >> if >> >>>>>>>> needed). >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Platform API [4] could go in this release as well, what do >> >>> you >> >>>>>>>> think? >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> --- >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> [1] >> >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=76 >> >>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-10831 >> >>>>>>>>>>>>> [3] >> >> >> https://issues.apache.org/jira/browse/CB-7287?focusedCommentId=15034831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15034831 >> >>>>>>>>>>>>> [4] https://issues.apache.org/jira/browse/CB-10109 >> >>>>>>>>>>>>> [5] https://github.com/apache/cordova-ios/pull/176 >> >>> --------------------------------------------------------------------- >> >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>>>>>>>>>>>> For additional commands, e-mail: >> >> dev-h...@cordova.apache.org >> >>>>> --------------------------------------------------------------------- >> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>>>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>> --------------------------------------------------------------------- >> >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>>>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>>>> >> >>>>> --------------------------------------------------------------------- >> >>>>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
