LGTM.
On Friday, August 21, 2015 10:48 AM, Suraj Pindoria
<suraj.pindo...@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 <iclell...@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-als...@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
>
