You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Alexander Sorokin (Akvelon)" <v-...@microsoft.com> on 2015/08/21 14:33:30 UTC
File.spec.144 purpose
Hi guys.
It looks like "file.spec.144 copyTo: asset directory" tries to copy whole www directory. Was it done intentionally?
On slow environments, especially emulators this can take huge amount of time (up to 5 minutes).
In case it is not substantial and any folder will do, I've prepared a fix for this test to stop timing out on Android emulators:
https://github.com/apache/cordova-plugin-file/pull/129
Thanks,
Alexander Sorokin
Re: File.spec.144 purpose
Posted by Jesse <pu...@gmail.com>.
Can we add some of this info to a comment in the code, or put a link to
this thread?
There are far too many tests where it is not easy to glean what we are
actually testing.
My team is hiring!
@purplecabbage
risingj.com
On Fri, Aug 21, 2015 at 11:45 AM, Suraj Pindoria <
suraj.pindoria@yahoo.com.invalid> wrote:
> LGTM.
>
> On Friday, August 21, 2015 10:48 AM, Suraj Pindoria
> <su...@yahoo.com.INVALID> wrote:
>
>
> Was just replying when Ian responded. The reason I changed the test was
> because the plugin folders do not not exist when using browserify. I am
> running mobilespec now to see if everything is still good with your new
> changes.
> Suraj.
>
>
> On Friday, August 21, 2015 10:34 AM, Ian Clelland <
> iclelland@chromium.org> wrote:
>
>
> Yes and no -- it looks like a deliberate change, but it wasn't the
> original
> intention of the test -- the test was put in place as part of
> https://issues.apache.org/jira/browse/CB-6428, and it originally tested
> that it could copy just the file plugin's assets into local storage.
>
> CB-6428 is about being able to read from android_assets, and so any
> directory within the app assets would do. I suspect that the file plugin's
> dir was chosen because it should exist if we're testing it.
>
> The source directory was changed, though, about two weeks ago, with this
> commit:
>
> https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c
> (no JIRA issue, but the comments is that it fixes an issue when browserify
> is used -- I presume that the JS-concatenation means that the plugin JS
> files aren't present anymore.)
>
> So, any directory under /android_assets/ will do, but you should make sure
> that your patch doesn't fail in the same way as the original if browserify
> is being used.
>
>
> On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) <
> v-alsoro@microsoft.com> wrote:
>
> > Hi guys.
> >
> > It looks like "file.spec.144 copyTo: asset directory" tries to copy whole
> > www directory. Was it done intentionally?
> > On slow environments, especially emulators this can take huge amount of
> > time (up to 5 minutes).
> >
> > In case it is not substantial and any folder will do, I've prepared a fix
> > for this test to stop timing out on Android emulators:
> > https://github.com/apache/cordova-plugin-file/pull/129
> >
> > Thanks,
> > Alexander Sorokin
> >
>
>
>
>
>
>
Re: File.spec.144 purpose
Posted by Suraj Pindoria <su...@yahoo.com.INVALID>.
LGTM.
On Friday, August 21, 2015 10:48 AM, Suraj Pindoria <su...@yahoo.com.INVALID> wrote:
Was just replying when Ian responded. The reason I changed the test was because the plugin folders do not not exist when using browserify. I am running mobilespec now to see if everything is still good with your new changes.
Suraj.
On Friday, August 21, 2015 10:34 AM, Ian Clelland <ic...@chromium.org> wrote:
Yes and no -- it looks like a deliberate change, but it wasn't the original
intention of the test -- the test was put in place as part of
https://issues.apache.org/jira/browse/CB-6428, and it originally tested
that it could copy just the file plugin's assets into local storage.
CB-6428 is about being able to read from android_assets, and so any
directory within the app assets would do. I suspect that the file plugin's
dir was chosen because it should exist if we're testing it.
The source directory was changed, though, about two weeks ago, with this
commit:
https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c
(no JIRA issue, but the comments is that it fixes an issue when browserify
is used -- I presume that the JS-concatenation means that the plugin JS
files aren't present anymore.)
So, any directory under /android_assets/ will do, but you should make sure
that your patch doesn't fail in the same way as the original if browserify
is being used.
On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) <
v-alsoro@microsoft.com> wrote:
> Hi guys.
>
> It looks like "file.spec.144 copyTo: asset directory" tries to copy whole
> www directory. Was it done intentionally?
> On slow environments, especially emulators this can take huge amount of
> time (up to 5 minutes).
>
> In case it is not substantial and any folder will do, I've prepared a fix
> for this test to stop timing out on Android emulators:
> https://github.com/apache/cordova-plugin-file/pull/129
>
> Thanks,
> Alexander Sorokin
>
Re: File.spec.144 purpose
Posted by Suraj Pindoria <su...@yahoo.com.INVALID>.
Was just replying when Ian responded. The reason I changed the test was because the plugin folders do not not exist when using browserify. I am running mobilespec now to see if everything is still good with your new changes.
Suraj.
On Friday, August 21, 2015 10:34 AM, Ian Clelland <ic...@chromium.org> wrote:
Yes and no -- it looks like a deliberate change, but it wasn't the original
intention of the test -- the test was put in place as part of
https://issues.apache.org/jira/browse/CB-6428, and it originally tested
that it could copy just the file plugin's assets into local storage.
CB-6428 is about being able to read from android_assets, and so any
directory within the app assets would do. I suspect that the file plugin's
dir was chosen because it should exist if we're testing it.
The source directory was changed, though, about two weeks ago, with this
commit:
https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c
(no JIRA issue, but the comments is that it fixes an issue when browserify
is used -- I presume that the JS-concatenation means that the plugin JS
files aren't present anymore.)
So, any directory under /android_assets/ will do, but you should make sure
that your patch doesn't fail in the same way as the original if browserify
is being used.
On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) <
v-alsoro@microsoft.com> wrote:
> Hi guys.
>
> It looks like "file.spec.144 copyTo: asset directory" tries to copy whole
> www directory. Was it done intentionally?
> On slow environments, especially emulators this can take huge amount of
> time (up to 5 minutes).
>
> In case it is not substantial and any folder will do, I've prepared a fix
> for this test to stop timing out on Android emulators:
> https://github.com/apache/cordova-plugin-file/pull/129
>
> Thanks,
> Alexander Sorokin
>
Re: File.spec.144 purpose
Posted by Ian Clelland <ic...@chromium.org>.
Yes and no -- it looks like a deliberate change, but it wasn't the original
intention of the test -- the test was put in place as part of
https://issues.apache.org/jira/browse/CB-6428, and it originally tested
that it could copy just the file plugin's assets into local storage.
CB-6428 is about being able to read from android_assets, and so any
directory within the app assets would do. I suspect that the file plugin's
dir was chosen because it should exist if we're testing it.
The source directory was changed, though, about two weeks ago, with this
commit:
https://github.com/apache/cordova-plugin-file/commit/19c8a79a6f4667c8643f84192fd617ce1028be0c
(no JIRA issue, but the comments is that it fixes an issue when browserify
is used -- I presume that the JS-concatenation means that the plugin JS
files aren't present anymore.)
So, any directory under /android_assets/ will do, but you should make sure
that your patch doesn't fail in the same way as the original if browserify
is being used.
On Fri, Aug 21, 2015 at 8:33 AM, Alexander Sorokin (Akvelon) <
v-alsoro@microsoft.com> wrote:
> Hi guys.
>
> It looks like "file.spec.144 copyTo: asset directory" tries to copy whole
> www directory. Was it done intentionally?
> On slow environments, especially emulators this can take huge amount of
> time (up to 5 minutes).
>
> In case it is not substantial and any folder will do, I've prepared a fix
> for this test to stop timing out on Android emulators:
> https://github.com/apache/cordova-plugin-file/pull/129
>
> Thanks,
> Alexander Sorokin
>