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 > >> >
