[jira] [Resolved] (CB-6887) Add --archs option to build command for Windows Phone
[ https://issues.apache.org/jira/browse/CB-6887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse MacFadyen resolved CB-6887. - Resolution: Fixed > Add --archs option to build command for Windows Phone > - > > Key: CB-6887 > URL: https://issues.apache.org/jira/browse/CB-6887 > Project: Apache Cordova > Issue Type: Sub-task > Components: Android, CLI, iOS, Windows 8, WP8 >Reporter: Vladimir Kotikov > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CB-6728) Support chip architecture as an option when building Windows and Windows Phone projects
[
https://issues.apache.org/jira/browse/CB-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse MacFadyen resolved CB-6728.
-
Resolution: Fixed
> Support chip architecture as an option when building Windows and Windows
> Phone projects
> ---
>
> Key: CB-6728
> URL: https://issues.apache.org/jira/browse/CB-6728
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android, CLI, iOS, Windows 8, WP8
>Affects Versions: 3.4.0
>Reporter: Vladimir Kotikov
>Assignee: Jesse MacFadyen
> Labels: arm, cli, windows, wp8, x64, x86
>
> Currently apps for Windows 8 and Windows Phone 8 are targeted to AnyCPU
> architecture, which is universal, but sometimes it's critical to build
> application for specific processor architecture.
> As an example is WebSQL plugin which contains references to C++ libs so needs
> to be built for specific architecture (x84, x64, ARM) and which does not
> support AnyCPU target.
> So it looks important to add support for additional build flags `-x64`,
> `-x86`, `-arm`, '-any' to specify target chip architecture.
> {noformat}
> cordova build windows8 --release --x64
> cordova build wp8 --arm
> {noformat}
> If flag is not specified, `AnuCPU` target platform should be used by default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CB-6886) Add --archs option to build command for Windows
[ https://issues.apache.org/jira/browse/CB-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse MacFadyen resolved CB-6886. - Resolution: Fixed > Add --archs option to build command for Windows > --- > > Key: CB-6886 > URL: https://issues.apache.org/jira/browse/CB-6886 > Project: Apache Cordova > Issue Type: Sub-task > Components: Android, CLI, iOS, Windows 8, WP8 >Reporter: Vladimir Kotikov > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6895) Generated manifest skips some properties
Rodrigo Silveira created CB-6895: Summary: Generated manifest skips some properties Key: CB-6895 URL: https://issues.apache.org/jira/browse/CB-6895 Project: Apache Cordova Issue Type: Bug Components: FirefoxOS Affects Versions: 3.5.0 Reporter: Rodrigo Silveira Assignee: Rodrigo Silveira The properties *launch_path* and *installs_allowed_from* are hard coded and should instead come from *content* and *access* elements in *config.xml*. Manifest doesn't support fullscreen and portrait. See [config.xml docs|http://cordova.apache.org/docs/en/3.5.0/config_ref_index.md.html#The%20config.xml%20File] for cordova props we can use and [app manifest doc|https://developer.mozilla.org/en-US/Apps/Build/Manifest] for what firefoxos supports. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6894) Support core cordova lifecycle events
Rodrigo Silveira created CB-6894: Summary: Support core cordova lifecycle events Key: CB-6894 URL: https://issues.apache.org/jira/browse/CB-6894 Project: Apache Cordova Issue Type: Improvement Components: FirefoxOS Reporter: Rodrigo Silveira Right now we only support *deviceready*, we should add support for other [cordova lifecycle events|http://cordova.apache.org/docs/en/3.5.0/cordova_events_events.md.html#Events] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6892) Cordova Android unable to resolve org.apache.cordova (Mac)
[ https://issues.apache.org/jira/browse/CB-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020526#comment-14020526 ] Bruno Braga commented on CB-6892: - After update from 3.2 to 3.5 I see that file was removed: /platforms/android/libs/cordova-3.2.0.jar and I could find a new cordova-3.5.0.jar in my project Where is the new cordova jar file? That is related with the problem? > Cordova Android unable to resolve org.apache.cordova (Mac) > -- > > Key: CB-6892 > URL: https://issues.apache.org/jira/browse/CB-6892 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.5.0 >Reporter: Bruno Braga > > After update from 3.2 to 3.5 my android project stopped to compile. > I think something broke in a recent update with Cordova. > My problem is the same reported at > http://forum.ionicframework.com/t/unable-to-resolve-org-apache-cordova-mac/4445 > Another guy tested each Cordova version (android + mac + eclipse) and that is > the results: > > 3.4.1-0.1.0 - After my success in the previous post,I deleted CordovaLib from > the platfiorms/Android directory. Cordova was unable to rebuild it - works if > it already exists (which may be why they didn't catch this bug - it affects > brand new projects). > 3.2.0-0.4.0 - does not build (note - seemed to have alot of plugins included) > 3.3.1-0.4.2 - works if you start with a fresh new folder - you can't just > ugrade, you have to start fresh and copy your app files back in > 3.5.0-0.2.4 (latest) - fails on a clean build > 3.5.0-0.2.1 - fails on clean build > 3.4.1-0.1.0 - fails on clean build > 3.4.0-0.1.3 - fails on clean build > 3.4.0-0.1.0 - fails on clean build > 3.4.0-rc.2 - could not install via npm - its gone... > 3.3.1-0.4.23.3.1-0.4.2 - SUCCESS! WORKS > now to jump ahead and upgrade cordova to latest and try rebuilding on top of > old project with CordovaLib already built: > 3.5.0-0.2.4 - the latest! > Rebuilds, but output different - no line breaks in the output, but it works. > There seems to be alot of operations different than the early version - like > a degug.apk being created. > To recap I did this to fix it [ATTENTION: BAND-AID SOLUTION FOLLOWS]: > Install old version of cordova from February, 2014 > sudo npm -g uninstall cordova > sudo npm -g install cordova@3.3.1-0.4.23.3.1-0.4.2 > delete previous project > rm -Rf wishthisworked > cordova create wishthisworked > cordova platform add android > cordova build android > DONE with old version, now to install the latest version > sudo npm -g uninstall cordova > sudo npm -g install cordova@3.5.0-0.2.4 > within directory, build again - WORKS > Going forward : > Cordova needs to fix this bug. I'll report my findings to them. > The bad thing is every new project won't build for Android, without first > uninstalling the new version of Cordova and going back to the old version > from Feb, 2014, or try copying the CordovaLib directory to the > platform/android directory - but that is stupid ... We shouldn't have to do > this... (I have not tested this by the way) > So there's definitely a bug, it shouldn't be this hard. And even if its an > issue with my environment when all is said and done, it would be REAL NICE to > have some code in the setup that checks for that and tells the > user/installer. Otherwise, I have to dig into this more to find out why Ant > is broke, and I don't have time for that. I can just do my app in native > Android and Xcode faster than fixing this issue. > -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CB-6118) CLI should support installing a plugin on a per-platform basis
[
https://issues.apache.org/jira/browse/CB-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020432#comment-14020432
]
Craig Payne edited comment on CB-6118 at 6/6/14 11:20 PM:
--
I have a related issue. My hybrid app is served assets via a Rails-based
website. Ideally, I'd be able to serve up one set of assets - not a patchwork
quilt - and then have the Cordova side of things work out what parts to use. I
ran into this with a workaround Andrew had supplied to cordova.js (see
CB-6505). When I went to add Android support to the existing iOS-only
implementation, I ran into this complication. cordova.js is different for the
different device architectures. cordova_plugins.js *might* be different for
the different device architectures (in the case where different plugins were in
use for each), and I believe the underlying JavaScript for the plugins also
might be different for the different device architectures. At present, I'm
including all of that in the Assets being served up by Rails when a page is
loaded. If there's a smarter way to do that (e.g., including the relevant
assets in the Cordova device-specific builds) that would be fine - but I
haven't yet started looking into that.
Ideally, I'd like to have an assets directory that had sub-dirs for each of the
device OS's supported:
/app/assets/javascript/ios/
cordova.js
cordova_plugins.js
plugins/
com.phonegap.apache.barcodescanner/www/barcodescanner.js
was (Author: craigapayne):
I have a related issue. My hybrid app is served assets via a Rails-based
website. Ideally, I'd be able to serve up one set of assets - not a patchwork
quilt - and then have the Cordova side of things work out what parts to use. I
ran into this with a workaround Andrew had supplied to cordova.js (see
CB-6505). When I went to add Android support to the existing iOS-only
implementation, I ran into this complication. cordova.js is different for the
different device architectures. cordova_plugins.js *might* be different for
the different device architectures (in the case where different plugins were in
use for each), and I believe the underlying JavaScript for the plugins also
might be different for the different device architectures. At present, I'm
including all of that in the Assets being served up by Rails when a page is
loaded. If there's a smarter way to do that (e.g., including the relevant
assets in the Cordova device-specific builds) that would be fine - but I
haven't yet started looking into that.
> CLI should support installing a plugin on a per-platform basis
> --
>
> Key: CB-6118
> URL: https://issues.apache.org/jira/browse/CB-6118
> Project: Apache Cordova
> Issue Type: Improvement
> Components: CLI
>Reporter: Andrew Grieve
>Assignee: Mark Koudritsky
>
> There are several reasons why you would want to do this:
> * You want splashscreen on iOS, but not Android
> * You want a Play Services-based geolocation plugin on Android, and regular
> Geolocation for iOS
> * You want InAppBrowser for iOS, but want to just use intents on Android
> * You many want an older version of File plugin on Android, but the latest on
> on iOS
> Desired syntax:
> {code}
> cordova plugin add org.apache.cordova.file@0.3.0 --platform=ios
> cordova plugin rm org.apache.cordova.file --platform=ios --platform=android
> {code}
> Change to `cordova plugin ls`:
> {code}
> $ cordova plugin ls
> Plugins installed on Android:
> org.apache.cordova.file@1.0.0
> org.apache.cordova.file-transfer@1.2.3
> Plugins installed on iOS:
> org.apache.cordova.file@0.1.0
> org.apache.cordova.file-transfer@1.1.3
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6893) Update readme documentation in cordova-firefoxos
Rodrigo Silveira created CB-6893: Summary: Update readme documentation in cordova-firefoxos Key: CB-6893 URL: https://issues.apache.org/jira/browse/CB-6893 Project: Apache Cordova Issue Type: Task Components: FirefoxOS Reporter: Rodrigo Silveira Priority: Minor The readme instructions are way more complex that what they need to be. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6892) Cordova Android unable to resolve org.apache.cordova (Mac)
Bruno Braga created CB-6892: --- Summary: Cordova Android unable to resolve org.apache.cordova (Mac) Key: CB-6892 URL: https://issues.apache.org/jira/browse/CB-6892 Project: Apache Cordova Issue Type: Bug Components: Android Affects Versions: 3.5.0 Reporter: Bruno Braga After update from 3.2 to 3.5 my android project stopped to compile. I think something broke in a recent update with Cordova. My problem is the same reported at http://forum.ionicframework.com/t/unable-to-resolve-org-apache-cordova-mac/4445 Another guy tested each Cordova version (android + mac + eclipse) and that is the results: 3.4.1-0.1.0 - After my success in the previous post,I deleted CordovaLib from the platfiorms/Android directory. Cordova was unable to rebuild it - works if it already exists (which may be why they didn't catch this bug - it affects brand new projects). 3.2.0-0.4.0 - does not build (note - seemed to have alot of plugins included) 3.3.1-0.4.2 - works if you start with a fresh new folder - you can't just ugrade, you have to start fresh and copy your app files back in 3.5.0-0.2.4 (latest) - fails on a clean build 3.5.0-0.2.1 - fails on clean build 3.4.1-0.1.0 - fails on clean build 3.4.0-0.1.3 - fails on clean build 3.4.0-0.1.0 - fails on clean build 3.4.0-rc.2 - could not install via npm - its gone... 3.3.1-0.4.23.3.1-0.4.2 - SUCCESS! WORKS now to jump ahead and upgrade cordova to latest and try rebuilding on top of old project with CordovaLib already built: 3.5.0-0.2.4 - the latest! Rebuilds, but output different - no line breaks in the output, but it works. There seems to be alot of operations different than the early version - like a degug.apk being created. To recap I did this to fix it [ATTENTION: BAND-AID SOLUTION FOLLOWS]: Install old version of cordova from February, 2014 sudo npm -g uninstall cordova sudo npm -g install cordova@3.3.1-0.4.23.3.1-0.4.2 delete previous project rm -Rf wishthisworked cordova create wishthisworked cordova platform add android cordova build android DONE with old version, now to install the latest version sudo npm -g uninstall cordova sudo npm -g install cordova@3.5.0-0.2.4 within directory, build again - WORKS Going forward : Cordova needs to fix this bug. I'll report my findings to them. The bad thing is every new project won't build for Android, without first uninstalling the new version of Cordova and going back to the old version from Feb, 2014, or try copying the CordovaLib directory to the platform/android directory - but that is stupid ... We shouldn't have to do this... (I have not tested this by the way) So there's definitely a bug, it shouldn't be this hard. And even if its an issue with my environment when all is said and done, it would be REAL NICE to have some code in the setup that checks for that and tells the user/installer. Otherwise, I have to dig into this more to find out why Ant is broke, and I don't have time for that. I can just do my app in native Android and Xcode faster than fixing this issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6872) File plugin: wrong disk space available on iOS
[
https://issues.apache.org/jira/browse/CB-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020508#comment-14020508
]
jcesarmobile commented on CB-6872:
--
Yes, it fixed the issue for me.
But on the merge message you wrote it fix issue CB-6871 instead CB-6872
> File plugin: wrong disk space available on iOS
> --
>
> Key: CB-6872
> URL: https://issues.apache.org/jira/browse/CB-6872
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File
>Affects Versions: 3.4.0
>Reporter: Alberto Pagliarini
>Assignee: Ian Clelland
>
> I have some issue on iOS trying to allocate more than 140 Mbytes with FIle
> plugin. I have an iPad 16 Giga with 10 Giga free on device but a
> QUOTA_EXCEEDED_ERR was thrown
> Here the code
> {code}
> var requestBytes = 150 * 1024 * 1024;
> window.requestFileSystem(LocalFileSystem.PERSISTENT, requestBytes,
> function(fs) {
> // success callback
> }, function (e) {
> // error callback
> });
> {code}
> I see that the free space calulated in {{requestFileSystem}} method of
> *CDVFile.m* results always about 144 Mbytes.
> Link to thread on google groups
> https://groups.google.com/d/msg/phonegap/0er5Gp2c-gQ/bTvh15z24AkJ
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6118) CLI should support installing a plugin on a per-platform basis
[
https://issues.apache.org/jira/browse/CB-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020432#comment-14020432
]
Craig Payne commented on CB-6118:
-
I have a related issue. My hybrid app is served assets via a Rails-based
website. Ideally, I'd be able to serve up one set of assets - not a patchwork
quilt - and then have the Cordova side of things work out what parts to use. I
ran into this with a workaround Andrew had supplied to cordova.js (see
CB-6505). When I went to add Android support to the existing iOS-only
implementation, I ran into this complication. cordova.js is different for the
different device architectures. cordova_plugins.js *might* be different for
the different device architectures (in the case where different plugins were in
use for each), and I believe the underlying JavaScript for the plugins also
might be different for the different device architectures. At present, I'm
including all of that in the Assets being served up by Rails when a page is
loaded. If there's a smarter way to do that (e.g., including the relevant
assets in the Cordova device-specific builds) that would be fine - but I
haven't yet started looking into that.
> CLI should support installing a plugin on a per-platform basis
> --
>
> Key: CB-6118
> URL: https://issues.apache.org/jira/browse/CB-6118
> Project: Apache Cordova
> Issue Type: Improvement
> Components: CLI
>Reporter: Andrew Grieve
>Assignee: Mark Koudritsky
>
> There are several reasons why you would want to do this:
> * You want splashscreen on iOS, but not Android
> * You want a Play Services-based geolocation plugin on Android, and regular
> Geolocation for iOS
> * You want InAppBrowser for iOS, but want to just use intents on Android
> * You many want an older version of File plugin on Android, but the latest on
> on iOS
> Desired syntax:
> {code}
> cordova plugin add org.apache.cordova.file@0.3.0 --platform=ios
> cordova plugin rm org.apache.cordova.file --platform=ios --platform=android
> {code}
> Change to `cordova plugin ls`:
> {code}
> $ cordova plugin ls
> Plugins installed on Android:
> org.apache.cordova.file@1.0.0
> org.apache.cordova.file-transfer@1.2.3
> Plugins installed on iOS:
> org.apache.cordova.file@0.1.0
> org.apache.cordova.file-transfer@1.1.3
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6888) Fix Polish translation of plugins
[ https://issues.apache.org/jira/browse/CB-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020421#comment-14020421 ] ASF GitHub Bot commented on CB-6888: Github user rodms10 commented on the pull request: https://github.com/apache/cordova-plugin-device-motion/pull/13#issuecomment-45388123 I think you must go through crowdin for translation, [see the wiki](http://wiki.apache.org/cordova/CordovaTranslations). @ldeluca can probably confirm. > Fix Polish translation of plugins > - > > Key: CB-6888 > URL: https://issues.apache.org/jira/browse/CB-6888 > Project: Apache Cordova > Issue Type: Bug >Reporter: Piotr Zalewa > > Bing translation is not perfect, let's make it good -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6728) Support chip architecture as an option when building Windows and Windows Phone projects
[
https://issues.apache.org/jira/browse/CB-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020402#comment-14020402
]
ASF GitHub Bot commented on CB-6728:
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-windows/pull/33
> Support chip architecture as an option when building Windows and Windows
> Phone projects
> ---
>
> Key: CB-6728
> URL: https://issues.apache.org/jira/browse/CB-6728
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android, CLI, iOS, Windows 8, WP8
>Affects Versions: 3.4.0
>Reporter: Vladimir Kotikov
>Assignee: Jesse MacFadyen
> Labels: arm, cli, windows, wp8, x64, x86
>
> Currently apps for Windows 8 and Windows Phone 8 are targeted to AnyCPU
> architecture, which is universal, but sometimes it's critical to build
> application for specific processor architecture.
> As an example is WebSQL plugin which contains references to C++ libs so needs
> to be built for specific architecture (x84, x64, ARM) and which does not
> support AnyCPU target.
> So it looks important to add support for additional build flags `-x64`,
> `-x86`, `-arm`, '-any' to specify target chip architecture.
> {noformat}
> cordova build windows8 --release --x64
> cordova build wp8 --arm
> {noformat}
> If flag is not specified, `AnuCPU` target platform should be used by default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (CB-6891) Splashscreen CLI URL results in "No such file or directory"
[ https://issues.apache.org/jira/browse/CB-6891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Husting closed CB-6891. - Resolution: Fixed Fix Version/s: 3.0.0 Error in my thinking about the problem. > Splashscreen CLI URL results in "No such file or directory" > --- > > Key: CB-6891 > URL: https://issues.apache.org/jira/browse/CB-6891 > Project: Apache Cordova > Issue Type: Task > Components: CLI >Affects Versions: 3.4.0 > Environment: Mac OS X 10.9.1 on latest Mac Mini > Cordova CLI 3.4.0 > for Android 4.3, 4.4 v19 >Reporter: Steve Husting > Labels: documentation > Fix For: 3.0.0 > > > This page: > http://docs.phonegap.com/en/3.0.0/cordova_splashscreen_splashscreen.md.html#Splashscreen > ... tells us to use the following to get the Splashscreen API with CLI: > cordova plugin add > https://git-wip-us.apache.org/repos/asf/cordova-plugin-splashscreen.git > When I do that I get the console response: > -bash: > https://git-wip-us.apache.org/repos/asf/cordova-plugin-splashscreen.git: No > such file or directory > With cordova plugin list, it shows no splashscreen plugin listed. > Conclusion: we need the plugin's URL updated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6891) Splashscreen CLI URL results in "No such file or directory"
[ https://issues.apache.org/jira/browse/CB-6891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020394#comment-14020394 ] Steve Husting commented on CB-6891: --- I was wrong. That is the correct URL for 3.0.0. I needed to use the URL in 3.4.0. This can be closed. > Splashscreen CLI URL results in "No such file or directory" > --- > > Key: CB-6891 > URL: https://issues.apache.org/jira/browse/CB-6891 > Project: Apache Cordova > Issue Type: Task > Components: CLI >Affects Versions: 3.4.0 > Environment: Mac OS X 10.9.1 on latest Mac Mini > Cordova CLI 3.4.0 > for Android 4.3, 4.4 v19 >Reporter: Steve Husting > Labels: documentation > > This page: > http://docs.phonegap.com/en/3.0.0/cordova_splashscreen_splashscreen.md.html#Splashscreen > ... tells us to use the following to get the Splashscreen API with CLI: > cordova plugin add > https://git-wip-us.apache.org/repos/asf/cordova-plugin-splashscreen.git > When I do that I get the console response: > -bash: > https://git-wip-us.apache.org/repos/asf/cordova-plugin-splashscreen.git: No > such file or directory > With cordova plugin list, it shows no splashscreen plugin listed. > Conclusion: we need the plugin's URL updated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6877) Plugins Release June 5th, 2014
[ https://issues.apache.org/jira/browse/CB-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020368#comment-14020368 ] ASF subversion and git services commented on CB-6877: - Commit 992306bbc58f3ba9dc0f4dbcde1b084db5ba8169 in cordova-plugin-inappbrowser's branch refs/heads/master from [~stevegill] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git;h=992306b ] CB-6877 Updated version and RELEASENOTES.md for release 0.5.0 > Plugins Release June 5th, 2014 > -- > > Key: CB-6877 > URL: https://issues.apache.org/jira/browse/CB-6877 > Project: Apache Cordova > Issue Type: Task >Reporter: Steve Gill > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6877) Plugins Release June 5th, 2014
[ https://issues.apache.org/jira/browse/CB-6877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020369#comment-14020369 ] ASF subversion and git services commented on CB-6877: - Commit c011fe2d9dd7b5b018cadb4d7a00a0f0f9428892 in cordova-plugin-inappbrowser's branch refs/heads/master from [~stevegill] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-inappbrowser.git;h=c011fe2 ] CB-6877 Incremented plugin version. > Plugins Release June 5th, 2014 > -- > > Key: CB-6877 > URL: https://issues.apache.org/jira/browse/CB-6877 > Project: Apache Cordova > Issue Type: Task >Reporter: Steve Gill > > Following steps at > https://github.com/apache/cordova-coho/blob/master/docs/plugins-release-process.md -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6728) Support chip architecture as an option when building Windows and Windows Phone projects
[
https://issues.apache.org/jira/browse/CB-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020364#comment-14020364
]
ASF GitHub Bot commented on CB-6728:
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-wp8/pull/39
> Support chip architecture as an option when building Windows and Windows
> Phone projects
> ---
>
> Key: CB-6728
> URL: https://issues.apache.org/jira/browse/CB-6728
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android, CLI, iOS, Windows 8, WP8
>Affects Versions: 3.4.0
>Reporter: Vladimir Kotikov
>Assignee: Jesse MacFadyen
> Labels: arm, cli, windows, wp8, x64, x86
>
> Currently apps for Windows 8 and Windows Phone 8 are targeted to AnyCPU
> architecture, which is universal, but sometimes it's critical to build
> application for specific processor architecture.
> As an example is WebSQL plugin which contains references to C++ libs so needs
> to be built for specific architecture (x84, x64, ARM) and which does not
> support AnyCPU target.
> So it looks important to add support for additional build flags `-x64`,
> `-x86`, `-arm`, '-any' to specify target chip architecture.
> {noformat}
> cordova build windows8 --release --x64
> cordova build wp8 --arm
> {noformat}
> If flag is not specified, `AnuCPU` target platform should be used by default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6891) Splashscreen CLI URL results in "No such file or directory"
Steve Husting created CB-6891: - Summary: Splashscreen CLI URL results in "No such file or directory" Key: CB-6891 URL: https://issues.apache.org/jira/browse/CB-6891 Project: Apache Cordova Issue Type: Task Components: CLI Affects Versions: 3.4.0 Environment: Mac OS X 10.9.1 on latest Mac Mini Cordova CLI 3.4.0 for Android 4.3, 4.4 v19 Reporter: Steve Husting This page: http://docs.phonegap.com/en/3.0.0/cordova_splashscreen_splashscreen.md.html#Splashscreen ... tells us to use the following to get the Splashscreen API with CLI: cordova plugin add https://git-wip-us.apache.org/repos/asf/cordova-plugin-splashscreen.git When I do that I get the console response: -bash: https://git-wip-us.apache.org/repos/asf/cordova-plugin-splashscreen.git: No such file or directory With cordova plugin list, it shows no splashscreen plugin listed. Conclusion: we need the plugin's URL updated. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6879) [codova-lib] Config Utility Modularization
[ https://issues.apache.org/jira/browse/CB-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020320#comment-14020320 ] ASF subversion and git services commented on CB-6879: - Commit fff9eebaa9f36f7d3e933af28f4afa3f847c0669 in cordova-lib's branch refs/heads/configparser_module from [~lorin] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=fff9eeb ] [CB-6879] metadata parsers now consume the Cordova-Lib ConfigParser module references the source by relative path improvement would be for each module to be referenced through npm > [codova-lib] Config Utility Modularization > -- > > Key: CB-6879 > URL: https://issues.apache.org/jira/browse/CB-6879 > Project: Apache Cordova > Issue Type: Sub-task > Components: CLI >Reporter: Lorin Beer >Assignee: Lorin Beer > > Config Parser has useful functionality for subprojects > use case includes any downstream project which wants to manipulate a custom > or template config.xml file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6879) [codova-lib] Config Utility Modularization
[ https://issues.apache.org/jira/browse/CB-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020322#comment-14020322 ] ASF subversion and git services commented on CB-6879: - Commit fdd231396b13f04078ff2bba66515eaa8bca1bdc in cordova-lib's branch refs/heads/configparser_module from [~lorin] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=fdd2313 ] [CB-6879] removed ConfigParser implementation from cordova > [codova-lib] Config Utility Modularization > -- > > Key: CB-6879 > URL: https://issues.apache.org/jira/browse/CB-6879 > Project: Apache Cordova > Issue Type: Sub-task > Components: CLI >Reporter: Lorin Beer >Assignee: Lorin Beer > > Config Parser has useful functionality for subprojects > use case includes any downstream project which wants to manipulate a custom > or template config.xml file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6879) [codova-lib] Config Utility Modularization
[ https://issues.apache.org/jira/browse/CB-6879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020321#comment-14020321 ] ASF subversion and git services commented on CB-6879: - Commit 350b23ea891b6e17fa72a5ea9c60a13e6144887d in cordova-lib's branch refs/heads/configparser_module from [~lorin] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=350b23e ] [CB-6879] majore cordova lib functions refer to modularized ConfigParser > [codova-lib] Config Utility Modularization > -- > > Key: CB-6879 > URL: https://issues.apache.org/jira/browse/CB-6879 > Project: Apache Cordova > Issue Type: Sub-task > Components: CLI >Reporter: Lorin Beer >Assignee: Lorin Beer > > Config Parser has useful functionality for subprojects > use case includes any downstream project which wants to manipulate a custom > or template config.xml file. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6698) Plugman support for referencing Android libraries
[ https://issues.apache.org/jira/browse/CB-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020319#comment-14020319 ] ASF subversion and git services commented on CB-6698: - Commit 04588a42067a5ba0d303f4b69f99f44640c3b9e0 in cordova-lib's branch refs/heads/master from [~agrieve] [ https://git-wip-us.apache.org/repos/asf?p=cordova-lib.git;h=04588a4 ] CB-6698 Resolve android relative to plugin_dir when custom=true > Plugman support for referencing Android libraries > - > > Key: CB-6698 > URL: https://issues.apache.org/jira/browse/CB-6698 > Project: Apache Cordova > Issue Type: New Feature > Components: Plugman >Reporter: Martin Bektchiev >Assignee: Martin Bektchiev > > Make plugman capable of referencing an Android library project from within a > plugin. > Currently there's no viable way to do it and it is becoming common to try to > circumvent this limitation by abusing *plugin.xml* to (try to) merge a > library's resources, code and configuration. (see > https://github.com/wildabeast/BarcodeScanner) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6872) File plugin: wrong disk space available on iOS
[
https://issues.apache.org/jira/browse/CB-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020267#comment-14020267
]
Ian Clelland commented on CB-6872:
--
[~jcesarmobile] -- I've merged this in to file -- can you confirm that it fixes
the issue for you?
> File plugin: wrong disk space available on iOS
> --
>
> Key: CB-6872
> URL: https://issues.apache.org/jira/browse/CB-6872
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File
>Affects Versions: 3.4.0
>Reporter: Alberto Pagliarini
>
> I have some issue on iOS trying to allocate more than 140 Mbytes with FIle
> plugin. I have an iPad 16 Giga with 10 Giga free on device but a
> QUOTA_EXCEEDED_ERR was thrown
> Here the code
> {code}
> var requestBytes = 150 * 1024 * 1024;
> window.requestFileSystem(LocalFileSystem.PERSISTENT, requestBytes,
> function(fs) {
> // success callback
> }, function (e) {
> // error callback
> });
> {code}
> I see that the free space calulated in {{requestFileSystem}} method of
> *CDVFile.m* results always about 144 Mbytes.
> Link to thread on google groups
> https://groups.google.com/d/msg/phonegap/0er5Gp2c-gQ/bTvh15z24AkJ
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CB-6872) File plugin: wrong disk space available on iOS
[
https://issues.apache.org/jira/browse/CB-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland reassigned CB-6872:
Assignee: Ian Clelland
> File plugin: wrong disk space available on iOS
> --
>
> Key: CB-6872
> URL: https://issues.apache.org/jira/browse/CB-6872
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File
>Affects Versions: 3.4.0
>Reporter: Alberto Pagliarini
>Assignee: Ian Clelland
>
> I have some issue on iOS trying to allocate more than 140 Mbytes with FIle
> plugin. I have an iPad 16 Giga with 10 Giga free on device but a
> QUOTA_EXCEEDED_ERR was thrown
> Here the code
> {code}
> var requestBytes = 150 * 1024 * 1024;
> window.requestFileSystem(LocalFileSystem.PERSISTENT, requestBytes,
> function(fs) {
> // success callback
> }, function (e) {
> // error callback
> });
> {code}
> I see that the free space calulated in {{requestFileSystem}} method of
> *CDVFile.m* results always about 144 Mbytes.
> Link to thread on google groups
> https://groups.google.com/d/msg/phonegap/0er5Gp2c-gQ/bTvh15z24AkJ
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6871) Windows8 - add ability to resolve ms-appdata urls for
[ https://issues.apache.org/jira/browse/CB-6871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020262#comment-14020262 ] ASF subversion and git services commented on CB-6871: - Commit 429d0720a9184c7876ee60c66dfd2daedaa87b28 in cordova-plugin-file's branch refs/heads/master from [~iclelland] [ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=429d072 ] Merge fix for CB-6871 (Wrong disk free space being reported in iOS) > Windows8 - add ability to resolve ms-appdata urls for > -- > > Key: CB-6871 > URL: https://issues.apache.org/jira/browse/CB-6871 > Project: Apache Cordova > Issue Type: Improvement > Components: Plugin File >Affects Versions: 3.5.0 >Reporter: Cristian Badila > > This is especially important as the camera plugin right now returns a URL of > the following format when successfully capturing a photo: > bq. "ms-appdata:///local/" + storageFile.name > This kind of URL format cannot be resolved by the file plugin right now so > the result returned by the camera plugin cannot be used by the file plugin in > any way. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6872) File plugin: wrong disk space available on iOS
[
https://issues.apache.org/jira/browse/CB-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020263#comment-14020263
]
ASF GitHub Bot commented on CB-6872:
Github user asfgit closed the pull request at:
https://github.com/apache/cordova-plugin-file/pull/50
> File plugin: wrong disk space available on iOS
> --
>
> Key: CB-6872
> URL: https://issues.apache.org/jira/browse/CB-6872
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File
>Affects Versions: 3.4.0
>Reporter: Alberto Pagliarini
>
> I have some issue on iOS trying to allocate more than 140 Mbytes with FIle
> plugin. I have an iPad 16 Giga with 10 Giga free on device but a
> QUOTA_EXCEEDED_ERR was thrown
> Here the code
> {code}
> var requestBytes = 150 * 1024 * 1024;
> window.requestFileSystem(LocalFileSystem.PERSISTENT, requestBytes,
> function(fs) {
> // success callback
> }, function (e) {
> // error callback
> });
> {code}
> I see that the free space calulated in {{requestFileSystem}} method of
> *CDVFile.m* results always about 144 Mbytes.
> Link to thread on google groups
> https://groups.google.com/d/msg/phonegap/0er5Gp2c-gQ/bTvh15z24AkJ
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6532) cdvfile file url is not working with link tag like css
[
https://issues.apache.org/jira/browse/CB-6532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020245#comment-14020245
]
Ian Clelland commented on CB-6532:
--
[~patrickdu] -- any update? I can't reproduce it with recent plugins / cordova;
I'll close this if I don't hear back, but feel free to comment / re-open it if
it's still an issue.
> cdvfile file url is not working with link tag like css
> ---
>
> Key: CB-6532
> URL: https://issues.apache.org/jira/browse/CB-6532
> Project: Apache Cordova
> Issue Type: Bug
> Components: Plugin File, Plugin File Transfer
>Affects Versions: 3.4.0
> Environment: iOS 7
>Reporter: Patrick Dürsteler
>Priority: Critical
>
> A css downloaded with xhr and created a local url
> (cdvfile://localhost/test.css) with the File API can't be used as a
> stylesheet.
> {code}
> var filename = "test.css";
> var imageURL = "http://apache.org/css/style.css";;
> requestFileSystem(TEMPORARY, 0, function(fileSystem) {
> var ft = new FileTransfer();
> ft.download(imageURL, fileSystem.root.toURL() + "/" + filename,
> function(entry) {
> var fileref=document.createElement("link");
> fileref.setAttribute("rel", "stylesheet");
> fileref.setAttribute("type", "text/css");
>fileref.setAttribute("href", entry.toURL());
> document.head.appendChild(imgElement);
> });
> });
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CB-6890) Android plugins which use pluginManager fields break on 4.0.x branch
[
https://issues.apache.org/jira/browse/CB-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Clelland resolved CB-6890.
--
Resolution: Fixed
Fixed in three core plugins.
> Android plugins which use pluginManager fields break on 4.0.x branch
>
>
> Key: CB-6890
> URL: https://issues.apache.org/jira/browse/CB-6890
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin File, Plugin File Transfer, Plugin Media
> Capture
>Affects Versions: 4.0.0
>Reporter: Ian Clelland
>Assignee: Ian Clelland
>
> The field {{CordovaWebView.pluginManager}} was changed from a public field to
> a getter, {{getPluginManager()}}, for Cordova-Android v4.0.0. (to support
> pluggable webviews)
> This means that code in plugins like this:
> {code}
> PluginManager pm = webView.pluginManager;
> {code}
> will break. However, the replacement code,
> {code}
> PluginManager pm = webView.getPluginManager();
> {code}
> will break on existing 3.x versions of Cordova.
> The solution is to use reflection in the plugin to determine whether the
> method or the field is available, and to use the appropriate access method to
> get the plugin manager. This code works in both old and new versions of
> Cordova:
> {code}
> Class webViewClass = webView.getClass();
> PluginManager pm = null;
> try {
> Method gpm = webViewClass.getMethod("getPluginManager");
> pm = (PluginManager) gpm.invoke(webView);
> } catch (NoSuchMethodException e) {
> } catch (IllegalAccessException e) {
> } catch (InvocationTargetException e) {
> }
> if (pm == null) {
> try {
> Field pmf = webViewClass.getField("pluginManager");
> pm = (PluginManager)pmf.get(webView);
> } catch (NoSuchFieldException e) {
> } catch (IllegalAccessException e) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6890) Android plugins which use pluginManager fields break on 4.0.x branch
[
https://issues.apache.org/jira/browse/CB-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020184#comment-14020184
]
ASF subversion and git services commented on CB-6890:
-
Commit 690824248cd745a44ba79b622b370d0b41cdbce0 in
cordova-plugin-file-transfer's branch refs/heads/master from [~iclelland]
[
https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file-transfer.git;h=6908242
]
CB-6890: Fix pluginManager access for 4.0.x branch
> Android plugins which use pluginManager fields break on 4.0.x branch
>
>
> Key: CB-6890
> URL: https://issues.apache.org/jira/browse/CB-6890
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin File, Plugin File Transfer, Plugin Media
> Capture
>Affects Versions: 4.0.0
>Reporter: Ian Clelland
>Assignee: Ian Clelland
>
> The field {{CordovaWebView.pluginManager}} was changed from a public field to
> a getter, {{getPluginManager()}}, for Cordova-Android v4.0.0. (to support
> pluggable webviews)
> This means that code in plugins like this:
> {code}
> PluginManager pm = webView.pluginManager;
> {code}
> will break. However, the replacement code,
> {code}
> PluginManager pm = webView.getPluginManager();
> {code}
> will break on existing 3.x versions of Cordova.
> The solution is to use reflection in the plugin to determine whether the
> method or the field is available, and to use the appropriate access method to
> get the plugin manager. This code works in both old and new versions of
> Cordova:
> {code}
> Class webViewClass = webView.getClass();
> PluginManager pm = null;
> try {
> Method gpm = webViewClass.getMethod("getPluginManager");
> pm = (PluginManager) gpm.invoke(webView);
> } catch (NoSuchMethodException e) {
> } catch (IllegalAccessException e) {
> } catch (InvocationTargetException e) {
> }
> if (pm == null) {
> try {
> Field pmf = webViewClass.getField("pluginManager");
> pm = (PluginManager)pmf.get(webView);
> } catch (NoSuchFieldException e) {
> } catch (IllegalAccessException e) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6890) Android plugins which use pluginManager fields break on 4.0.x branch
[
https://issues.apache.org/jira/browse/CB-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020186#comment-14020186
]
ASF subversion and git services commented on CB-6890:
-
Commit 3b004e20e19f7aaa8b3448177e0ca66126a77835 in cordova-plugin-file's branch
refs/heads/master from [~iclelland]
[ https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file.git;h=3b004e2 ]
CB-6890: Fix pluginManager access for 4.0.x branch
> Android plugins which use pluginManager fields break on 4.0.x branch
>
>
> Key: CB-6890
> URL: https://issues.apache.org/jira/browse/CB-6890
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin File, Plugin File Transfer, Plugin Media
> Capture
>Affects Versions: 4.0.0
>Reporter: Ian Clelland
>Assignee: Ian Clelland
>
> The field {{CordovaWebView.pluginManager}} was changed from a public field to
> a getter, {{getPluginManager()}}, for Cordova-Android v4.0.0. (to support
> pluggable webviews)
> This means that code in plugins like this:
> {code}
> PluginManager pm = webView.pluginManager;
> {code}
> will break. However, the replacement code,
> {code}
> PluginManager pm = webView.getPluginManager();
> {code}
> will break on existing 3.x versions of Cordova.
> The solution is to use reflection in the plugin to determine whether the
> method or the field is available, and to use the appropriate access method to
> get the plugin manager. This code works in both old and new versions of
> Cordova:
> {code}
> Class webViewClass = webView.getClass();
> PluginManager pm = null;
> try {
> Method gpm = webViewClass.getMethod("getPluginManager");
> pm = (PluginManager) gpm.invoke(webView);
> } catch (NoSuchMethodException e) {
> } catch (IllegalAccessException e) {
> } catch (InvocationTargetException e) {
> }
> if (pm == null) {
> try {
> Field pmf = webViewClass.getField("pluginManager");
> pm = (PluginManager)pmf.get(webView);
> } catch (NoSuchFieldException e) {
> } catch (IllegalAccessException e) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6890) Android plugins which use pluginManager fields break on 4.0.x branch
[
https://issues.apache.org/jira/browse/CB-6890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020183#comment-14020183
]
ASF subversion and git services commented on CB-6890:
-
Commit 1bef8d02dddbf4effeb501459b1de86e61b06c75 in
cordova-plugin-media-capture's branch refs/heads/master from [~iclelland]
[
https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-media-capture.git;h=1bef8d0
]
CB-6890: Fix pluginManager access for 4.0.x branch
> Android plugins which use pluginManager fields break on 4.0.x branch
>
>
> Key: CB-6890
> URL: https://issues.apache.org/jira/browse/CB-6890
> Project: Apache Cordova
> Issue Type: Bug
> Components: Android, Plugin File, Plugin File Transfer, Plugin Media
> Capture
>Affects Versions: 4.0.0
>Reporter: Ian Clelland
>Assignee: Ian Clelland
>
> The field {{CordovaWebView.pluginManager}} was changed from a public field to
> a getter, {{getPluginManager()}}, for Cordova-Android v4.0.0. (to support
> pluggable webviews)
> This means that code in plugins like this:
> {code}
> PluginManager pm = webView.pluginManager;
> {code}
> will break. However, the replacement code,
> {code}
> PluginManager pm = webView.getPluginManager();
> {code}
> will break on existing 3.x versions of Cordova.
> The solution is to use reflection in the plugin to determine whether the
> method or the field is available, and to use the appropriate access method to
> get the plugin manager. This code works in both old and new versions of
> Cordova:
> {code}
> Class webViewClass = webView.getClass();
> PluginManager pm = null;
> try {
> Method gpm = webViewClass.getMethod("getPluginManager");
> pm = (PluginManager) gpm.invoke(webView);
> } catch (NoSuchMethodException e) {
> } catch (IllegalAccessException e) {
> } catch (InvocationTargetException e) {
> }
> if (pm == null) {
> try {
> Field pmf = webViewClass.getField("pluginManager");
> pm = (PluginManager)pmf.get(webView);
> } catch (NoSuchFieldException e) {
> } catch (IllegalAccessException e) {
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6890) Android plugins which use pluginManager fields break on 4.0.x branch
Ian Clelland created CB-6890:
Summary: Android plugins which use pluginManager fields break on
4.0.x branch
Key: CB-6890
URL: https://issues.apache.org/jira/browse/CB-6890
Project: Apache Cordova
Issue Type: Bug
Components: Android, Plugin File, Plugin File Transfer, Plugin Media
Capture
Affects Versions: 4.0.0
Reporter: Ian Clelland
Assignee: Ian Clelland
The field {{CordovaWebView.pluginManager}} was changed from a public field to a
getter, {{getPluginManager()}}, for Cordova-Android v4.0.0. (to support
pluggable webviews)
This means that code in plugins like this:
{code}
PluginManager pm = webView.pluginManager;
{code}
will break. However, the replacement code,
{code}
PluginManager pm = webView.getPluginManager();
{code}
will break on existing 3.x versions of Cordova.
The solution is to use reflection in the plugin to determine whether the method
or the field is available, and to use the appropriate access method to get the
plugin manager. This code works in both old and new versions of Cordova:
{code}
Class webViewClass = webView.getClass();
PluginManager pm = null;
try {
Method gpm = webViewClass.getMethod("getPluginManager");
pm = (PluginManager) gpm.invoke(webView);
} catch (NoSuchMethodException e) {
} catch (IllegalAccessException e) {
} catch (InvocationTargetException e) {
}
if (pm == null) {
try {
Field pmf = webViewClass.getField("pluginManager");
pm = (PluginManager)pmf.get(webView);
} catch (NoSuchFieldException e) {
} catch (IllegalAccessException e) {
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-5671) facilitate dynamic loading of cordova plugins
[ https://issues.apache.org/jira/browse/CB-5671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14020081#comment-14020081 ] Craig Payne commented on CB-5671: - Hi Andrew, is there an Open Issue for doing that work (the build-step to concat all the plugin JS & cordova.js)? I'd like to track it, so I know when I can remove the cordova.js you pointed me at a few months ago. > facilitate dynamic loading of cordova plugins > - > > Key: CB-5671 > URL: https://issues.apache.org/jira/browse/CB-5671 > Project: Apache Cordova > Issue Type: Improvement > Components: CordovaJS >Affects Versions: 3.2.0 > Environment: any >Reporter: Jon Whitlock >Assignee: Andrew Grieve > Labels: javascript > Attachments: Screen Shot 2014-03-06 at 8.49.27 AM.png > > > Problem: Cordova expects resources to be loaded off the device filesystem. > 1) On iOS this is very risky due to the turnaround time pushing hotfixes > through the App store. > 2) In complex JS applications one needs to use a loader like require.js to > manage async loading (especially on mobile) & module dependancy management > (as cordova does internally). > 3) When integrating with many 3rd-party services like auth/"social login" one > needs to have a public-facing page to call back to. > Use case: We have a bunch of prereqs before cordova.js loads, so we have to > load cordova.js using require.js. However to show localised error messages > we need the preferred language from the device to know which language to show > messaging in, so we need cordova loaded as part of auth prerequisites. > Problematic Assumptions: > a) findCordovaPath() assumes a script tag in the document loaded cordova.js > -- not the case with require.js or similar. > b) injectPluginScript() assumes that cordova_plugins.js is in the same dir as > cordova.js > So using plugins & dynamically loading Cordova is terminal, unless I hack > findCordovaPath() to return (in our case) the path where cordova.js is to be > found -- which is defined in a JS configuration file. > I think it would be more robust to define the location of those file(s) in a > config file somewhere -- which could also facilitate dynamic loading of > cordova. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CB-4101) Remove casing inconsistencies in config parameter names
[ https://issues.apache.org/jira/browse/CB-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Bowser updated CB-4101: --- Component/s: (was: Android) > Remove casing inconsistencies in config parameter names > --- > > Key: CB-4101 > URL: https://issues.apache.org/jira/browse/CB-4101 > Project: Apache Cordova > Issue Type: Bug >Reporter: Andrew Grieve >Assignee: Max Woghiren >Priority: Minor > > ML Discussion: http://callback.markmail.org/thread/6agfbr7mggkixevz -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6024) nopt refactoring
[ https://issues.apache.org/jira/browse/CB-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019900#comment-14019900 ] Mark Koudritsky commented on CB-6024: - I don't think there is a need to replace optimist in createmobilespec, it's used there in a nice and clean way (unlike it was in cordova-cli) so we can leave it as is until we start hitting real problems with it. I'm not aware of any other places that use optimist, so I consider the "nopt" part done. > nopt refactoring > > > Key: CB-6024 > URL: https://issues.apache.org/jira/browse/CB-6024 > Project: Apache Cordova > Issue Type: Improvement > Components: CLI, Plugman >Affects Versions: 3.3.0 > Environment: Windows, Mac OSX >Reporter: Jonathan Bond >Assignee: Mark Koudritsky > Labels: patch > Fix For: 3.6.0 > > > As per mailing list: > - Refactoring cli to use nopt. > - Several improvements to the install/uninstall tests to touch the file > system. > - Consistency improvements in the code -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6024) nopt refactoring
[ https://issues.apache.org/jira/browse/CB-6024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019855#comment-14019855 ] Marcel Kinard commented on CB-6024: --- What is the scope of this refactoring? For example, optimist is used in cordova-mobile-spec/createmobilespec/createmobilespec.js. Is it your intention to target all places where optimist is used, or just lib and cli? > nopt refactoring > > > Key: CB-6024 > URL: https://issues.apache.org/jira/browse/CB-6024 > Project: Apache Cordova > Issue Type: Improvement > Components: CLI, Plugman >Affects Versions: 3.3.0 > Environment: Windows, Mac OSX >Reporter: Jonathan Bond >Assignee: Mark Koudritsky > Labels: patch > Fix For: 3.6.0 > > > As per mailing list: > - Refactoring cli to use nopt. > - Several improvements to the install/uninstall tests to touch the file > system. > - Consistency improvements in the code -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-5294) File input element not opening file picker in Android 4.4
[ https://issues.apache.org/jira/browse/CB-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019848#comment-14019848 ] Mike Billau commented on CB-5294: - Seems mostly fixed for me on Nexus 5 running 4.4.3. The button opens the file chooser dialog. No matter what source I select, the asset does seem to be uploaded. However, if you select from "Recent" or "Images", the file will be renamed from something like IMG_234234.jpg --> image%3A24. If you select from "Downloads", or "Gallery", the image will be renamed from: IMG_23432423.jpg --> 24 > File input element not opening file picker in Android 4.4 > - > > Key: CB-5294 > URL: https://issues.apache.org/jira/browse/CB-5294 > Project: Apache Cordova > Issue Type: Bug > Components: Android >Affects Versions: 3.1.0 > Environment: Android 4.4.2, partially fixed in Android 4.4.3 >Reporter: Paul Kane >Assignee: Ian Clelland > > The file input field doesn't respond when clicked/tapped in Android 4.4. > Works fine in previous Android versions. This is regardless of whether the > Target Level is set to 18 or 19. > To reproduce, I created a fresh Cordova 3.1.0 project for Android. The only > modification I made to the default (placeholder) index.html file was adding a > element with a single element inside. Clicking the > "Choose File" button does nothing. No Logcat output or errors. Normally at > this point a dialogue would open allowing me to select an image from the > gallery or take a picture, which is what happens in older Android versions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CB-6889) "Edit json" step in master.cfg fails on Windows
[
https://issues.apache.org/jira/browse/CB-6889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Kotikov closed CB-6889.
Resolution: Cannot Reproduce
> "Edit json" step in master.cfg fails on Windows
> ---
>
> Key: CB-6889
> URL: https://issues.apache.org/jira/browse/CB-6889
> Project: Apache Cordova
> Issue Type: Bug
> Components: Medic, Windows 8, WP8
>Reporter: Vladimir Kotikov
>Assignee: Jesse MacFadyen
>
> When running medic on windows (either the client and server or just a
> client), the Edit json step specified in master.cfg fails.
> Reason: Windows medic install uses the unix utilities from git\bin, the
> version of sed installed doesn't support the "-i" parameter.
> {noformat}
> ShellCommand(command=["sed","-e","s/cordova-lib\": \"0./cordova-lib\":
> \">=0./","-i","bak","package.json"],workdir='build/cordova-cli',haltOnFailure=True,description='Edit
> json',descriptionDone='Edit json'),
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CB-6889) "Edit json" step in master.cfg fails on Windows
Vladimir Kotikov created CB-6889:
Summary: "Edit json" step in master.cfg fails on Windows
Key: CB-6889
URL: https://issues.apache.org/jira/browse/CB-6889
Project: Apache Cordova
Issue Type: Bug
Components: Medic, Windows 8, WP8
Reporter: Vladimir Kotikov
Assignee: Jesse MacFadyen
When running medic on windows (either the client and server or just a client),
the Edit json step specified in master.cfg fails.
Reason: Windows medic install uses the unix utilities from git\bin, the version
of sed installed doesn't support the "-i" parameter.
{noformat}
ShellCommand(command=["sed","-e","s/cordova-lib\": \"0./cordova-lib\":
\">=0./","-i","bak","package.json"],workdir='build/cordova-cli',haltOnFailure=True,description='Edit
json',descriptionDone='Edit json'),
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6728) Support chip architecture as an option when building Windows and Windows Phone projects
[
https://issues.apache.org/jira/browse/CB-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019806#comment-14019806
]
ASF GitHub Bot commented on CB-6728:
GitHub user vladimir-kotikov opened a pull request:
https://github.com/apache/cordova-windows/pull/33
CB 6728 Support chip architecture as an option when building Windows
projects
Adds support for target architectures to build command
Implementation for [CB-6728](https://issues.apache.org/jira/browse/CB-6728)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/MSOpenTech/cordova-windows CB-6728
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-windows/pull/33.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #33
commit 28bba7032dee74b26de37c43cc12bb41c428a3de
Author: Vladimir Kotikov
Date: 2014-06-06T07:23:58Z
Adds support for target architectures to build command
> Support chip architecture as an option when building Windows and Windows
> Phone projects
> ---
>
> Key: CB-6728
> URL: https://issues.apache.org/jira/browse/CB-6728
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android, CLI, iOS, Windows 8, WP8
>Affects Versions: 3.4.0
>Reporter: Vladimir Kotikov
>Assignee: Jesse MacFadyen
> Labels: arm, cli, windows, wp8, x64, x86
>
> Currently apps for Windows 8 and Windows Phone 8 are targeted to AnyCPU
> architecture, which is universal, but sometimes it's critical to build
> application for specific processor architecture.
> As an example is WebSQL plugin which contains references to C++ libs so needs
> to be built for specific architecture (x84, x64, ARM) and which does not
> support AnyCPU target.
> So it looks important to add support for additional build flags `-x64`,
> `-x86`, `-arm`, '-any' to specify target chip architecture.
> {noformat}
> cordova build windows8 --release --x64
> cordova build wp8 --arm
> {noformat}
> If flag is not specified, `AnuCPU` target platform should be used by default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-6728) Support chip architecture as an option when building Windows and Windows Phone projects
[
https://issues.apache.org/jira/browse/CB-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019804#comment-14019804
]
ASF GitHub Bot commented on CB-6728:
GitHub user vladimir-kotikov opened a pull request:
https://github.com/apache/cordova-wp8/pull/39
CB-6728 Support chip architecture as an option when building Windows Phone
projects
Adds support for target architectures to build command
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/MSOpenTech/cordova-wp8 CB-6728
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cordova-wp8/pull/39.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #39
commit 351ff3e74b07e4d380a244cfb443e51257c7edb7
Author: Vladimir Kotikov
Date: 2014-06-06T06:45:08Z
Adds support for target architectures to build command
> Support chip architecture as an option when building Windows and Windows
> Phone projects
> ---
>
> Key: CB-6728
> URL: https://issues.apache.org/jira/browse/CB-6728
> Project: Apache Cordova
> Issue Type: Improvement
> Components: Android, CLI, iOS, Windows 8, WP8
>Affects Versions: 3.4.0
>Reporter: Vladimir Kotikov
>Assignee: Jesse MacFadyen
> Labels: arm, cli, windows, wp8, x64, x86
>
> Currently apps for Windows 8 and Windows Phone 8 are targeted to AnyCPU
> architecture, which is universal, but sometimes it's critical to build
> application for specific processor architecture.
> As an example is WebSQL plugin which contains references to C++ libs so needs
> to be built for specific architecture (x84, x64, ARM) and which does not
> support AnyCPU target.
> So it looks important to add support for additional build flags `-x64`,
> `-x86`, `-arm`, '-any' to specify target chip architecture.
> {noformat}
> cordova build windows8 --release --x64
> cordova build wp8 --arm
> {noformat}
> If flag is not specified, `AnuCPU` target platform should be used by default.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CB-4967) device-motion
[ https://issues.apache.org/jira/browse/CB-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019752#comment-14019752 ] ASF GitHub Bot commented on CB-4967: Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-device-motion/pull/8 > device-motion > - > > Key: CB-4967 > URL: https://issues.apache.org/jira/browse/CB-4967 > Project: Apache Cordova > Issue Type: Sub-task > Components: Plugin Device Motion > Environment: firefoxos >Reporter: Piotr Zalewa >Assignee: Steve Gill > > I started development of the Accelerator > https://github.com/zalun/cordova-plugin-device-motion > I've got issues on FxOS device, works on Android (via Firefox browser) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-6888) Fix Polish translation of plugins
[ https://issues.apache.org/jira/browse/CB-6888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019743#comment-14019743 ] ASF GitHub Bot commented on CB-6888: GitHub user zalun opened a pull request: https://github.com/apache/cordova-plugin-device-motion/pull/13 CB-6888 Polish translation fixed * and _ fixed automatic translation issues You can merge this pull request into a Git repository by running: $ git pull https://github.com/zalun/cordova-plugin-device-motion fix_pl_translation Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-device-motion/pull/13.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #13 commit 5be9ece7e45a43f54dbc678890ec63dacc2b2c1a Author: Piotr Zalewa Date: 2014-06-06T10:32:39Z fixed * and _ fixed automatic translation issues > Fix Polish translation of plugins > - > > Key: CB-6888 > URL: https://issues.apache.org/jira/browse/CB-6888 > Project: Apache Cordova > Issue Type: Bug >Reporter: Piotr Zalewa > > Bing translation is not perfect, let's make it good -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CB-6888) Fix Polish translation of plugins
Piotr Zalewa created CB-6888: Summary: Fix Polish translation of plugins Key: CB-6888 URL: https://issues.apache.org/jira/browse/CB-6888 Project: Apache Cordova Issue Type: Bug Reporter: Piotr Zalewa Bing translation is not perfect, let's make it good -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CB-2606) Add support for elements in config.xml
[
https://issues.apache.org/jira/browse/CB-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019630#comment-14019630
]
ASF GitHub Bot commented on CB-2606:
Github user rohitagg28 commented on the pull request:
https://github.com/apache/cordova-cli/pull/126#issuecomment-45308768
Thanks. The problem get solved by using the updated version.
> Add support for elements in config.xml
> -
>
> Key: CB-2606
> URL: https://issues.apache.org/jira/browse/CB-2606
> Project: Apache Cordova
> Issue Type: Wish
> Components: Docs
>Reporter: Filip Maj
>Assignee: Mark Koudritsky
>
> This feature would add support for specifying the application icon by
> changing values inside the {{config.xml}} document.
> Relevant details for Cordova:
> - {{}} elements _may_ have {{width}} and {{height}} attributes
> representing the preferred size of the icon in CSS pixels.
> - {{}} elements _must_ have a {{src}} attribute, which contains a path
> string relative to the {{www/}} folder (or equivalent) in the platform.
> See [the Widget Spec's section on
> icons|http://www.w3.org/TR/widgets/#the-icon-element-and-its-attributes] for
> specifics.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
