cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [DISCUSS] cordova-ios-4.x release (for real)
Date Tue, 08 Dec 2015 02:05:09 GMT
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 <csantana23@gmail.com> wrote:

> Currently working on it...
>
> - Carlos
> @csantanapr
>
> > On Dec 7, 2015, at 6:50 PM, Steven Gill <stevengill97@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 <csantana23@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >>> On Fri, Dec 4, 2015 at 3:07 PM Shazron <shazron@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 <csantana23@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 <shazron@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 <shazron@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 <
> >> csantana23@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 <shazron@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 <purplecabbage@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 <shazron@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 <shazron@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
<
> >>>>> csantana23@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
<shazron@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-unsubscribe@cordova.apache.org
> >>>>>>>>>>>>> For additional commands, e-mail:
> >> dev-help@cordova.apache.org
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message