Re: [DISCUSS] Cordova-Android 4.0.0 Release
+1 for vote thread, let's get this thing out so people (that are not us) can test... On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com wrote: OK, this is a three month old thread, and we're waiting on a discussion before we release something? I really think we should go to a vote thread now that we have a legacy whitelist plugin and a new style whitelist plugin. We shouldn't keep constantly delaying this release because of what's happening on other platforms, especially since we already pluginized the whitelist. Can we please release soon? On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal nikhi...@microsoft.com wrote: I know we discussed a couple of approaches implementing the default whitelist policy for Android/iOS - either every app would be required to include the whitelist plugin or have it have smart defaults in the platform implementation and the plugin being able to override them. I don’t think that thread closed with any conclusions. Thanks, Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Thursday, March 12, 2015 11:23 AM To: dev Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release OK, so right now it's just docs? How soon can we get a VOTE thread started for 4.0.0? On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org wrote: mobilespec is now working again... Took longer than I would have liked, but did you know that on Android FileReader triggers shouldInterceptRequest() with Blob URLs!? Separate thread is already happening re: whitelists, so once that's figured out, it's just docs afaict. On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com wrote: We should start a new whitelist plugin related thread. Why is a plugin blocking a release? Default (aka no-plugin) behavior should be to allow all network requests shouldn't it? Well, that just might be a blacklist then :) This thread is a month long, and not the first discussion of 4.0.0 for Android. Seriously, though -- the whitelist discussion is much longer than that, and this isn't the first time that the default no-network-access policy has been brought up: (Here's the first question, from *July*: http://markmail.org/message/t4vj4saisem2mcgw Here's where I mentioned what the implemented policy was: http://markmail.org/message/s4necfnh4hnblpjm And in another discussion: http://markmail.org/message/ap7syhqysizmsvrz) If we want to reconsider that decision, then we should certainly do so before we cut a release. I think it would be a real problem to change it afterwards, so let's get it right. Also, it's not the plugin itself that's blocking the release, it's us making sure that we've implemented the core hooks correctly so that the plugin can actually do its job, and that people who don't want that particular plugin can make a better one. (It is also an issue that a plugin, required for cordova-android 4.0.0, breaks apps which are also building for cordova-ios 3.8.0. I'll take a look at that, and either remove the ios-native portions of the whitelist plugin, or neuter it so that it doesn't interfere with an ios app if it's not on the unplug-whitelist branch of that repo.) Ian @purplecabbage risingj.com On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com wrote: legacy-whitelist-plugin should be fixed so that it compiles on cordova-ios@3.8.0. It shouldn't be a problem to fix this at compile or run-time (whichever is applicable here related to the compile error) On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue dvpdin...@gmail.com wrote: On 2 March 2015 at 13:37, Joe Bowser bows...@gmail.com wrote: So, right now the whitelist changes are what's holding up the 4.0.0 release now? Is this really the only thing that's holding up this release? On Wed Feb 25 2015 at 1:18:26 PM Andrew Grieve agri...@chromium.org wrote: I think we'll also need to finish with the whitelist changes have both the legacy and new-way whitelist plugins released before we can do a 4.0.0 release (otherwise you wouldn't be able to write an app that hits the network) Just FYI, the whitelist stuff is proving to be a bit of a pain point. I'm using cordova-android@master, and need to install the legacy-whitelist plugin in order to make network requests. Once the plugin is installed, everything seems to work. The problem is that the legacy-whitelist plugin generates compile errors with cordova-ios@3.8.0, so now I can't just run `cordova build`, I need to split the platforms up and
Re: Deprecation of Config and the embedded use case (4.0.x related)
Well, this feature was tested using TDD, and when the tests were re-written I assumed that they would be run. In this case, I'll blame Android Studio, since we're still battling with the learning curve on that one. (I have no clue how to run the new tests from Gradle on the command line, only in Android Studio). The thing is that another refactor removing layouts broke the tests, which is how I know that they weren't run. So, I landed a couple of commits to refactor the unit tests so that they test this use case with the new API and the tests now pass. This works again, and we can update the documentation, There's still the matter of getting the plugins to work, but I'm fine with leaving that to be an exercise for the downstreams that support this, and not Cordova itself. On Mon, Mar 16, 2015 at 6:27 PM Michal Mocny mmo...@chromium.org wrote: Carlos, thats great, then perhaps you could give 4.0 embedded webview a shot to confirm that it is still adequately supported for your customers? I think this thread has been too much talk and not enough trying it out in practice. Everyone agrees the use case is important, what's left is to confirm we got it right. -Michal On Mon, Mar 16, 2015 at 8:58 PM, Carlos Santana csantan...@gmail.com wrote: I just want to add that Joe is not alone on thinking that are developers with this use case. For us we have customers that start with Native Android alone, and then later want to add a Cordova Web View to a portion of their App. And they want an easy way to add a Cordova Web View. For 4.x, I would assume that the developer can choose to make this embedded Cordova Web View CrossWalk based. On Wed, Mar 11, 2015 at 10:24 AM, Joe Bowser bows...@gmail.com wrote: That's why we have tests! I just changed the activity and saw that we have one failure. I'm not sure why this test in particular is failing, since there's too many assertions in one method, so I'll have to try and debug it today. The thing is that if we're deprecating something and replacing it with something else, we should write tests for it. Releasing a 4.0.x and changing how we embed a WebView by changing class names but not fixing up the deprecation is bizzare. On Wed, Mar 11, 2015 at 7:15 AM Andrew Grieve agri...@chromium.org wrote: I wanted to make sure that I didn't break the old way of doing things. On Tue, Mar 10, 2015 at 2:24 PM, Joe Bowser bows...@gmail.com wrote: The main issue is that this isn't documented anywhere, and this is necessary for people to use a Third Party WebView. Also, why didn't you bother updating the test with the new API? On Mon, Mar 9, 2015 at 5:19 PM Andrew Grieve agri...@chromium.org wrote: Here's an example: ConfigXmlParser parser = new ConfigXmlParser(); parser.parse(activity); webView.init(cordova, parser.getPluginEntries(), parser.getPreferences()); Feel free to iterate if you think the API is too obtuse, but I think it's good to allow a file-less mode, and to allow different WebViews to have different settings. On Mon, Mar 9, 2015 at 8:08 PM, Joe Bowser bows...@gmail.com wrote: Do you have an example of how this would work? This seems to be a lot more complex than it needs to be. On Mon, Mar 9, 2015 at 5:05 PM Andrew Grieve agri...@chromium.org wrote: It's so that you can have multiple CordovaWebViews that use different configs within one application. It's also so that you don't have to have a config.xml if you prefer to build up your config in code instead. I don't think loadConfig() is deprecated. It has a @SuppressWarnings(deprecation), which just silences a warning about it setting the config of the Config class (which is done for backwards compatibility). On Mon, Mar 9, 2015 at 3:54 PM, Joe Bowser bows...@gmail.com wrote: OK, this actually makes using the WebView as a component a lot harder, since you now have to have this loadConfig method which you also marked for deprecation required to get all of the necessary attributes out of this. I'm pretty sure this is a major step backwards in that people looking to use Cordova as a component now have to jump through additional hoops to get this to work. What is the benefit of deprecating the Config static class and replacing it with the ConfigXmlParser again? I don't remember why this was done. On Mon, Mar 9, 2015 at 9:04 AM Andrew Grieve agri...@chromium.org wrote:
[GitHub] cordova-js pull request: CB-7992 prohibit multiple cordova include...
GitHub user purplecabbage opened a pull request: https://github.com/apache/cordova-js/pull/104 CB-7992 prohibit multiple cordova includes Verify that window.cordova does not already exist and throw error if it does. Tested on ios/android/wp8. You can merge this pull request into a Git repository by running: $ git pull https://github.com/purplecabbage/cordova-js CB-7992 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-js/pull/104.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 #104 commit 59bd041f7f8eedad937ad211c6b714901b032ec5 Author: Jesse MacFadyen purplecabb...@gmail.com Date: 2015-03-16T21:42:47Z Verify that window.cordova does not already exist and throw error if it does --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Everything's ready afaik (minus upgrade guide, publishing whitelist plugins, and making it so that the default project template includes plugin name=cordova-plugin-whitelist /). Maybe let's do a RC while we wait on these things being finished up? If anyone wants to take on any of these tasks, that would be awesome. On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com wrote: +1 for vote thread, let's get this thing out so people (that are not us) can test... On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com wrote: OK, this is a three month old thread, and we're waiting on a discussion before we release something? I really think we should go to a vote thread now that we have a legacy whitelist plugin and a new style whitelist plugin. We shouldn't keep constantly delaying this release because of what's happening on other platforms, especially since we already pluginized the whitelist. Can we please release soon? On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal nikhi...@microsoft.com wrote: I know we discussed a couple of approaches implementing the default whitelist policy for Android/iOS - either every app would be required to include the whitelist plugin or have it have smart defaults in the platform implementation and the plugin being able to override them. I don’t think that thread closed with any conclusions. Thanks, Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Thursday, March 12, 2015 11:23 AM To: dev Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release OK, so right now it's just docs? How soon can we get a VOTE thread started for 4.0.0? On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org wrote: mobilespec is now working again... Took longer than I would have liked, but did you know that on Android FileReader triggers shouldInterceptRequest() with Blob URLs!? Separate thread is already happening re: whitelists, so once that's figured out, it's just docs afaict. On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com wrote: We should start a new whitelist plugin related thread. Why is a plugin blocking a release? Default (aka no-plugin) behavior should be to allow all network requests shouldn't it? Well, that just might be a blacklist then :) This thread is a month long, and not the first discussion of 4.0.0 for Android. Seriously, though -- the whitelist discussion is much longer than that, and this isn't the first time that the default no-network-access policy has been brought up: (Here's the first question, from *July*: http://markmail.org/message/t4vj4saisem2mcgw Here's where I mentioned what the implemented policy was: http://markmail.org/message/s4necfnh4hnblpjm And in another discussion: http://markmail.org/message/ap7syhqysizmsvrz) If we want to reconsider that decision, then we should certainly do so before we cut a release. I think it would be a real problem to change it afterwards, so let's get it right. Also, it's not the plugin itself that's blocking the release, it's us making sure that we've implemented the core hooks correctly so that the plugin can actually do its job, and that people who don't want that particular plugin can make a better one. (It is also an issue that a plugin, required for cordova-android 4.0.0, breaks apps which are also building for cordova-ios 3.8.0. I'll take a look at that, and either remove the ios-native portions of the whitelist plugin, or neuter it so that it doesn't interfere with an ios app if it's not on the unplug-whitelist branch of that repo.) Ian @purplecabbage risingj.com On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com wrote: legacy-whitelist-plugin should be fixed so that it compiles on cordova-ios@3.8.0. It shouldn't be a problem to fix this at compile or run-time (whichever is applicable here related to the compile error) On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue dvpdin...@gmail.com wrote: On 2 March 2015 at 13:37, Joe Bowser bows...@gmail.com wrote: So, right now the whitelist changes are what's holding up the 4.0.0 release now? Is this really the only thing that's holding up this release? On Wed Feb 25 2015 at 1:18:26 PM Andrew Grieve agri...@chromium.org wrote: I think we'll also need to finish with the whitelist changes have both the legacy and new-way whitelist plugins released before we can do a 4.0.0 release (otherwise you wouldn't be able to write an app
[GitHub] cordova-ios pull request: CB-7428: Enable Swift development of Plu...
Github user cjpearson commented on the pull request: https://github.com/apache/cordova-ios/pull/133#issuecomment-82005079 That's correct. Thanks, @shazron. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
+1 -- Let's get this out the door :) I'll see what I can get done to move it in that direction. On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve agri...@chromium.org wrote: Everything's ready afaik (minus upgrade guide, publishing whitelist plugins, and making it so that the default project template includes plugin name=cordova-plugin-whitelist /). Maybe let's do a RC while we wait on these things being finished up? If anyone wants to take on any of these tasks, that would be awesome. On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com wrote: +1 for vote thread, let's get this thing out so people (that are not us) can test... On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com wrote: OK, this is a three month old thread, and we're waiting on a discussion before we release something? I really think we should go to a vote thread now that we have a legacy whitelist plugin and a new style whitelist plugin. We shouldn't keep constantly delaying this release because of what's happening on other platforms, especially since we already pluginized the whitelist. Can we please release soon? On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal nikhi...@microsoft.com wrote: I know we discussed a couple of approaches implementing the default whitelist policy for Android/iOS - either every app would be required to include the whitelist plugin or have it have smart defaults in the platform implementation and the plugin being able to override them. I don’t think that thread closed with any conclusions. Thanks, Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Thursday, March 12, 2015 11:23 AM To: dev Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release OK, so right now it's just docs? How soon can we get a VOTE thread started for 4.0.0? On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org wrote: mobilespec is now working again... Took longer than I would have liked, but did you know that on Android FileReader triggers shouldInterceptRequest() with Blob URLs!? Separate thread is already happening re: whitelists, so once that's figured out, it's just docs afaict. On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com wrote: We should start a new whitelist plugin related thread. Why is a plugin blocking a release? Default (aka no-plugin) behavior should be to allow all network requests shouldn't it? Well, that just might be a blacklist then :) This thread is a month long, and not the first discussion of 4.0.0 for Android. Seriously, though -- the whitelist discussion is much longer than that, and this isn't the first time that the default no-network-access policy has been brought up: (Here's the first question, from *July*: http://markmail.org/message/t4vj4saisem2mcgw Here's where I mentioned what the implemented policy was: http://markmail.org/message/s4necfnh4hnblpjm And in another discussion: http://markmail.org/message/ap7syhqysizmsvrz) If we want to reconsider that decision, then we should certainly do so before we cut a release. I think it would be a real problem to change it afterwards, so let's get it right. Also, it's not the plugin itself that's blocking the release, it's us making sure that we've implemented the core hooks correctly so that the plugin can actually do its job, and that people who don't want that particular plugin can make a better one. (It is also an issue that a plugin, required for cordova-android 4.0.0, breaks apps which are also building for cordova-ios 3.8.0. I'll take a look at that, and either remove the ios-native portions of the whitelist plugin, or neuter it so that it doesn't interfere with an ios app if it's not on the unplug-whitelist branch of that repo.) Ian @purplecabbage risingj.com On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com wrote: legacy-whitelist-plugin should be fixed so that it compiles on cordova-ios@3.8.0. It shouldn't be a problem to fix this at compile or run-time (whichever is applicable here related to the compile error) On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue dvpdin...@gmail.com wrote: On 2 March 2015 at 13:37, Joe Bowser bows...@gmail.com wrote: So, right now the whitelist changes are what's holding up the 4.0.0 release now? Is this really the only thing that's holding up this release? On Wed Feb 25 2015 at 1:18:26 PM Andrew
[GitHub] cordova-plugin-file-transfer pull request: Fix NoSuchMethodExcepti...
Github user dpogue commented on the pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/68#issuecomment-82073797 /cc @agrieve Would be good to get this in before cordova-android 4.0.0 release. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-ios pull request: CB-7428: Enable Swift development of Plu...
Github user shazron commented on the pull request: https://github.com/apache/cordova-ios/pull/133#issuecomment-81998000 Hi @cjpearson - I'd like this to get in sooner rather than later. Since CB-8643 has been resolved, this can be merged in. I see a Connor Pearson listed as someone that has already signed the Apache iCLA, confirming this is you? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-android pull request: Part of fix for CT-7992
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-android/pull/163#issuecomment-82017424 This should handle it. Will test some more on windows and probably merge tomorrow. https://github.com/apache/cordova-js/pull/104 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Deprecation of Config and the embedded use case (4.0.x related)
Carlos, thats great, then perhaps you could give 4.0 embedded webview a shot to confirm that it is still adequately supported for your customers? I think this thread has been too much talk and not enough trying it out in practice. Everyone agrees the use case is important, what's left is to confirm we got it right. -Michal On Mon, Mar 16, 2015 at 8:58 PM, Carlos Santana csantan...@gmail.com wrote: I just want to add that Joe is not alone on thinking that are developers with this use case. For us we have customers that start with Native Android alone, and then later want to add a Cordova Web View to a portion of their App. And they want an easy way to add a Cordova Web View. For 4.x, I would assume that the developer can choose to make this embedded Cordova Web View CrossWalk based. On Wed, Mar 11, 2015 at 10:24 AM, Joe Bowser bows...@gmail.com wrote: That's why we have tests! I just changed the activity and saw that we have one failure. I'm not sure why this test in particular is failing, since there's too many assertions in one method, so I'll have to try and debug it today. The thing is that if we're deprecating something and replacing it with something else, we should write tests for it. Releasing a 4.0.x and changing how we embed a WebView by changing class names but not fixing up the deprecation is bizzare. On Wed, Mar 11, 2015 at 7:15 AM Andrew Grieve agri...@chromium.org wrote: I wanted to make sure that I didn't break the old way of doing things. On Tue, Mar 10, 2015 at 2:24 PM, Joe Bowser bows...@gmail.com wrote: The main issue is that this isn't documented anywhere, and this is necessary for people to use a Third Party WebView. Also, why didn't you bother updating the test with the new API? On Mon, Mar 9, 2015 at 5:19 PM Andrew Grieve agri...@chromium.org wrote: Here's an example: ConfigXmlParser parser = new ConfigXmlParser(); parser.parse(activity); webView.init(cordova, parser.getPluginEntries(), parser.getPreferences()); Feel free to iterate if you think the API is too obtuse, but I think it's good to allow a file-less mode, and to allow different WebViews to have different settings. On Mon, Mar 9, 2015 at 8:08 PM, Joe Bowser bows...@gmail.com wrote: Do you have an example of how this would work? This seems to be a lot more complex than it needs to be. On Mon, Mar 9, 2015 at 5:05 PM Andrew Grieve agri...@chromium.org wrote: It's so that you can have multiple CordovaWebViews that use different configs within one application. It's also so that you don't have to have a config.xml if you prefer to build up your config in code instead. I don't think loadConfig() is deprecated. It has a @SuppressWarnings(deprecation), which just silences a warning about it setting the config of the Config class (which is done for backwards compatibility). On Mon, Mar 9, 2015 at 3:54 PM, Joe Bowser bows...@gmail.com wrote: OK, this actually makes using the WebView as a component a lot harder, since you now have to have this loadConfig method which you also marked for deprecation required to get all of the necessary attributes out of this. I'm pretty sure this is a major step backwards in that people looking to use Cordova as a component now have to jump through additional hoops to get this to work. What is the benefit of deprecating the Config static class and replacing it with the ConfigXmlParser again? I don't remember why this was done. On Mon, Mar 9, 2015 at 9:04 AM Andrew Grieve agri...@chromium.org wrote: On Mon, Mar 9, 2015 at 11:56 AM, Joe Bowser bows...@gmail.com wrote: On Mon, Mar 9, 2015 at 7:39 AM Andrew Grieve agri...@chromium.org wrote: You can now instantiate a CordovaWebView without a config.xml, and without using Config. This happened when I added an init() method to CordovaWebView. You can pass in a CordovaPreferences object, and a list of PluginEntry. Maybe we just need a better comment on Config saying to use these instead? Where does one get this PluginEntry list when they're embedding a WebView? This needs to be documented or at least put in the test that tests this use case. That has nothing to do with InAppBrowser, this is to do with
[GitHub] cordova-plugin-media pull request: CB-8686 - remove musicLibrary c...
GitHub user muratsu opened a pull request: https://github.com/apache/cordova-plugin-media/pull/48 CB-8686 - remove musicLibrary capability Media plugin by default requests musicLibrary capability but it's not using it. It should be removed since, it's not required. You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-plugin-media CB-8686 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-media/pull/48.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 #48 commit fd9b6fcb9c1d63109d3fe97dd52556420979cd55 Author: Murat Sutunc mura...@microsoft.com Date: 2015-03-16T23:59:57Z CB-8686 - remove musicLibrary capability --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
We'll probably need at least an RC for the whitelist plugin, if not a vote, to be able to vote on this. Or can we just include instructions like Use cordova-plugin-whitelist@f70b1bc for testing while we start the official release process for the plugins? On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland iclell...@chromium.org wrote: +1 -- Let's get this out the door :) I'll see what I can get done to move it in that direction. On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve agri...@chromium.org wrote: Everything's ready afaik (minus upgrade guide, publishing whitelist plugins, and making it so that the default project template includes plugin name=cordova-plugin-whitelist /). Maybe let's do a RC while we wait on these things being finished up? If anyone wants to take on any of these tasks, that would be awesome. On Mon, Mar 16, 2015 at 4:57 PM, Shazron shaz...@gmail.com wrote: +1 for vote thread, let's get this thing out so people (that are not us) can test... On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser bows...@gmail.com wrote: OK, this is a three month old thread, and we're waiting on a discussion before we release something? I really think we should go to a vote thread now that we have a legacy whitelist plugin and a new style whitelist plugin. We shouldn't keep constantly delaying this release because of what's happening on other platforms, especially since we already pluginized the whitelist. Can we please release soon? On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal nikhi...@microsoft.com wrote: I know we discussed a couple of approaches implementing the default whitelist policy for Android/iOS - either every app would be required to include the whitelist plugin or have it have smart defaults in the platform implementation and the plugin being able to override them. I don’t think that thread closed with any conclusions. Thanks, Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Thursday, March 12, 2015 11:23 AM To: dev Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release OK, so right now it's just docs? How soon can we get a VOTE thread started for 4.0.0? On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org wrote: mobilespec is now working again... Took longer than I would have liked, but did you know that on Android FileReader triggers shouldInterceptRequest() with Blob URLs!? Separate thread is already happening re: whitelists, so once that's figured out, it's just docs afaict. On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com wrote: We should start a new whitelist plugin related thread. Why is a plugin blocking a release? Default (aka no-plugin) behavior should be to allow all network requests shouldn't it? Well, that just might be a blacklist then :) This thread is a month long, and not the first discussion of 4.0.0 for Android. Seriously, though -- the whitelist discussion is much longer than that, and this isn't the first time that the default no-network-access policy has been brought up: (Here's the first question, from *July*: http://markmail.org/message/t4vj4saisem2mcgw Here's where I mentioned what the implemented policy was: http://markmail.org/message/s4necfnh4hnblpjm And in another discussion: http://markmail.org/message/ap7syhqysizmsvrz) If we want to reconsider that decision, then we should certainly do so before we cut a release. I think it would be a real problem to change it afterwards, so let's get it right. Also, it's not the plugin itself that's blocking the release, it's us making sure that we've implemented the core hooks correctly so that the plugin can actually do its job, and that people who don't want that particular plugin can make a better one. (It is also an issue that a plugin, required for cordova-android 4.0.0, breaks apps which are also building for cordova-ios 3.8.0. I'll take a look at that, and either remove the ios-native portions of the whitelist plugin, or neuter it so that it doesn't interfere with an ios app if it's not on the unplug-whitelist branch of that repo.) Ian @purplecabbage risingj.com On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com wrote: legacy-whitelist-plugin should be fixed so that it compiles on cordova-ios@3.8.0. It shouldn't be a problem to fix this at compile or run-time (whichever is applicable here related to the compile error) On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue
Re: Medic Improvements
Hi Dmitry,
I am working in add Firefox OS platform
https://github.com/marti1125/cordova-medic I had problem with with some
plugins media and mediacapture because itself doesn't suppor. In
cordova-repos.json
when I run in console $ buildslave start slave_firefoxos I have to remove:
{
title : MEDIA,
repo :
https://git-wip-us.apache.org/repos/asf/cordova-plugin-media.git;,
category : CORDOVA-PLUGIN,
release : master,
current :master
},{
title : MEDIACAPTURE,
repo :
https://git-wip-us.apache.org/repos/asf/cordova-plugin-media-capture.git;,
category : CORDOVA-PLUGIN,
release : master,
current :master
}
Regards,
Willy
2015-03-14 22:49 GMT-05:00 Dmitry Blotsky dblot...@microsoft.com:
Hi list,
I have made a PR with some code cleanup and slight redesign for Medic, and
I would like to please request a code review from folks in the community
when it would be convenient for them! The PR is here:
https://github.com/apache/cordova-medic/pull/37. For those interested in
the details but not in reviewing the code, below are a list of changes and
their justifications and a list of the specific incompatibilities with the
previous medic code.
Code Changes and Reasons:
1. Putting private data into a private file: this was done to remove
passwords from the repo
2. Splitting config into several files: this was done so that the
config can be extended locally without affecting other installations that
share code (i.e. Apache Infra Buildbot)
3. Removing PlatformTestBase and its child classes: this was done in
favour of using build properties to modify build steps instead of hard
platform code as much as possible
4. Using Buildbot Properties to pass parameters to builds: this was
done so that medic doesn’t need to be reconfigured/restarted to run
parametrized builds, which allows it to run in Apache Infrastructure and
enables faster development
5. Adding step wrappers: this was done to reduce the probability of
errors by setting sensible defaults for values that are easily forgotten
6. Removing categories from repo config: this was done to reduce
code complexity for the checkout steps
Incompatibilities:
1. The format of the `cordova-repos.json` file has changed; current
files will need to simply be reformatted to match the new format, and they
will work with the new medic code
2. Semantics of the `cordova-config.json` file have changed, and
current setups will stop being able to control some of medic’s behaviour
using their current files; namely, builders and schedulers are now
configured in cordova.conf, and some platform settings have been removed
(e.g. iOS keychain information)
Kindly,
Dmitry
--
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Rep: https://reps.mozilla.org/u/Willy/
Mozilla Hispano - Willyaguirre
https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
RE: Medic Improvements
Hi Willy,
I suppose just deleting repositories from cordova-repos.json will not help.
Medic uses mobile-spec application to run plugin tests. It has both media and
media-capture plugins as a dependencies
https://github.com/apache/cordova-mobile-spec/blob/master/dependencies-plugin/plugin.xml.
So the `createmobilespec` step will fail in current medic (as well as Dmitry's
version).
A good solution will be to implement special parameter to createmobilespec
script to be able to specify a list of plugins to be included in mobile-spec
app. After it we could add conditional step to medic that will executes
createmobilespec script with limited list of plugins in case Firefox OS
platform is building.
Regards, Dmitriy
-Original Message-
From: Willy Aguirre [mailto:marti1...@gmail.com]
Sent: Monday, March 16, 2015 4:15 PM
To: dev@cordova.apache.org
Subject: Re: Medic Improvements
Hi Dmitry,
I am working in add Firefox OS platform
https://github.com/marti1125/cordova-medic I had problem with with some plugins
media and mediacapture because itself doesn't suppor. In cordova-repos.json
when I run in console $ buildslave start slave_firefoxos I have to remove:
{
title : MEDIA,
repo :
https://git-wip-us.apache.org/repos/asf/cordova-plugin-media.git;,
category : CORDOVA-PLUGIN,
release : master,
current :master
},{
title : MEDIACAPTURE,
repo :
https://git-wip-us.apache.org/repos/asf/cordova-plugin-media-capture.git;,
category : CORDOVA-PLUGIN,
release : master,
current :master
}
Regards,
Willy
2015-03-14 22:49 GMT-05:00 Dmitry Blotsky dblot...@microsoft.com:
Hi list,
I have made a PR with some code cleanup and slight redesign for Medic,
and I would like to please request a code review from folks in the
community when it would be convenient for them! The PR is here:
https://github.com/apache/cordova-medic/pull/37. For those interested
in the details but not in reviewing the code, below are a list of
changes and their justifications and a list of the specific
incompatibilities with the previous medic code.
Code Changes and Reasons:
1. Putting private data into a private file: this was done to remove
passwords from the repo
2. Splitting config into several files: this was done so that the
config can be extended locally without affecting other installations
that share code (i.e. Apache Infra Buildbot)
3. Removing PlatformTestBase and its child classes: this was done in
favour of using build properties to modify build steps instead of hard
platform code as much as possible
4. Using Buildbot Properties to pass parameters to builds: this was
done so that medic doesn’t need to be reconfigured/restarted to run
parametrized builds, which allows it to run in Apache Infrastructure
and enables faster development
5. Adding step wrappers: this was done to reduce the probability of
errors by setting sensible defaults for values that are easily forgotten
6. Removing categories from repo config: this was done to reduce
code complexity for the checkout steps
Incompatibilities:
1. The format of the `cordova-repos.json` file has changed; current
files will need to simply be reformatted to match the new format, and
they will work with the new medic code
2. Semantics of the `cordova-config.json` file have changed, and
current setups will stop being able to control some of medic’s
behaviour using their current files; namely, builders and schedulers
are now configured in cordova.conf, and some platform settings have
been removed (e.g. iOS keychain information)
Kindly,
Dmitry
--
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Rep: https://reps.mozilla.org/u/Willy/ Mozilla Hispano - Willyaguirre
https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-globalization pull request: CB-7960 Add cordova-plu...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-globalization/pull/33 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Introduction for Julian Horn
Hi Jesse,
While it's certainly true that it's impossible to bullet-proof Cordova,
protection against multiple inclusion is pretty basic. All the C system
include files protect against multiple inclusion. JavaScript objects like
jQuery include code to tolerate multiple inclusion. We should too.
The fix certainly does not require a large chunk of time! Here's the entire
fix; you put this up near the top of cordova.js, inside the outermost function
invocation:
if (window.cordova) {
return;
}
To appreciate why this matters, I think you have to cultivate a product
viewpoint. The Intel XDK is a development toolkit that attempts to make
cross-platform HTML5 more approachable. Obviously, as people get farther into
HTML5 development they will run into all kinds of hard problems. But right out
of the box, you want people to be able to put together simple apps simply.
That kind of good initial experience is a key to making an approachable
product.
This particular mistake, of including two script tags for cordova.js, is easy
to make and really hard to diagnose. In fact, some quite experienced
developers made this mistake and found it really hard to figure out how that
mistake led to the observed symptoms. You have to dig into cordova.js to
figure it out, and this is not the simplest piece of code. You don't want
ordinary Cordova users to have to do that if you can avoid it.
Julian
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Friday, March 13, 2015 6:14 PM
To: dev@cordova.apache.org
Subject: Re: Introduction for Julian Horn
Hello and welcome (back?) Julian!
I have added you as an assignable user in JIRA, and assigned this issue to you.
You also should be able to assign issues to yourself now.
Regarding this specific issue, I think I agree with Joe's comment in JIRA that
this is probably not a bug. There are literally millions of stupid things that
people can do to their projects to break them, and I think if we fix stupid in
code, we perpetuate it.
Not a requirement, but I would recommend you share your proposed solution to
this before you spend a large chunk of time on it.
@purplecabbage
risingj.com
On Fri, Mar 13, 2015 at 2:55 PM, Shazron shaz...@gmail.com wrote:
Welcome!
You mean https://issues.apache.org/jira/browse/CB-7992 of course ;)
On Fri, Mar 13, 2015 at 2:20 PM, Horn, Julian C
julian.c.h...@intel.com
wrote:
Hello! I am Julian Horn. I'm a software engineer in the Intel XDK
team. I am the team lead for the Device Emulator component, our
derivative of the Ripple emulator.
I have signed and sent in an individual contributor agreement, and
my
company has a corporate contributor agreement signed.
I have posted mail to this mail list and to the ripple mailing list
before, but this will be my first contribution.
To get my feet wet, I would like to take on CT-7792. This is a
small
JIRA I filed that complains about what happens if a user accidentally
codes two script tags for cordova.js.
How do I go about getting this JIRA assigned to me?
While this is a fairly trivial issue, we have found this is a common
mistake that new users make, especially when they are developing an
application from building blocks. People can become confused about
whether the script tag is already in the template or whether they
have to add it themselves and they end up with two. The behavior you
get when you make this mistake and you run in the Device Emulator is
bizarre, to say the least. That's why I want to fix this.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugins pull request: TCP Socket working for FxOS
GitHub user zalun opened a pull request: https://github.com/apache/cordova-plugins/pull/21 TCP Socket working for FxOS You can merge this pull request into a Git repository by running: $ git pull https://github.com/zalun/cordova-plugins tcp-socket-plugin Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugins/pull/21.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 #21 commit 3319513bda5e43b819fbace1d621758ddca865b1 Author: Piotr Zalewa pi...@zalewa.info Date: 2015-03-16T13:10:02Z TCP Socket working for FxOS --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-media-capture pull request: CB-7963 Adds support fo...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-media-capture/pull/31 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-inappbrowser pull request: CB-7961 Add cordova-plug...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-inappbrowser/pull/76 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-inappbrowser pull request: CB-8659 - Update InAppBr...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-inappbrowser/pull/93 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [Vote] 3.8.0 Cordova App Hello World Release (attempt 3)
+1 On Fri, Mar 13, 2015 at 3:01 PM, Mark Koudritsky kam...@google.com wrote: +1 Built and ran on - Android 5.0.2 on Nexus 7 - iOS simulator On Fri, Mar 13, 2015 at 2:32 PM, Steven Gill stevengil...@gmail.com wrote: Please review and vote on this 3.8.0 Cordova App Hello World Release. Release issue: https://issues.apache.org/jira/browse/CB-8645 Repos ready to be released have been published to dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8645 The package was published from its corresponding git tag: cordova-app-hello-world: 3.8.0 (5e572b6bd2) Upon a successful vote I will upload the archive to dist/ and publish it to NPM. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md Voting will go on for a minimum of 48 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ran coho check-license to ensure all dependencies and subdependencies have Apache-compatible licenses * Built a hello world app using the CLI
[GitHub] cordova-plugin-file-transfer pull request: [windows] added supprt ...
GitHub user biodiv opened a pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/70 [windows] added supprt for cdvfile:// Added support for cdvfile:// paths You can merge this pull request into a Git repository by running: $ git pull https://github.com/biodiv/cordova-plugin-file-transfer master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-file-transfer/pull/70.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 #70 commit 72febdb4a4e0783a36493a31401f0bd8e69d9050 Author: biodiv t...@eyesonic.net Date: 2015-03-16T15:33:59Z Update FileTransferProxy.js Added support for cdvfile:// paths --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-camera pull request: fix wp8.1 UI, added wp8.1 focu...
GitHub user biodiv opened a pull request: https://github.com/apache/cordova-plugin-camera/pull/77 fix wp8.1 UI, added wp8.1 focus control You can merge this pull request into a Git repository by running: $ git pull https://github.com/biodiv/cordova-plugin-camera master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-plugin-camera/pull/77.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 #77 commit ea6acfacf4a16540bc18fc711fbbcee4f856d713 Author: Tom t...@eyesonic.net Date: 2015-03-16T17:06:24Z [windows-wp8] Update CameraProxy.js fixed wp8 camera UI, added support for focus commit d824fdedc48e992adcc1adf1b7e392d072665a8d Author: Tom t...@eyesonic.net Date: 2015-03-16T17:08:07Z Update CameraProxy.js fixed windows-wp8 UI, added support for focus in windows-wp8 commit 683f599679dab6f26b9841e908fd6fe293da6072 Author: Tom t...@eyesonic.net Date: 2015-03-16T17:13:01Z Update CameraProxy.js fixed camera UI to wp8.1, added focus control to wp8.1 commit 578e77b6c649d87327425037aaeda8682bfe5913 Author: Tom t...@eyesonic.net Date: 2015-03-16T17:14:13Z Update CameraProxy.js fixded UI for wp8.1, added focus control to wp8.1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-wp8 pull request: JsonHelper testing, and use of Newtonsof...
Github user robpaveza commented on the pull request: https://github.com/apache/cordova-wp8/pull/62#issuecomment-81827543 LGTM. Was worried about possible compatibility breaks, but that library respects Data Contract attributes. So, should be g2g. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Introduction for Julian Horn
On Mon, Mar 16, 2015 at 6:40 AM Horn, Julian C julian.c.h...@intel.com
wrote:
The fix certainly does not require a large chunk of time! Here's the
entire fix; you put this up near the top of cordova.js, inside the
outermost function invocation:
if (window.cordova) {
return;
}
And nothing is stopping you from issuing a pull request. While Jesse and I
think that we shouldn't get into the practice of fixing people's JS errors,
I'm sure that someone in this project might agree with you. I just don't
think it's a bug, or even an improvement.
Re: Introduction for Julian Horn
And what about detecting if the user didn't include any cordova tag?
I usually see questions on stackoverflow asking, X feature of cordova
isn't working. And the accepted answer is include the cordova.js script
tag in you index.html
2015-03-16 14:37 GMT+01:00 Horn, Julian C julian.c.h...@intel.com:
Hi Jesse,
While it's certainly true that it's impossible to bullet-proof Cordova,
protection against multiple inclusion is pretty basic. All the C system
include files protect against multiple inclusion. JavaScript objects like
jQuery include code to tolerate multiple inclusion. We should too.
The fix certainly does not require a large chunk of time! Here's the
entire fix; you put this up near the top of cordova.js, inside the
outermost function invocation:
if (window.cordova) {
return;
}
To appreciate why this matters, I think you have to cultivate a product
viewpoint. The Intel XDK is a development toolkit that attempts to make
cross-platform HTML5 more approachable. Obviously, as people get farther
into HTML5 development they will run into all kinds of hard problems. But
right out of the box, you want people to be able to put together simple
apps simply. That kind of good initial experience is a key to making an
approachable product.
This particular mistake, of including two script tags for cordova.js, is
easy to make and really hard to diagnose. In fact, some quite experienced
developers made this mistake and found it really hard to figure out how
that mistake led to the observed symptoms. You have to dig into cordova.js
to figure it out, and this is not the simplest piece of code. You don't
want ordinary Cordova users to have to do that if you can avoid it.
Julian
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Friday, March 13, 2015 6:14 PM
To: dev@cordova.apache.org
Subject: Re: Introduction for Julian Horn
Hello and welcome (back?) Julian!
I have added you as an assignable user in JIRA, and assigned this issue to
you. You also should be able to assign issues to yourself now.
Regarding this specific issue, I think I agree with Joe's comment in JIRA
that this is probably not a bug. There are literally millions of stupid
things that people can do to their projects to break them, and I think if
we fix stupid in code, we perpetuate it.
Not a requirement, but I would recommend you share your proposed solution
to this before you spend a large chunk of time on it.
@purplecabbage
risingj.com
On Fri, Mar 13, 2015 at 2:55 PM, Shazron shaz...@gmail.com wrote:
Welcome!
You mean https://issues.apache.org/jira/browse/CB-7992 of course ;)
On Fri, Mar 13, 2015 at 2:20 PM, Horn, Julian C
julian.c.h...@intel.com
wrote:
Hello! I am Julian Horn. I'm a software engineer in the Intel XDK
team. I am the team lead for the Device Emulator component, our
derivative of the Ripple emulator.
I have signed and sent in an individual contributor agreement, and
my
company has a corporate contributor agreement signed.
I have posted mail to this mail list and to the ripple mailing list
before, but this will be my first contribution.
To get my feet wet, I would like to take on CT-7792. This is a
small
JIRA I filed that complains about what happens if a user accidentally
codes two script tags for cordova.js.
How do I go about getting this JIRA assigned to me?
While this is a fairly trivial issue, we have found this is a common
mistake that new users make, especially when they are developing an
application from building blocks. People can become confused about
whether the script tag is already in the template or whether they
have to add it themselves and they end up with two. The behavior you
get when you make this mistake and you run in the Device Emulator is
bizarre, to say the least. That's why I want to fix this.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-media-capture pull request: CB-8687 consolidate man...
Github user nikhilkh commented on the pull request: https://github.com/apache/cordova-plugin-media-capture/pull/35#issuecomment-82107826 @vladimir-kotikov Can you please review? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-ios pull request: CB-7428: Enable Swift development of Plu...
Github user shazron commented on the pull request: https://github.com/apache/cordova-ios/pull/133#issuecomment-82120865 PR merged into 4.0.x branch, see above commit reference and CB-7428 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [GitHub] cordova-plugin-file-transfer pull request: Fix NoSuchMethodExcepti...
They are independent no? Is this plugin relying on cordova-android 4.0? Or vice versa On Mar 16, 2015, at 8:39 PM, dpogue g...@git.apache.org wrote: Github user dpogue commented on the pull request: https://github.com/apache/cordova-plugin-file-transfer/pull/68#issuecomment-82073797 /cc @agrieve Would be good to get this in before cordova-android 4.0.0 release. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - 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
[GitHub] cordova-lib pull request: Allow hyphen in platform name
Github user asfgit closed the pull request at: https://github.com/apache/cordova-lib/pull/186 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-lib pull request: CB-8670 Error when set engine name to c...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-lib/pull/185 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
OK, this is a three month old thread, and we're waiting on a discussion before we release something? I really think we should go to a vote thread now that we have a legacy whitelist plugin and a new style whitelist plugin. We shouldn't keep constantly delaying this release because of what's happening on other platforms, especially since we already pluginized the whitelist. Can we please release soon? On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal nikhi...@microsoft.com wrote: I know we discussed a couple of approaches implementing the default whitelist policy for Android/iOS - either every app would be required to include the whitelist plugin or have it have smart defaults in the platform implementation and the plugin being able to override them. I don’t think that thread closed with any conclusions. Thanks, Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Thursday, March 12, 2015 11:23 AM To: dev Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release OK, so right now it's just docs? How soon can we get a VOTE thread started for 4.0.0? On Wed, Mar 4, 2015 at 10:47 AM Andrew Grieve agri...@chromium.org wrote: mobilespec is now working again... Took longer than I would have liked, but did you know that on Android FileReader triggers shouldInterceptRequest() with Blob URLs!? Separate thread is already happening re: whitelists, so once that's figured out, it's just docs afaict. On Mon, Mar 2, 2015 at 10:52 PM, Ian Clelland iclell...@chromium.org wrote: On Mon, Mar 2, 2015 at 6:00 PM, Jesse purplecabb...@gmail.com wrote: We should start a new whitelist plugin related thread. Why is a plugin blocking a release? Default (aka no-plugin) behavior should be to allow all network requests shouldn't it? Well, that just might be a blacklist then :) This thread is a month long, and not the first discussion of 4.0.0 for Android. Seriously, though -- the whitelist discussion is much longer than that, and this isn't the first time that the default no-network-access policy has been brought up: (Here's the first question, from *July*: http://markmail.org/message/t4vj4saisem2mcgw Here's where I mentioned what the implemented policy was: http://markmail.org/message/s4necfnh4hnblpjm And in another discussion: http://markmail.org/message/ap7syhqysizmsvrz) If we want to reconsider that decision, then we should certainly do so before we cut a release. I think it would be a real problem to change it afterwards, so let's get it right. Also, it's not the plugin itself that's blocking the release, it's us making sure that we've implemented the core hooks correctly so that the plugin can actually do its job, and that people who don't want that particular plugin can make a better one. (It is also an issue that a plugin, required for cordova-android 4.0.0, breaks apps which are also building for cordova-ios 3.8.0. I'll take a look at that, and either remove the ios-native portions of the whitelist plugin, or neuter it so that it doesn't interfere with an ios app if it's not on the unplug-whitelist branch of that repo.) Ian @purplecabbage risingj.com On Mon, Mar 2, 2015 at 2:02 PM, Shazron shaz...@gmail.com wrote: legacy-whitelist-plugin should be fixed so that it compiles on cordova-ios@3.8.0. It shouldn't be a problem to fix this at compile or run-time (whichever is applicable here related to the compile error) On Mon, Mar 2, 2015 at 1:47 PM, Darryl Pogue dvpdin...@gmail.com wrote: On 2 March 2015 at 13:37, Joe Bowser bows...@gmail.com wrote: So, right now the whitelist changes are what's holding up the 4.0.0 release now? Is this really the only thing that's holding up this release? On Wed Feb 25 2015 at 1:18:26 PM Andrew Grieve agri...@chromium.org wrote: I think we'll also need to finish with the whitelist changes have both the legacy and new-way whitelist plugins released before we can do a 4.0.0 release (otherwise you wouldn't be able to write an app that hits the network) Just FYI, the whitelist stuff is proving to be a bit of a pain point. I'm using cordova-android@master, and need to install the legacy-whitelist plugin in order to make network requests. Once the plugin is installed, everything seems to work. The problem is that the legacy-whitelist plugin generates compile errors with cordova-ios@3.8.0, so now I can't just run `cordova build`, I need to split the platforms up and install/uninstall the plugin in between. If someone makes a dev build for Android and forgets the plugin, it will appear to build successfully but not actually
[GitHub] cordova-lib pull request: Allow hyphen in platform name
Github user kamrik commented on the pull request: https://github.com/apache/cordova-lib/pull/186#issuecomment-81965293 Looks good, merging. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-lib pull request: Make required subdirectories for icons
Github user asfgit closed the pull request at: https://github.com/apache/cordova-lib/pull/169 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Introduction for Byoungro So
Hi, I would like to introduce myself. I have been working for Intel as a software architect for 10 years, and had worked for several research institutes (including IBM T. J. Watson) before I join Intel. I had designed and developed the SIMD support in the JavaScript W3C standardization effort. Currently, I am responsible for developing the Cordova component in the Intel XDK, and have been tweaking Cordova to make it work in the XDK environment. I would like to upstream several enhancements that I have developed for the last few years. My first contribution would be CB-8455https://issues.apache.org/jira/browse/CB-8455, which could improve the security aspect of Cordova. This feature is already included in the Intel XDK. Can someone assign this issue to me, or give me the assigner privilege? Hope to talk to you often. Byoungro So SSG / DPD / Mobile Computing and Compilers Intel Corporation
RE: Introduction for Julian Horn
Well, I can see that this is kind of a philosophical disagreement.
Today having two script tags for cordova.js is defined to be an error. As
such the current behavior of cordova.js is correct. But you could just as well
have said that it's not an error. I think that's a better choice.
I've spent most of my career working on software development tools for various
languages. Generally we try to minimize uncheckable constraints or gotchas
when we can. This makes things a little harder for a few tools vendors and a
little easier for large numbers of developers. That's usually an easy decision
to make.
When you create a new Cordova project in the Intel XDK, we provide a template
that includes a script tag for cordova.js. This means the only way you can
lack the tag is if you delete it (or import a project that was missing the
tag). That's a great thing: it makes it much less likely that users will
forget to include cordova.js and wind up wasting hours looking for an
explanation.
However, the opposite mistake does still happen. People don't read the entire
template (why should they?) and think they have to add the tag themselves.
That's how new users sometimes get into this situation. We would like that not
to be an error; it just makes things a little smoother and more forgiving,
which is our goal.
I will certainly submit a pull request.
Julian
-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com]
Sent: Monday, March 16, 2015 1:36 PM
To: dev@cordova.apache.org
Subject: Re: Introduction for Julian Horn
On Mon, Mar 16, 2015 at 6:40 AM Horn, Julian C julian.c.h...@intel.com
wrote:
The fix certainly does not require a large chunk of time! Here's the
entire fix; you put this up near the top of cordova.js, inside the
outermost function invocation:
if (window.cordova) {
return;
}
And nothing is stopping you from issuing a pull request. While Jesse and I
think that we shouldn't get into the practice of fixing people's JS errors, I'm
sure that someone in this project might agree with you. I just don't think
it's a bug, or even an improvement.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Introduction for Byoungro So
Welcome Byoungro So! I've given you the appropriate role and assigned you. On Sun, Mar 15, 2015 at 11:47 PM, So, Byoungro byoungro...@intel.com wrote: Hi, I would like to introduce myself. I have been working for Intel as a software architect for 10 years, and had worked for several research institutes (including IBM T. J. Watson) before I join Intel. I had designed and developed the SIMD support in the JavaScript W3C standardization effort. Currently, I am responsible for developing the Cordova component in the Intel XDK, and have been tweaking Cordova to make it work in the XDK environment. I would like to upstream several enhancements that I have developed for the last few years. My first contribution would be CB-8455https://issues.apache.org/jira/browse/CB-8455, which could improve the security aspect of Cordova. This feature is already included in the Intel XDK. Can someone assign this issue to me, or give me the assigner privilege? Hope to talk to you often. Byoungro So SSG / DPD / Mobile Computing and Compilers Intel Corporation - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-medic pull request: Medic Refactor
Github user dmitriy-barkalov commented on a diff in the pull request:
https://github.com/apache/cordova-medic/pull/37#discussion_r26515411
--- Diff: buildbot-conf/cordova-internal.conf ---
@@ -0,0 +1,101 @@
+import os
+import json
+
+from buildbot.changes.gitpoller import GitPoller
+from buildbot.schedulers.forcesched import ForceScheduler
+
+# config
+MEDIC_CONFIG_FILE= os.path.join(FP, 'cordova-config.json')
+PROJECTS_CONFIG_FILE = os.path.join(FP, 'cordova-repos.json')
+
+def parse_config_file(file_name):
+with open(file_name, 'r') as config_file:
+return json.load(config_file)
+
+medic_config= parse_config_file(MEDIC_CONFIG_FILE)
+projects_config = parse_config_file(PROJECTS_CONFIG_FILE)
+
+# constants
+GIT_BIN = 'git' if os.name != 'nt' else 'C:\Program Files
(x86)\Git\cmd\git.exe'
+GITPOLLER_DIR = 'gitpoller-workdir'
+
+POLLED_PROJECT_PATTERNS = [
+'cordova-mobile-spec',
+'cordova-lib',
+'cordova-js',
+'cordova-cli',
+'cordova-medic',
+'cordova-plugman',
+'cordova-windows',
+'cordova-android',
+]
+
+### UTILITIES
+
+# helpers
+def cordova_builders():
+return [b.name for b in c['builders'] if b.name.startswith('cordova-')]
+
+def is_polled_project(project_name):
+return True if any(pattern in project_name for pattern in
POLLED_PROJECT_PATTERNS) else False
+
+def get_polled_projects():
+return (project for project_name, project in projects_config.items()
if is_polled_project(project_name))
+
+def make_git_poller(repo_uri):
+# NOTE:
+# branches=True means watching all branches
+return GitPoller(repo_uri, workdir=GITPOLLER_DIR, branches=True,
pollinterval=120, gitbin=GIT_BIN)
--- End diff --
Earlier gitpoller was used to start builds per commits to repositories. It
utilized project and category parameters to avoid issue with unrelated builds
(I mentioned above).
I assumed that you are also planing to utilize gitpoller this way. And
pointed that without schedulers and categories / projects it doesn't make
scenes.
I've never mentioned that commits in waterfall. Still if it is valuable
feature I think we can keep gitpoller here.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-lib pull request: CB-8636 Remove FEATURE_SPECIAL_PARAMS fr...
Github user vladimir-kotikov commented on the pull request: https://github.com/apache/cordova-lib/pull/181#issuecomment-81875689 @omefire Could you please delete MSOT branch as well. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-android pull request: Part of fix for CT-7992
Github user purplecabbage commented on the pull request: https://github.com/apache/cordova-android/pull/163#issuecomment-81908413 If only it were that easy ... This file is generated so we cannot just modify it. Changes need to be implemented in the cordova-js repo. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-android pull request: Part of fix for CT-7992
GitHub user jchorn opened a pull request: https://github.com/apache/cordova-android/pull/163 Part of fix for CT-7992 New Cordova users, especially those building applications from building blocks, sometimes end up with more than one script tag for cordova.js. This currently results in bizarre behavior. This change makes such mistakes harmless, thus resulting in a more user-friendly experience. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jchorn/cordova-android master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-android/pull/163.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 #163 commit 7861e4d7132988e0be2f43a0edd382086f4710c5 Author: Julian Horn julian.c.h...@intel.com Date: 2015-03-16T19:59:24Z Part of fix for CT-7992 New Cordova users, especially those building applications from building blocks, sometimes end up with more than one script tag for cordova.js. This currently results in bizarre behavior. This change makes such mistakes harmless, thus resulting in a more user-friendly experience. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-android pull request: Part of fix for CT-7992
Github user jchorn closed the pull request at: https://github.com/apache/cordova-android/pull/163 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-android pull request: Part of fix for CT-7992
Github user jchorn commented on the pull request: https://github.com/apache/cordova-android/pull/163#issuecomment-81909526 Thanks for the pointer! I had a feeling all these platforms were sharing code somewhere. I will try again with the right component. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[GitHub] cordova-plugin-media pull request: CB-7962 Adds browser platform s...
Github user asfgit closed the pull request at: https://github.com/apache/cordova-plugin-media/pull/45 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
