Re: Jake woes
+1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js?
Re: Media API, DataResource, and empty URLs
On Thu, Jun 20, 2013 at 11:45 AM, Andrew Grieve agri...@chromium.orgwrote: WebView.getUrl() ? Or that, modulo any base tags that we detect? On Thu, Jun 20, 2013 at 9:49 AM, Braden Shepherdson bra...@chromium.org wrote: So the current state of handling URLs in DataResource is: if it has a scheme, all good; if it doesn't and is absolute, also good; if it is relative and has no scheme, throw new IllegalArgumentException. I agree that this behavior is dumb and there should be a sane default for relative URLs, and DataResource should rewrite them. The tricky bit is what they should be relative to. file:///android_asset/www? The currently loaded page in the WebView? Can we reliably check that in the presence of CordovaView and InAppBrowser? Braden On Thu, Jun 20, 2013 at 12:34 AM, Andrew Grieve agri...@chromium.org wrote: Agree that we should make Media() an error, but we don't want to change the semantics of relative URLs for APIs without proper deprecation. On Thu, Jun 20, 2013 at 12:00 AM, Ian Clelland iclell...@google.com wrote: On Wed, Jun 19, 2013 at 7:41 PM, Andrew Grieve agri...@chromium.org wrote: null could be interpreted as a relative URL I think. The current handling of relative URLs by plugins is sadly plugin-specific. Isn't that one of the things that DataResource is supposed to standardize? The string null is certainly a relative URL, and all plugins should interpret that as one. The empty string is a relative url as well. (See the 'image src=' problem). DataResource should probably handle relative URLs; that seems like a deficiency if it can't. We shouldn't be representing the JavaScript null value as null, or as , though. I don't think there's any rational reason to support new Media() as a construct. Media is fairly clearly documented as taking two required parameters, and two optional ones. I don't think Media() makes sense -- it doesn't give you a useful object. The calls to Media() are likely just in mobile-spec, and we should clean those up. On Wed, Jun 19, 2013 at 4:04 PM, Braden Shepherdson bra...@chromium.org wrote: The automated tests for Media frequently call new Media() with no URL, which sends a null to the create action. In the past, this got turned into the string null in Java, which was handled as a file named null that didn't exist, and nothing crashed. DataResource is fine with the files not existing, but it's not fine with null as a filename since it neither has a URL scheme nor is it an absolute path. Is there a reason why new Media() should work rather than throwing IllegalArgumentExceptions for trying to read files with relative paths? Should I detect and gracefully handle null being given as the media URL in Javascript? In Java? Should I instead change the mobile-spec tests to use file:///dummy or similar? Braden
RE: Suggestion - pluginLoader
So it's been about a week now and I haven't really had any feedback on this. https://github.com/jxp/cordova.pluginLoader I'm not sure if this means; a) Everyone is too busy b) Everyone assumed someone else would respond c) No-one is that interested in plugin javascript definitions d) You've had similar discussions before and don't want to start THAT again From: princej.w...@hotmail.co.uk To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader Date: Tue, 18 Jun 2013 16:55:19 +0100 I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version. I have found a module loader that I wish to use (require.js). My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation. I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed. My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); classic window.plugins, cordova.define and require.js -Original Message- From: J Prince [mailto:princej.w...@hotmail.co.uk] Sent: Monday, June 17, 2013 7:27 AM To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader There are a few main reasons. 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect. So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed. 3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page. The define/require pattern feels much cleaner and better compartmentalized. Our main page currently has 2 script includes: require.js and jqmobi.
Re: Opinions Needed: Platform specific features and mobilespec tests
For tests like this, I'd like to see something in Jasmine that is akin to
the Expected Failure result in JUinit / python unittest.
It means that we still run all of the tests, but a failure on a device that
doesn't support the feature doesn't cause the whole test suite to turn red.
On the other hand, if a test which is expected to fail actually succeeds,
that is reported as unexpected success in the test output. We can then go
and look at what has changed -- either the test is broken, or the issue was
actually resolved.
I don't think it's available as an idiom in Jasmine, but it's just
JavaScript; it shouldn't be too hard to implement.
Ian
On 13-06-20 9:06 AM, Andrew Grieve agri...@chromium.org wrote:
Definitely torn on this one. On one hand, if there are features
implemented
on some platforms that should be implemented on others than having them
fail is a constant reminder that your platform needs to implement the
missing functionality. OTOH, things like camera clean-up are meant to be
platform specific, so it's nothing but an annoyance if that fails on
other
platforms.
So, I think my take on it is:
1. Have them shared and failing if the API should eventually be
implemented
on all platforms
2. Wrap tests in if (platform.name == 'ios') {} if they are meant to
only
work on one platform.
On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca
ldel...@us.ibm.comwrote:
One issue I ran with respects to the mobile spec is some tests are only
applicable to certain device types. We have a couple options when it
comes to those types of tests:
1. Not include them in the automated tests
2. Include them knowing that they *might* cause failures with certain
device types (see example)
3. Add javascript logic to check for device type before performing the
tests
4. OR we could create platform specific automated tests that should be
ran
in addition to the base automated test per device. ex. automatedAndroid,
automatedIOS, etc.
An example is:
https://issues.apache.org/jira/browse/CB-3484
camera.cleanup is only supported on iOS.
I added a test case to verify that the function existed. But it doesn't
actually run camera.cleanup so there are no failure on other platforms.
So
really there shouldn't be any harm in keeping the test.
What are everyone's opinions on a good approach to handle this type of
situation?
Lisa Seacat DeLuca
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful.
Re: cordova-ios/iphone/beep.wav
That was an accidental commit, if it's ended up in cordova-ios. The file was previously in version control; I went back through the git repo history to find and restore it for cordova-mobile-spec, since iOS devices require it for the notification tests. I didn't expect that there would be a licensing issue with the file, but if so, we should replace the version in mobile-spec. On Wed, Jun 19, 2013 at 4:10 PM, Shazron shaz...@gmail.com wrote: Looking at the issue, I don't think it needed a beep.wav, which makes me think this was accidentally checked in On Wed, Jun 19, 2013 at 4:00 PM, Jesse purplecabb...@gmail.com wrote: If you need a wav file for the beep, I have composed a CC licensed file here: https://git-wip-us.apache.org/repos/asf?p=cordova-wp8.git;a=tree;f=common/resources;h=a9558f417570ee1793d34be30b81291750597153;hb=HEAD @purplecabbage risingj.com On Wed, Jun 19, 2013 at 3:30 PM, Shazron shaz...@gmail.com wrote: Ian, was this file supposed to be checked in? https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;h=4c63589 https://issues.apache.org/jira/browse/CB-2840 Ran Apache RAT and noticed that one.
Re: Suggestion - pluginLoader
Hi Jonathan, First, thanks for a well-written proposal. At least for me, I'm not really sure that there is enough of a problem with the current approach that would justify changing it. That said, business is always an issue, and bumping your thread was the right thing to do :) For Android and iOS, the large majority of plugins require native code in order to be useful, so I don't think that having plugin JS be dynamically seems that useful without being able to dynamically load the native parts of it. You said that you're serving your app via HTTP. I think your best bet would be to concat all of your plugin JS together would be by far your biggest performance boost rather than try to selectively load them. Until very recently, Cordova's module system didn't involve a loader at all, and required that all modules be defined ahead of time. Now, we actually do load plugin .js files during start-up, but still not on-demand. So, in my mind we really have two things: 1. A registry 2. A boot-up process. To be clear - is it that you want to change the registry part, or is it just that you want to have plugin .js loaded on-demand? Are you concerned about the native side of the plugins? One thing I think maybe we should add is the ability to disable the start-up plugin_loader.js logic for when people want to package the .js themselves. On Fri, Jun 21, 2013 at 8:30 AM, J Prince princej.w...@hotmail.co.ukwrote: So it's been about a week now and I haven't really had any feedback on this. https://github.com/jxp/cordova.pluginLoader I'm not sure if this means; a) Everyone is too busy b) Everyone assumed someone else would respond c) No-one is that interested in plugin javascript definitions d) You've had similar discussions before and don't want to start THAT again From: princej.w...@hotmail.co.uk To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader Date: Tue, 18 Jun 2013 16:55:19 +0100 I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version. I have found a module loader that I wish to use (require.js). My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation. I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed. My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); classic window.plugins, cordova.define and require.js -Original Message- From: J Prince [mailto:princej.w...@hotmail.co.uk] Sent: Monday, June 17, 2013 7:27 AM To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader There are a few main reasons. 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect. So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed. 3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page. The define/require pattern feels much cleaner and better compartmentalized. Our main page currently has 2 script includes: require.js and jqmobi.
Re: Jake woes
+1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.comwrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js?
RE: Suggestion - pluginLoader
Hi Andrew, My main point was to make the actual plugin javascript definitions more flexible. That way it would support more unusual developer requirements (such as mine). If the plugin definitions did not contain any loader implementation then the same definition can be used different ways by different developers. Currently any existing plugins that I want to use I am making my own copy of and modifying to suit my project. I found this annoying and produced my suggestion based on that experience. I suppose it is as much for developer simplicity as anything else. A format that supported different use cases would be better for me! It would also mean that the cordova team could more easily change the javascript plugin loader in future without breaking existing plugins. I hadn't thought about dynamically loading the native side of plugins. I was just assuming that would always be loaded. From: agri...@chromium.org Date: Fri, 21 Jun 2013 09:12:42 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org Hi Jonathan, First, thanks for a well-written proposal. At least for me, I'm not really sure that there is enough of a problem with the current approach that would justify changing it. That said, business is always an issue, and bumping your thread was the right thing to do :) For Android and iOS, the large majority of plugins require native code in order to be useful, so I don't think that having plugin JS be dynamically seems that useful without being able to dynamically load the native parts of it. You said that you're serving your app via HTTP. I think your best bet would be to concat all of your plugin JS together would be by far your biggest performance boost rather than try to selectively load them. Until very recently, Cordova's module system didn't involve a loader at all, and required that all modules be defined ahead of time. Now, we actually do load plugin .js files during start-up, but still not on-demand. So, in my mind we really have two things: 1. A registry 2. A boot-up process. To be clear - is it that you want to change the registry part, or is it just that you want to have plugin .js loaded on-demand? Are you concerned about the native side of the plugins? One thing I think maybe we should add is the ability to disable the start-up plugin_loader.js logic for when people want to package the .js themselves. On Fri, Jun 21, 2013 at 8:30 AM, J Prince princej.w...@hotmail.co.ukwrote: So it's been about a week now and I haven't really had any feedback on this. https://github.com/jxp/cordova.pluginLoader I'm not sure if this means; a) Everyone is too busy b) Everyone assumed someone else would respond c) No-one is that interested in plugin javascript definitions d) You've had similar discussions before and don't want to start THAT again From: princej.w...@hotmail.co.uk To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader Date: Tue, 18 Jun 2013 16:55:19 +0100 I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version. I have found a module loader that I wish to use (require.js). My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation. I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed. My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); classic window.plugins, cordova.define and require.js -Original Message- From: J Prince [mailto:princej.w...@hotmail.co.uk] Sent: Monday, June 17, 2013 7:27 AM To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader There are a few main reasons. 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect. So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed. 3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page. The define/require pattern feels much cleaner and better compartmentalized. Our main page currently has 2 script includes: require.js and jqmobi.
Re: Jake woes
+1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.comwrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Suggestion - pluginLoader
For your actual app, you're free to use any JS loader that you'd like. Are there really many existing Cordova plugins that use alternate module package definitions? On Fri, Jun 21, 2013 at 9:39 AM, J Prince princej.w...@hotmail.co.ukwrote: Hi Andrew, My main point was to make the actual plugin javascript definitions more flexible. That way it would support more unusual developer requirements (such as mine). If the plugin definitions did not contain any loader implementation then the same definition can be used different ways by different developers. Currently any existing plugins that I want to use I am making my own copy of and modifying to suit my project. I found this annoying and produced my suggestion based on that experience. I suppose it is as much for developer simplicity as anything else. A format that supported different use cases would be better for me! It would also mean that the cordova team could more easily change the javascript plugin loader in future without breaking existing plugins. I hadn't thought about dynamically loading the native side of plugins. I was just assuming that would always be loaded. From: agri...@chromium.org Date: Fri, 21 Jun 2013 09:12:42 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org Hi Jonathan, First, thanks for a well-written proposal. At least for me, I'm not really sure that there is enough of a problem with the current approach that would justify changing it. That said, business is always an issue, and bumping your thread was the right thing to do :) For Android and iOS, the large majority of plugins require native code in order to be useful, so I don't think that having plugin JS be dynamically seems that useful without being able to dynamically load the native parts of it. You said that you're serving your app via HTTP. I think your best bet would be to concat all of your plugin JS together would be by far your biggest performance boost rather than try to selectively load them. Until very recently, Cordova's module system didn't involve a loader at all, and required that all modules be defined ahead of time. Now, we actually do load plugin .js files during start-up, but still not on-demand. So, in my mind we really have two things: 1. A registry 2. A boot-up process. To be clear - is it that you want to change the registry part, or is it just that you want to have plugin .js loaded on-demand? Are you concerned about the native side of the plugins? One thing I think maybe we should add is the ability to disable the start-up plugin_loader.js logic for when people want to package the .js themselves. On Fri, Jun 21, 2013 at 8:30 AM, J Prince princej.w...@hotmail.co.uk wrote: So it's been about a week now and I haven't really had any feedback on this. https://github.com/jxp/cordova.pluginLoader I'm not sure if this means; a) Everyone is too busy b) Everyone assumed someone else would respond c) No-one is that interested in plugin javascript definitions d) You've had similar discussions before and don't want to start THAT again From: princej.w...@hotmail.co.uk To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader Date: Tue, 18 Jun 2013 16:55:19 +0100 I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version. I have found a module loader that I wish to use (require.js). My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation. I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed. My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); classic window.plugins, cordova.define and require.js -Original Message- From: J Prince [mailto:princej.w...@hotmail.co.uk] Sent: Monday, June 17, 2013 7:27 AM To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader There are a few main reasons. 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect. So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed. 3. We
Re: Jake woes
Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.comwrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
RE: Suggestion - pluginLoader
Perhaps my terminology is wrong but ALL plugins define how they are loaded. Either (old style) window.plugins = ... or (new style) cordova.define(... My fundamental point is they shouldn't. I don't want my plugins loaded in either of these ways. The loading of plugins should be separate to the plugin definition. Hence my suggestion of; cordova.pluginLoader(...) In this pattern pluginLoader could either have multiple different modes or developers could override it (or both). At the moment I am having to change each plugin to not define its loading implementation. From: agri...@chromium.org Date: Fri, 21 Jun 2013 10:22:35 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org For your actual app, you're free to use any JS loader that you'd like. Are there really many existing Cordova plugins that use alternate module package definitions? On Fri, Jun 21, 2013 at 9:39 AM, J Prince princej.w...@hotmail.co.ukwrote: Hi Andrew, My main point was to make the actual plugin javascript definitions more flexible. That way it would support more unusual developer requirements (such as mine). If the plugin definitions did not contain any loader implementation then the same definition can be used different ways by different developers. Currently any existing plugins that I want to use I am making my own copy of and modifying to suit my project. I found this annoying and produced my suggestion based on that experience. I suppose it is as much for developer simplicity as anything else. A format that supported different use cases would be better for me! It would also mean that the cordova team could more easily change the javascript plugin loader in future without breaking existing plugins. I hadn't thought about dynamically loading the native side of plugins. I was just assuming that would always be loaded. From: agri...@chromium.org Date: Fri, 21 Jun 2013 09:12:42 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org Hi Jonathan, First, thanks for a well-written proposal. At least for me, I'm not really sure that there is enough of a problem with the current approach that would justify changing it. That said, business is always an issue, and bumping your thread was the right thing to do :) For Android and iOS, the large majority of plugins require native code in order to be useful, so I don't think that having plugin JS be dynamically seems that useful without being able to dynamically load the native parts of it. You said that you're serving your app via HTTP. I think your best bet would be to concat all of your plugin JS together would be by far your biggest performance boost rather than try to selectively load them. Until very recently, Cordova's module system didn't involve a loader at all, and required that all modules be defined ahead of time. Now, we actually do load plugin .js files during start-up, but still not on-demand. So, in my mind we really have two things: 1. A registry 2. A boot-up process. To be clear - is it that you want to change the registry part, or is it just that you want to have plugin .js loaded on-demand? Are you concerned about the native side of the plugins? One thing I think maybe we should add is the ability to disable the start-up plugin_loader.js logic for when people want to package the .js themselves. On Fri, Jun 21, 2013 at 8:30 AM, J Prince princej.w...@hotmail.co.uk wrote: So it's been about a week now and I haven't really had any feedback on this. https://github.com/jxp/cordova.pluginLoader I'm not sure if this means; a) Everyone is too busy b) Everyone assumed someone else would respond c) No-one is that interested in plugin javascript definitions d) You've had similar discussions before and don't want to start THAT again From: princej.w...@hotmail.co.uk To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader Date: Tue, 18 Jun 2013 16:55:19 +0100 I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version. I have found a module loader that I wish to use (require.js). My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation. I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed. My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); classic window.plugins, cordova.define
RE: Opinions Needed: Platform specific features and mobilespec tests
Probably call the test failure for the unimplemented feature as Unimplemented
Failure, and show in jasmine using a different color. Those failure are like a
warning, and means the feature is expected to be supported by the platform, but
is just not yet implemented.
Expected failure is little confusing, as if when expected failure happens,
it means a success test case.
Jonathan
-Original Message-
From: Ian Clelland [mailto:iclell...@google.com]
Sent: Friday, June 21, 2013 8:35 AM
To: dev@cordova.apache.org
Subject: Re: Opinions Needed: Platform specific features and mobilespec tests
For tests like this, I'd like to see something in Jasmine that is akin to
the Expected Failure result in JUinit / python unittest.
It means that we still run all of the tests, but a failure on a device that
doesn't support the feature doesn't cause the whole test suite to turn red.
On the other hand, if a test which is expected to fail actually succeeds,
that is reported as unexpected success in the test output. We can then go
and look at what has changed -- either the test is broken, or the issue was
actually resolved.
I don't think it's available as an idiom in Jasmine, but it's just
JavaScript; it shouldn't be too hard to implement.
Ian
On 13-06-20 9:06 AM, Andrew Grieve agri...@chromium.org wrote:
Definitely torn on this one. On one hand, if there are features
implemented
on some platforms that should be implemented on others than having them
fail is a constant reminder that your platform needs to implement the
missing functionality. OTOH, things like camera clean-up are meant to be
platform specific, so it's nothing but an annoyance if that fails on
other
platforms.
So, I think my take on it is:
1. Have them shared and failing if the API should eventually be
implemented
on all platforms
2. Wrap tests in if (platform.name == 'ios') {} if they are meant to
only
work on one platform.
On Thu, Jun 20, 2013 at 8:44 AM, Lisa Seacat DeLuca
ldel...@us.ibm.comwrote:
One issue I ran with respects to the mobile spec is some tests are only
applicable to certain device types. We have a couple options when it
comes to those types of tests:
1. Not include them in the automated tests
2. Include them knowing that they *might* cause failures with certain
device types (see example)
3. Add javascript logic to check for device type before performing the
tests
4. OR we could create platform specific automated tests that should be
ran
in addition to the base automated test per device. ex. automatedAndroid,
automatedIOS, etc.
An example is:
https://issues.apache.org/jira/browse/CB-3484
camera.cleanup is only supported on iOS.
I added a test case to verify that the function existed. But it doesn't
actually run camera.cleanup so there are no failure on other platforms.
So
really there shouldn't be any harm in keeping the test.
What are everyone's opinions on a good approach to handle this type of
situation?
Lisa Seacat DeLuca
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other
than the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and
delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended
recipients is not authorized and may be unlawful.
Re: Review Request: Fixing exec bug.
On June 21, 2013, 2:33 a.m., Andrew Grieve wrote: framework/src/org/apache/cordova/api/PluginManager.java, line 226 https://reviews.apache.org/r/12013/diff/1/?file=309778#file309778line226 These params don't need to be final. Isn't it better to make them final unless there is a need to modify them? On June 21, 2013, 2:33 a.m., Andrew Grieve wrote: framework/src/org/apache/cordova/api/PluginManager.java, line 434 https://reviews.apache.org/r/12013/diff/1/?file=309778#file309778line434 I realized tonight that a boolean here isn't enough. Consider this case: 1. set runExecOnUiThread = true 2. runExecOnUiThread=false Runnable queued. 3. Exec call foo gets made, Runnable queued. 4. runExecOnUiThread=false runs 5. Exec call bar gets made, executes right away 6. Exec call foo Runnable is run We don't want to ever execute calls out-of-order. bar shouldn't get run before foo. I think to fix this, we can use an AtomicInteger. Increment it every time an exec is queued, decrement it each time an exec finishes. Turn off runExecOnUiThread only once the count reaches 0. make sense? If an app is making execs too fast couldn't it cause every exec to be run the UI thread and never switch to using the WebCore thread? Is it possible to leave runExecOnUiThread getting set like it currently is, use your AtomicInteger idea to track the number of pending execs on the UI thread and then make WebCore execs block until this value is 0. We would have to make sure that if multiple WebCore execs get blocked, when they get unblocked they get execute in the same order that they came in. - Jeffrey --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/#review9 --- On June 20, 2013, 8:16 p.m., Jeffrey Willms wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/ --- (Updated June 20, 2013, 8:16 p.m.) Review request for cordova and Andrew Grieve. Description --- Fixing exec bug. This addresses bug CB-3927. https://issues.apache.org/jira/browse/CB-3927 Diffs - framework/src/org/apache/cordova/api/PluginEntry.java 9b9af6bc303965e7263bca75037256da81868fb2 framework/src/org/apache/cordova/api/PluginManager.java 71fc25817b5d58bb2fbf5a29158ef2c7d424d4ab Diff: https://reviews.apache.org/r/12013/diff/ Testing --- Thanks, Jeffrey Willms
Re: Cordova Blog
This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com
Re: Suggestion - pluginLoader
aha, so previously we didn't help plugins along at all. With plugman-compatible plugins, we do define a way for plugin JS to be loaded: you add a js-module tag to your plugin.xml and then plugman will wrap your file in a cordova.define(). Spec: https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md You can also specify a runs/ tag in js-module which just causes your .js file to be executed after cordova.js is parsed. I think with this, you could layer on another module loading system if you wanted something outside of the cordova.define() system. Does that make sense? On Fri, Jun 21, 2013 at 10:41 AM, J Prince princej.w...@hotmail.co.ukwrote: Perhaps my terminology is wrong but ALL plugins define how they are loaded. Either (old style) window.plugins = ... or (new style) cordova.define(... My fundamental point is they shouldn't. I don't want my plugins loaded in either of these ways. The loading of plugins should be separate to the plugin definition. Hence my suggestion of; cordova.pluginLoader(...) In this pattern pluginLoader could either have multiple different modes or developers could override it (or both). At the moment I am having to change each plugin to not define its loading implementation. From: agri...@chromium.org Date: Fri, 21 Jun 2013 10:22:35 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org For your actual app, you're free to use any JS loader that you'd like. Are there really many existing Cordova plugins that use alternate module package definitions? On Fri, Jun 21, 2013 at 9:39 AM, J Prince princej.w...@hotmail.co.uk wrote: Hi Andrew, My main point was to make the actual plugin javascript definitions more flexible. That way it would support more unusual developer requirements (such as mine). If the plugin definitions did not contain any loader implementation then the same definition can be used different ways by different developers. Currently any existing plugins that I want to use I am making my own copy of and modifying to suit my project. I found this annoying and produced my suggestion based on that experience. I suppose it is as much for developer simplicity as anything else. A format that supported different use cases would be better for me! It would also mean that the cordova team could more easily change the javascript plugin loader in future without breaking existing plugins. I hadn't thought about dynamically loading the native side of plugins. I was just assuming that would always be loaded. From: agri...@chromium.org Date: Fri, 21 Jun 2013 09:12:42 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org Hi Jonathan, First, thanks for a well-written proposal. At least for me, I'm not really sure that there is enough of a problem with the current approach that would justify changing it. That said, business is always an issue, and bumping your thread was the right thing to do :) For Android and iOS, the large majority of plugins require native code in order to be useful, so I don't think that having plugin JS be dynamically seems that useful without being able to dynamically load the native parts of it. You said that you're serving your app via HTTP. I think your best bet would be to concat all of your plugin JS together would be by far your biggest performance boost rather than try to selectively load them. Until very recently, Cordova's module system didn't involve a loader at all, and required that all modules be defined ahead of time. Now, we actually do load plugin .js files during start-up, but still not on-demand. So, in my mind we really have two things: 1. A registry 2. A boot-up process. To be clear - is it that you want to change the registry part, or is it just that you want to have plugin .js loaded on-demand? Are you concerned about the native side of the plugins? One thing I think maybe we should add is the ability to disable the start-up plugin_loader.js logic for when people want to package the .js themselves. On Fri, Jun 21, 2013 at 8:30 AM, J Prince princej.w...@hotmail.co.uk wrote: So it's been about a week now and I haven't really had any feedback on this. https://github.com/jxp/cordova.pluginLoader I'm not sure if this means; a) Everyone is too busy b) Everyone assumed someone else would respond c) No-one is that interested in plugin javascript definitions d) You've had similar discussions before and don't want to start THAT again From: princej.w...@hotmail.co.uk To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader Date: Tue, 18 Jun 2013 16:55:19 +0100 I have (briefly) looked at
RE: Suggestion - pluginLoader
That looks much more like what I need. I think there were two things adding to my confusion; 1. I was not aware plugman could affect the javascript 2. I don't think I've seen any clean plugman plugins in the wild I will look into the plugin spec a bit further and do some testing with it to see what can be done. From: agri...@chromium.org Date: Fri, 21 Jun 2013 11:28:28 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org aha, so previously we didn't help plugins along at all. With plugman-compatible plugins, we do define a way for plugin JS to be loaded: you add a js-module tag to your plugin.xml and then plugman will wrap your file in a cordova.define(). Spec: https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md You can also specify a runs/ tag in js-module which just causes your .js file to be executed after cordova.js is parsed. I think with this, you could layer on another module loading system if you wanted something outside of the cordova.define() system. Does that make sense? On Fri, Jun 21, 2013 at 10:41 AM, J Prince princej.w...@hotmail.co.ukwrote: Perhaps my terminology is wrong but ALL plugins define how they are loaded. Either (old style) window.plugins = ... or (new style) cordova.define(... My fundamental point is they shouldn't. I don't want my plugins loaded in either of these ways. The loading of plugins should be separate to the plugin definition. Hence my suggestion of; cordova.pluginLoader(...) In this pattern pluginLoader could either have multiple different modes or developers could override it (or both). At the moment I am having to change each plugin to not define its loading implementation. From: agri...@chromium.org Date: Fri, 21 Jun 2013 10:22:35 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org For your actual app, you're free to use any JS loader that you'd like. Are there really many existing Cordova plugins that use alternate module package definitions? On Fri, Jun 21, 2013 at 9:39 AM, J Prince princej.w...@hotmail.co.uk wrote: Hi Andrew, My main point was to make the actual plugin javascript definitions more flexible. That way it would support more unusual developer requirements (such as mine). If the plugin definitions did not contain any loader implementation then the same definition can be used different ways by different developers. Currently any existing plugins that I want to use I am making my own copy of and modifying to suit my project. I found this annoying and produced my suggestion based on that experience. I suppose it is as much for developer simplicity as anything else. A format that supported different use cases would be better for me! It would also mean that the cordova team could more easily change the javascript plugin loader in future without breaking existing plugins. I hadn't thought about dynamically loading the native side of plugins. I was just assuming that would always be loaded. From: agri...@chromium.org Date: Fri, 21 Jun 2013 09:12:42 -0400 Subject: Re: Suggestion - pluginLoader To: dev@cordova.apache.org Hi Jonathan, First, thanks for a well-written proposal. At least for me, I'm not really sure that there is enough of a problem with the current approach that would justify changing it. That said, business is always an issue, and bumping your thread was the right thing to do :) For Android and iOS, the large majority of plugins require native code in order to be useful, so I don't think that having plugin JS be dynamically seems that useful without being able to dynamically load the native parts of it. You said that you're serving your app via HTTP. I think your best bet would be to concat all of your plugin JS together would be by far your biggest performance boost rather than try to selectively load them. Until very recently, Cordova's module system didn't involve a loader at all, and required that all modules be defined ahead of time. Now, we actually do load plugin .js files during start-up, but still not on-demand. So, in my mind we really have two things: 1. A registry 2. A boot-up process. To be clear - is it that you want to change the registry part, or is it just that you want to have plugin .js loaded on-demand? Are you concerned about the native side of the plugins? One thing I think maybe we should add is the ability to disable the start-up plugin_loader.js logic for when people want to package the .js themselves. On Fri, Jun 21, 2013 at 8:30 AM, J Prince princej.w...@hotmail.co.uk wrote: So it's been about a week
Re: Cordova Blog
+1 on a blog but I'd like to do something static if possible. (Jekyll, Scotch, Docpad are all nice enough). We used to use Wordpress for http://phonegap.com and it was a complete struggle to keep it up to date and online. The running joke when were dealing w/ this was 'static sites are web scale'. And its true, since moving to Jekyll we've had basically zero downtime. While our current setup is not ideal (svn) it does accommodate anything static. I will talk w/ Yohei about doing a slight refresh to that (if cool w/ everyone here). On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana csantan...@gmail.com wrote: This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com
Re: Cordova Blog
@Brian I'm not married to WordPress was just referring as an example, JekyII will do fine , Can we see if we can host the content on git/github instead of svn?, this way, I think it will be easier to contribute and maintain. --Carlos On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux b...@brian.io wrote: +1 on a blog but I'd like to do something static if possible. (Jekyll, Scotch, Docpad are all nice enough). We used to use Wordpress for http://phonegap.com and it was a complete struggle to keep it up to date and online. The running joke when were dealing w/ this was 'static sites are web scale'. And its true, since moving to Jekyll we've had basically zero downtime. While our current setup is not ideal (svn) it does accommodate anything static. I will talk w/ Yohei about doing a slight refresh to that (if cool w/ everyone here). On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana csantan...@gmail.com wrote: This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: Cordova Blog
We could mirror but stuff that lives on apache.org is svn deployed and I'm almost completely certain that infra would not be into changing that. On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana csantan...@gmail.com wrote: @Brian I'm not married to WordPress was just referring as an example, JekyII will do fine , Can we see if we can host the content on git/github instead of svn?, this way, I think it will be easier to contribute and maintain. --Carlos On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux b...@brian.io wrote: +1 on a blog but I'd like to do something static if possible. (Jekyll, Scotch, Docpad are all nice enough). We used to use Wordpress for http://phonegap.com and it was a complete struggle to keep it up to date and online. The running joke when were dealing w/ this was 'static sites are web scale'. And its true, since moving to Jekyll we've had basically zero downtime. While our current setup is not ideal (svn) it does accommodate anything static. I will talk w/ Yohei about doing a slight refresh to that (if cool w/ everyone here). On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana csantan...@gmail.com wrote: This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: Cordova Blog
... the github method would of course, apply to all the repos, they can have their own Github project pages if they want. And since they are git repos -- cherry-picking/merging of blog posts I suppose (which can be automated) On Fri, Jun 21, 2013 at 9:52 AM, Shazron shaz...@gmail.com wrote: +1 on Jekyll and Github. All we need is to request a cordova-blog repo on git-wip-us, and then the Github mirror does all the work (I think) :) https://help.github.com/articles/user-organization-and-project-pages So if the repo is cordova-blog, the url would then be http://cordova.github.io/cordova-blog On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana csantan...@gmail.comwrote: @Brian I'm not married to WordPress was just referring as an example, JekyII will do fine , Can we see if we can host the content on git/github instead of svn?, this way, I think it will be easier to contribute and maintain. --Carlos On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux b...@brian.io wrote: +1 on a blog but I'd like to do something static if possible. (Jekyll, Scotch, Docpad are all nice enough). We used to use Wordpress for http://phonegap.com and it was a complete struggle to keep it up to date and online. The running joke when were dealing w/ this was 'static sites are web scale'. And its true, since moving to Jekyll we've had basically zero downtime. While our current setup is not ideal (svn) it does accommodate anything static. I will talk w/ Yohei about doing a slight refresh to that (if cool w/ everyone here). On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana csantan...@gmail.com wrote: This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: Cordova Blog
Yes mirror to Github, official and live content will be stored on apache servers. +1 on the repo name cordova-blog On Fri, Jun 21, 2013 at 12:52 PM, Shazron shaz...@gmail.com wrote: +1 on Jekyll and Github. All we need is to request a cordova-blog repo on git-wip-us, and then the Github mirror does all the work (I think) :) https://help.github.com/articles/user-organization-and-project-pages So if the repo is cordova-blog, the url would then be http://cordova.github.io/cordova-blog On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana csantan...@gmail.com wrote: @Brian I'm not married to WordPress was just referring as an example, JekyII will do fine , Can we see if we can host the content on git/github instead of svn?, this way, I think it will be easier to contribute and maintain. --Carlos On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux b...@brian.io wrote: +1 on a blog but I'd like to do something static if possible. (Jekyll, Scotch, Docpad are all nice enough). We used to use Wordpress for http://phonegap.com and it was a complete struggle to keep it up to date and online. The running joke when were dealing w/ this was 'static sites are web scale'. And its true, since moving to Jekyll we've had basically zero downtime. While our current setup is not ideal (svn) it does accommodate anything static. I will talk w/ Yohei about doing a slight refresh to that (if cool w/ everyone here). On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana csantan...@gmail.com wrote: This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: PhoneGap Day tickets
NP, Colene (cc'd) can help get any/all committers tickets. (Its ridiculously cheap for any community that isn't yet a committer but pls email me if you need help.) On Thu, Jun 20, 2013 at 6:56 PM, Andrew Grieve agri...@chromium.org wrote: Do I (or other committers thinking of attending) need to buy a ticket?
Re: Cordova Blog
OR we could use Github pages for the Cordova org and just host on a subdomain: http://blog.cordova.io ??? Seems like the least friction. On Fri, Jun 21, 2013 at 9:56 AM, Carlos Santana csantan...@gmail.com wrote: Yes mirror to Github, official and live content will be stored on apache servers. +1 on the repo name cordova-blog On Fri, Jun 21, 2013 at 12:52 PM, Shazron shaz...@gmail.com wrote: +1 on Jekyll and Github. All we need is to request a cordova-blog repo on git-wip-us, and then the Github mirror does all the work (I think) :) https://help.github.com/articles/user-organization-and-project-pages So if the repo is cordova-blog, the url would then be http://cordova.github.io/cordova-blog On Fri, Jun 21, 2013 at 9:41 AM, Carlos Santana csantan...@gmail.com wrote: @Brian I'm not married to WordPress was just referring as an example, JekyII will do fine , Can we see if we can host the content on git/github instead of svn?, this way, I think it will be easier to contribute and maintain. --Carlos On Fri, Jun 21, 2013 at 12:29 PM, Brian LeRoux b...@brian.io wrote: +1 on a blog but I'd like to do something static if possible. (Jekyll, Scotch, Docpad are all nice enough). We used to use Wordpress for http://phonegap.com and it was a complete struggle to keep it up to date and online. The running joke when were dealing w/ this was 'static sites are web scale'. And its true, since moving to Jekyll we've had basically zero downtime. While our current setup is not ideal (svn) it does accommodate anything static. I will talk w/ Yohei about doing a slight refresh to that (if cool w/ everyone here). On Fri, Jun 21, 2013 at 8:06 AM, Carlos Santana csantan...@gmail.com wrote: This is great idea. I don't mind the same content in both places. (PhoneGap and Cordova) Phonegap is spelled Cordova anyway :-) Some of the blog posts in PhoneGap point to personal blogs. I would thin that the Cordova Blog will do the same have blogs hosted on its site or point to personal blog posts. What about having Pages (i.e. WordPress) on the Cordova Blog in addition of Posts? Ideas for Pages: - Release Notes - Roadmap/Timeline - Videos - Tutorials - List 3rd Party Plugins Here is another one, if Blog (i.e. WordPress) is created why not host the whole site (cordova.io) with WordPress (Posts and Pages) and move away from Ruby for the website :-). If not then you will be maintaining two sites with two different technologies. --Carlos On Thu, Jun 20, 2013 at 10:19 PM, Joe Bowser bows...@gmail.com wrote: Currently, PhoneGap aggregates the blog posts of many committers at phonegap.com/blog. The downside of this is that it's an Adobe blog, and it's not Apache Cordova. Apache Cordova should probably have its own blog, but I see a lot of the same content being in two different places. If someone wants to take this on, that'd be awesome. On Thu, Jun 20, 2013 at 7:12 PM, Andrew Grieve agri...@chromium.org wrote: I brought it up in a separate thread ( http://callback.markmail.org/thread/y44pmva6gfm257sl) but probably deserves its own. I'd like to create a Blog for Cordova and make all Committers able to post to it. We could use it to: - Post release announcements release notes - Draw attention to deprecations and upgrade guides - Deep dive into significant improvements / changes Mainly, I think having a blog for the project will be really help by providing an authoritative source for Cordova blob posts (as opposed to on our personal blogs, which I appreciate, but which I feel are lacking authority). I'm quite inexperienced at blogging, so everyone agrees we should go ahead with this, it'd be good if someone more blog-savvy would own setting it up. -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: Review Request: Fixing exec bug.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/ --- (Updated June 21, 2013, 5:21 p.m.) Review request for cordova and Andrew Grieve. Description --- Fixing exec bug. This addresses bug CB-3927. https://issues.apache.org/jira/browse/CB-3927 Diffs (updated) - framework/src/org/apache/cordova/api/PluginEntry.java 9b9af6bc303965e7263bca75037256da81868fb2 framework/src/org/apache/cordova/api/PluginManager.java adaec907e216c101cc78ee72ff30ec6b7d875a45 Diff: https://reviews.apache.org/r/12013/diff/ Testing --- Thanks, Jeffrey Willms
Re: Apache VM for Medic's CouchDB
If we can get one setup then yes why not (could be good to have more than one frankly). Pursing the Nodejitsu guys to donate an instance (as they do for npm itself) which has really good uptime... ;) On Thu, Jun 20, 2013 at 8:53 AM, Anis KADRI anis.ka...@gmail.com wrote: Should we use this for our NPM registry as well ? On Thu, Jun 20, 2013 at 2:24 AM, Brian LeRoux b...@brian.io wrote: Right on. Thanks for taking this on Mike. On Wed, Jun 19, 2013 at 7:12 PM, Lorin Beer lorin.beer@gmail.com wrote: that would be fantastic! On Wed, Jun 19, 2013 at 9:59 AM, Filip Maj f...@adobe.com wrote: Would love to see this, thanks for taking the initiative on this Mike! On 6/19/13 7:19 AM, Andrew Grieve agri...@chromium.org wrote: Sounds great! On Wed, Jun 19, 2013 at 9:39 AM, Mike Billau mike.bil...@gmail.com wrote: Hello everyone, I have been working the last week on getting medic up and running here at our office, and so far things are going pretty well. I would like to start contributing our tests back to the community pretty soon. However, I contacted Fil about flowing our test results back to the CI database, and he informed me that unfortunately the EC2 instance has been removed. I would like to propose that we have the Apache folks set us up with a standard Linux VM that we can use to host the CouchDB server to collect test results. Using an Apache VM seems to be more in the Apache spirit as opposed to an EC2 instance. Since it would be more centralized and community owned, it would potentially make it easier for other groups to contribute test results. The VM can also serve as a home for any future dumps or hosted scripts that we need. Any thoughts on this? If there are no problems, then can somebody involved with ASF help me create the relevant INFRA issues? Thanks, Mike Billau
Re: Jake woes
Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
plugman iOS + compiler flags
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml definition. Generally it's been going well, however one
problem I've come across a few times particularly when trying to apply
it to old code or adapting 3rd party code is that the code isn't ARC
compliant. The preference would obviously be to make the code
arc-compliant, but not being a pro in objective c, it's often easier to
just add '-fno-objc-arc' as a compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m compilerFlags=-fno-objc-arc/
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
It makes sense to me although I'd like to hear what other committers think
about this as well.
Related question: are there any other platforms where compiler flags would
be helpful/useful?
On 6/21/13 11:37 AM, aaron barnes aa...@stasis.org wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml definition. Generally it's been going well, however one
problem I've come across a few times particularly when trying to apply
it to old code or adapting 3rd party code is that the code isn't ARC
compliant. The preference would obviously be to make the code
arc-compliant, but not being a pro in objective c, it's often easier to
just add '-fno-objc-arc' as a compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m compilerFlags=-fno-objc-arc/
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
Of course it should be considered. We did discuss this briefly, but I don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
including it in any kind of project setting it would work - without adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are enabling
it in the default template: https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counting-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships with
libTestFlight.a), and for small plugins to convert to use the macro, but I
can see it being a problem if we had to include the Facebook SDK with its
gajillion files that may or may not be ARC (since converting them may be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's plugin.xml
definition. Generally it's been going well, however one problem I've come
across a few times particularly when trying to apply it to old code or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but not being
a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
including it in any kind of project setting it would work - without adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are enabling
it in the default template: https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships
with
libTestFlight.a), and for small plugins to convert to use the macro, but I
can see it being a problem if we had to include the Facebook SDK with its
gajillion files that may or may not be ARC (since converting them may be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml
definition. Generally it's been going well, however one problem I've
come
across a few times particularly when trying to apply it to old code or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but not
being
a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m
compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
Also, Andrew Grieve did propose it here in proposal #2:
http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtxx6f2a+state:results
Awesome, I'll file it
On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote:
Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
including it in any kind of project setting it would work - without adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are enabling
it in the default template: https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships
with
libTestFlight.a), and for small plugins to convert to use the macro, but I
can see it being a problem if we had to include the Facebook SDK with its
gajillion files that may or may not be ARC (since converting them may be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml
definition. Generally it's been going well, however one problem I've
come
across a few times particularly when trying to apply it to old code or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but not
being
a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m
compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
+1 on the be able to inject compiler options per file from xml
On the same area, what about coding a small script/tool to analyze a plugin
folder and generate the plugin.xml section containing the list of files
that need the flag?
--Carlos
On Fri, Jun 21, 2013 at 3:00 PM, Shazron shaz...@gmail.com wrote:
Also, Andrew Grieve did propose it here in proposal #2:
http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtxx6f2a+state:results
Awesome, I'll file it
On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote:
Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
including it in any kind of project setting it would work - without
adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are
enabling
it in the default template:
https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships
with
libTestFlight.a), and for small plugins to convert to use the macro,
but I
can see it being a problem if we had to include the Facebook SDK with
its
gajillion files that may or may not be ARC (since converting them may
be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org
wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml
definition. Generally it's been going well, however one problem I've
come
across a few times particularly when trying to apply it to old code or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but not
being
a pro in objective c, it's often easier to just add '-fno-objc-arc'
as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m
compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
--
Carlos Santana
csantan...@gmail.com
Re: plugman iOS + compiler flags
That would be cool, have at it Carlos :D
On 6/21/13 12:11 PM, Carlos Santana csantan...@gmail.com wrote:
+1 on the be able to inject compiler options per file from xml
On the same area, what about coding a small script/tool to analyze a
plugin
folder and generate the plugin.xml section containing the list of files
that need the flag?
--Carlos
On Fri, Jun 21, 2013 at 3:00 PM, Shazron shaz...@gmail.com wrote:
Also, Andrew Grieve did propose it here in proposal #2:
http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtx
x6f2a+state:results
Awesome, I'll file it
On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote:
Sweet, let's file an issue as a feature request for this and I'll do
my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This
way,
including it in any kind of project setting it would work - without
adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are
enabling
it in the default template:
https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti
n
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK
ships
with
libTestFlight.a), and for small plugins to convert to use the macro,
but I
can see it being a problem if we had to include the Facebook SDK with
its
gajillion files that may or may not be ARC (since converting them may
be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler
flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org
wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml
definition. Generally it's been going well, however one problem
I've
come
across a few times particularly when trying to apply it to old
code or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but
not
being
a pro in objective c, it's often easier to just add '-fno-objc-arc'
as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm
thinking
something like:
source-file src=src/ios/LegacyCode.m
compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m
*/;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it
be
considered?
--aaron
--
Carlos Santana
csantan...@gmail.com
Re: plugman iOS + compiler flags
Filed: https://issues.apache.org/jira/browse/CB-3967
On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote:
Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This way,
including it in any kind of project setting it would work - without adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are enabling
it in the default template: https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships
with
libTestFlight.a), and for small plugins to convert to use the macro, but I
can see it being a problem if we had to include the Facebook SDK with its
gajillion files that may or may not be ARC (since converting them may be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml
definition. Generally it's been going well, however one problem I've
come
across a few times particularly when trying to apply it to old code or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but not
being
a pro in objective c, it's often easier to just add '-fno-objc-arc' as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m
compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
Thanks Shaz!
On 6/21/13 12:20 PM, Shazron shaz...@gmail.com wrote:
Filed: https://issues.apache.org/jira/browse/CB-3967
On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote:
Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't
think we added it as a feature request in time for 3.0.0.
What I did recommend however, is for plugins to use the
__has_feature(objc_arc) macro to support both ARC and non-ARC. This
way,
including it in any kind of project setting it would work - without
adding
this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project
template (for plugin compatibility reasons), but in 3.0.0 we are
enabling
it in the default template:
https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti
n
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships
with
libTestFlight.a), and for small plugins to convert to use the macro,
but I
can see it being a problem if we had to include the Facebook SDK with
its
gajillion files that may or may not be ARC (since converting them may
be a
maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler
flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org
wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml
definition. Generally it's been going well, however one problem I've
come
across a few times particularly when trying to apply it to old code
or
adapting 3rd party code is that the code isn't ARC compliant. The
preference would obviously be to make the code arc-compliant, but not
being
a pro in objective c, it's often easier to just add '-fno-objc-arc'
as a
compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m
compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
Re: plugman iOS + compiler flags
Holy sh*t guys, that's some fast work.
Much obliged,
--aaron
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Filed: https://issues.apache.org/jira/browse/CB-3967
On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj fi...@adobe.com wrote:
Sweet, let's file an issue as a feature request for this and I'll do my
best to get this in time for 3.0.
On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote:
Of course it should be considered. We did discuss this briefly, but I
don't think we added it as a feature request in time for 3.0.0. What I
did recommend however, is for plugins to use the __has_feature(objc_arc)
macro to support both ARC and non-ARC. This way, including it in any
kind of project setting it would work - without adding this flag.
Pre-3.0.0, ARC is _not_ enabled by default in the project template (for
plugin compatibility reasons), but in 3.0.0 we are enabling it in the
default template: https://issues.apache.org/jira/browse/CB-2180
More info here:
http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-countin
g-arc-and-cordova-plugins/
For pre-compiled binaries it's no problem (say the TestFlightSDK ships
with libTestFlight.a), and for small plugins to convert to use the
macro, but I can see it being a problem if we had to include the
Facebook SDK with its gajillion files that may or may not be ARC (since
converting them may be a maintenance nightmare for newer versions).
For that last scenario, I would recommend having that new compiler flags
attribute.
On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aar...@stasis.org wrote:
I've really been enjoying the cordova cli/plugin.xml definition.
I've been porting a bunch of old plugins to work with plugman's
plugin.xml definition. Generally it's been going well, however one
problem I've come across a few times particularly when trying to apply
it to old code or adapting 3rd party code is that the code isn't ARC
compliant. The preference would obviously be to make the code
arc-compliant, but not being a pro in objective c, it's often easier to
just add '-fno-objc-arc' as a compiler flag for the file in xcode.
It would be great to add as an option for iOS builders, I'm thinking
something like:
source-file src=src/ios/LegacyCode.m compilerFlags=-fno-objc-arc/**
in plugin.xml
which would then insert something like :
93803FD21768C79200CB4E50 /* LegacyCode.m in Sources */ = {isa =
PBXBuildFile; fileRef = 93803FCF1768C79200CB4E50 /* LegacyCode.m */;
settings = {COMPILER_FLAGS = -fno-objc-arc; }; }
into the project.pbxproj.
would anybody else find this useful as a feature-request? can it be
considered?
--aaron
© 2007-2011 MarkLogic Corporation. All rights reserved.Home
http://markmail.org/|Browse http://markmail.org/browse|FAQ
http://markmail.org/docs/faq.xqy|Advertising
http://markmail.org/docs/advertising.xqy|Blog
http://markmail.blogspot.com/|Feedback
http://markmail.org/docs/feedback.xqy|MarkMail^(TM) Legalese
http://markmail.org/docs/terms-of-use.xqy|About MarkLogic Server
http://www.marklogic.com/products/mmoverview.html
[Announce] Cordova 2.9.0rc1 released
Just wanted to announce that Cordova 2.9.0rc1 has been released! You can download it on the Cordova website at http://cordova.apache.org/. This is the release candidate for Cordova 2.9.0 which should be released next week. A changelog is included in the download. Have a great weekend! -Steve
Re: [Announce] Cordova 2.9.0rc1 released
Thanks for getting it out Steve! On 6/21/13 1:31 PM, Steven Gill stevengil...@gmail.com wrote: Just wanted to announce that Cordova 2.9.0rc1 has been released! You can download it on the Cordova website at http://cordova.apache.org/. This is the release candidate for Cordova 2.9.0 which should be released next week. A changelog is included in the download. Have a great weekend! -Steve
Re: plugman iOS + compiler flags
I will take look into detecting incompatible ARC files that will potentially give compiler errors. So far what I had found is to look if code is using invalid functions (i.e. retain and release) Taking into consideration that file could be using macro to have dual path based on #if !__has_feature(objc_arc) --Carlos On Friday, June 21, 2013, Filip Maj wrote: That would be cool, have at it Carlos :D On 6/21/13 12:11 PM, Carlos Santana csantan...@gmail.com wrote: +1 on the be able to inject compiler options per file from xml On the same area, what about coding a small script/tool to analyze a plugin folder and generate the plugin.xml section containing the list of files that need the flag? --Carlos On Fri, Jun 21, 2013 at 3:00 PM, Shazron shaz...@gmail.com wrote: Also, Andrew Grieve did propose it here in proposal #2: http://markmail.org/thread/tskkqinboyp5cjdg#query:+page:1+mid:ojea6mtsrtx x6f2a+state:results Awesome, I'll file it On Fri, Jun 21, 2013 at 11:58 AM, Filip Maj f...@adobe.com wrote: Sweet, let's file an issue as a feature request for this and I'll do my best to get this in time for 3.0. On 6/21/13 11:54 AM, Shazron shaz...@gmail.com wrote: Of course it should be considered. We did discuss this briefly, but I don't think we added it as a feature request in time for 3.0.0. What I did recommend however, is for plugins to use the __has_feature(objc_arc) macro to support both ARC and non-ARC. This way, including it in any kind of project setting it would work - without adding this flag. Pre-3.0.0, ARC is _not_ enabled by default in the project template (for plugin compatibility reasons), but in 3.0.0 we are enabling it in the default template: https://issues.apache.org/jira/browse/CB-2180 More info here: http://shazronatadobe.wordpress.com/2012/09/05/automatic-reference-counti n g-arc-and-cordova-plugins/ For pre-compiled binaries it's no problem (say the TestFlightSDK ships with libTestFlight.a), and for small plugins to convert to use the macro, but I can see it being a problem if we had to include the Facebook SDK with its gajillion files that may or may not be ARC (since converting them may be a maintenance nightmare for newer versions). For that last scenario, I would recommend having that new compiler flags attribute. On Fri, Jun 21, 2013 at 11:37 AM, aaron barnes aa...@stasis.org wrote: I've really been enjoying the cordova cli/plugin.xml definition. I've been porting a bunch of old plugins to work with plugman's plugin.xml definition. Generally it's been going well, however one problem I've come across a few times particularly when trying to apply it to old code or adapting 3rd party code is that the code isn't ARC compliant. The preference would obviously be to make the code arc-compliant, but not being a pro in objective c, it's often easier to just add '-fno-objc-arc' as a compiler flag for the file in xcode. It would be great to add as an option for iOS builders, I'm thinking something like: -- Carlos Santana csantan...@gmail.com
Re: Jake woes
It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Jake woes
noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Jake woes
Punishable by death or bunga-bunga, your choice. @purplecabbage risingj.com On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj f...@adobe.com wrote: noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Jake woes
HORRIBLE On Fri, Jun 21, 2013 at 2:43 PM, Jesse purplecabb...@gmail.com wrote: Punishable by death or bunga-bunga, your choice. @purplecabbage risingj.com On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj f...@adobe.com wrote: noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Jake woes
Guys no one can completely defeat the daleks. I'm sure that they will be back. Possibly in rainbow colours. On Jun 21, 2013 6:27 PM, Lorin Beer lorin.beer@gmail.com wrote: HORRIBLE On Fri, Jun 21, 2013 at 2:43 PM, Jesse purplecabb...@gmail.com wrote: Punishable by death or bunga-bunga, your choice. @purplecabbage risingj.com On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj f...@adobe.com wrote: noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Jake woes
Ex-term-in-ate Sent from my iPhone On 2013-06-21, at 6:52 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Guys no one can completely defeat the daleks. I'm sure that they will be back. Possibly in rainbow colours. On Jun 21, 2013 6:27 PM, Lorin Beer lorin.beer@gmail.com wrote: HORRIBLE On Fri, Jun 21, 2013 at 2:43 PM, Jesse purplecabb...@gmail.com wrote: Punishable by death or bunga-bunga, your choice. @purplecabbage risingj.com On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj f...@adobe.com wrote: noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Review Request: Fixing exec bug.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/#review22279 --- Ship it! Looks good! Just send me the JS change and I'll commit it. framework/src/org/apache/cordova/api/PluginManager.java https://reviews.apache.org/r/12013/#comment45770 - Andrew Grieve On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/ --- (Updated June 21, 2013, 5:21 p.m.) Review request for cordova and Andrew Grieve. Description --- Fixing exec bug. This addresses bug CB-3927. https://issues.apache.org/jira/browse/CB-3927 Diffs - framework/src/org/apache/cordova/api/PluginEntry.java 9b9af6bc303965e7263bca75037256da81868fb2 framework/src/org/apache/cordova/api/PluginManager.java adaec907e216c101cc78ee72ff30ec6b7d875a45 Diff: https://reviews.apache.org/r/12013/diff/ Testing --- Thanks, Jeffrey Willms
Re: Jake woes
:) who needs the dalek. On Fri, Jun 21, 2013 at 7:17 PM, Gord Tanner gtan...@gmail.com wrote: Ex-term-in-ate Sent from my iPhone On 2013-06-21, at 6:52 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Guys no one can completely defeat the daleks. I'm sure that they will be back. Possibly in rainbow colours. On Jun 21, 2013 6:27 PM, Lorin Beer lorin.beer@gmail.com wrote: HORRIBLE On Fri, Jun 21, 2013 at 2:43 PM, Jesse purplecabb...@gmail.com wrote: Punishable by death or bunga-bunga, your choice. @purplecabbage risingj.com On Fri, Jun 21, 2013 at 2:09 PM, Filip Maj f...@adobe.com wrote: noo On 6/21/13 2:01 PM, Patrick Mueller pmue...@gmail.com wrote: It appears you've made a horrible, HORRIBLE mistake with your patch [1], and deleted the dalek. HORRIBLE. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=273e0a 3a ps: I too once tried to delete the dalek, and look what happened to me. and the dalek :-( On Fri, Jun 21, 2013 at 2:17 PM, Benn Mapes benn.ma...@gmail.com wrote: Could you also update the README? https://issues.apache.org/jira/browse/CB-3966 Thanks! On Fri, Jun 21, 2013 at 7:23 AM, Andrew Grieve agri...@chromium.org wrote: Okay, CB-3960 is the tracker. On Fri, Jun 21, 2013 at 9:57 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone on the Rogers network. From: Bryan Higgins Sent: Friday, June 21, 2013 9:39 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Jake woes +1 On Fri, Jun 21, 2013 at 7:11 AM, Lucas Holmquist lholm...@redhat.com wrote: +1 On Jun 20, 2013, at 11:20 PM, Steven Gill stevengil...@gmail.com wrote: +1 Grunt On Thu, Jun 20, 2013 at 7:15 PM, Andrew Grieve agri...@chromium.org wrote: I've burned quite a bit of time trying to get it to work, and I'm a bit realizing that it's probably not worth continuing. By fiddling with dependencies I can get it to run, but tasks are being run multiple times when they shouldn't be, and there's no reason I should need to fiddle the deps to get it to run. So... any objections if I delete Jakefile and replace it with a Gruntfile.js? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. -- Patrick Mueller http://muellerware.org
Re: Review Request: Fixing exec bug.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/#review22286 --- Ship it! Ship It! - Joe Bowser On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/ --- (Updated June 21, 2013, 5:21 p.m.) Review request for cordova and Andrew Grieve. Description --- Fixing exec bug. This addresses bug CB-3927. https://issues.apache.org/jira/browse/CB-3927 Diffs - framework/src/org/apache/cordova/api/PluginEntry.java 9b9af6bc303965e7263bca75037256da81868fb2 framework/src/org/apache/cordova/api/PluginManager.java adaec907e216c101cc78ee72ff30ec6b7d875a45 Diff: https://reviews.apache.org/r/12013/diff/ Testing --- Thanks, Jeffrey Willms
Re: Review Request: Fixing exec bug.
On June 21, 2013, 11:47 p.m., Joe Bowser wrote: Ship It! I really just wanted to push the Ship it! button, but yeah, this looks good. - Joe --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/#review22286 --- On June 21, 2013, 5:21 p.m., Jeffrey Willms wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12013/ --- (Updated June 21, 2013, 5:21 p.m.) Review request for cordova and Andrew Grieve. Description --- Fixing exec bug. This addresses bug CB-3927. https://issues.apache.org/jira/browse/CB-3927 Diffs - framework/src/org/apache/cordova/api/PluginEntry.java 9b9af6bc303965e7263bca75037256da81868fb2 framework/src/org/apache/cordova/api/PluginManager.java adaec907e216c101cc78ee72ff30ec6b7d875a45 Diff: https://reviews.apache.org/r/12013/diff/ Testing --- Thanks, Jeffrey Willms
