A regular `tar -cvzf` the missing folders are included, it's just `npm pack` not liking my local repo for some reason.
On Tue, Dec 8, 2015 at 3:51 AM, Shazron <shaz...@gmail.com> wrote: > 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
