Re: new meta data for plugin.xml
Perhaps this has been brought up before, but why are we using an xml file? why not make it a json file. Plugman is written in node( js ) so why not have the plugin config file in it's native format. This will probably save a bit of code since the xml is converted to an object to manipulate anyway. i know this is a little off topic. thoughts? On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com wrote: I added some validation for plugin names (to follow reverse-domain-name convention) a couple of weeks ago but there needs to be more of it for sure. On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to track the meta tag addition. https://issues.apache.org/jira/browse/CB-5128 I agree with doing validation with plugman during publish time. We should decide soon which ones are going to be mandatory and which ones will be optional. Probably update the plugin spec + our docs around creating plugins as well. On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com wrote: Perhaps either plugman or the registry should do some validation, and have some required fields? I know that PhoneGap Build when you try to submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: +1 for adding metadata but should more of the metadata be compulsory? JBoss tools plugin discovery uses the cordova.io registry and some of the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on whether to use a plugin or not. Although information such as keywords does not seem like important it becomes quite useful when you are trying to find a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny mmo...@chromium.org wrote: +1 to repo / issue / website / docs etc metadata -1 *for now* to dependencies at specific versions, and testing related changes like mode, just because its not clear what the right solution to these problems is. We do need to address it, but those topics will likely move to separate discussions. On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist lholm...@redhat.com wrote: i was just thinking the same thing :) On Oct 18, 2013, at 12:06 PM, Carlos Santana csantan...@gmail.com wrote: plugin.xml metadata is looking more and more like a package.json (i.e. npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill stevengil...@gmail.com wrote: Yes I meant plugins.xml On Oct 18, 2013, at 5:43 AM, Lucas Holmquist lholm...@redhat.com wrote: On Oct 17, 2013, at 7:54 PM, Steven Gill stevengil...@gmail.com wrote: So looks like want to to start including more data on http://plugins.cordova.io. Repo tag - points to repo where plugin lives Issue tag - points to issue tracker (with component for jira) Testing related (can get discussed more in testing thread Mode tag - to differentiate between testing mode and normal mode JS module tag for test module Dependency related adding version number to dependency tags so they don't just grab latest always. Multiple approaches were discussed and this discussion should probably happen in a new thread. Thoughts on above? Suggestions for other meta data we should look into adding to config.xml? did you mean plugin.xml? -- Carlos Santana csantan...@gmail.com
Re: new meta data for plugin.xml
I believe the consensus at the time was to use XML since it is the format used in other cordova config files, making it easier for plugin developers to upgrade. Changing to json now would not be possible without breaking existing plugins or supporting both formats for a while. Not worth the effort in my opinion for a small improvement to maintainability.
Re: config.xml discussion, we need to talk
Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.comwrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org wrote: I use the IDE with the CLI and hope to make it better. In my mind, the old way is for making platform modifications, and the new way threads platforms/ as a build artifact. If you must control the platform code, you sacrifice easy upgrades and ease of multi-platform development, but gain control. If you want to use the CLI, you lose the ability to make modifications to directly platform code without worrying about the implications. -Michal On Fri, Oct 18, 2013 at 3:18 PM, Steven Gill stevengil...@gmail.com wrote: I like that better. I know that both methods use the command line, but the cordova-cli has cli in its name! We call the tool the cordova-cli so it might be more confusing going away from that and calling it anything else. Not saying we shouldn't be open to a name change though just because we called it X since its inception (or am I saying that? :P). When we write the docs about the other workflow (bin/create, plugman), maybe making the IDE an integral part of it would make it make more sense calling that workflow IDE. Just a thought. On Fri, Oct 18, 2013 at 12:09 PM, Jesse purplecabb...@gmail.com wrote: IDE or cordova-cli ?? @purplecabbage risingj.com On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill stevengil...@gmail.com wrote: I think SinplePlatform vs MultiPlatform is misleading because you can use the CLI to do single platform development. On Fri, Oct 18, 2013 at 11:51 AM, Jesse purplecabb...@gmail.com wrote: SinglePlatform vs MultiPlatform makes the most sense to me. SinglePlatform = Focus on a single platform, and use plugman and the platform scripts directly. Useful when you only have that particular device to test on, or only have access to that device's marketplace. Also useful for platform developers who are focused primarily on the native code. ( aka DivideAndConquer ) -- Carlos Santana csantan...@gmail.com
Re: new meta data for plugin.xml
I suspect that it is because plugin.xml was derived (intellectually, if not literally) from config.xml, which was an XML file because of the W3C Widgets spec, which we tried to adhere to. Whether that spec is still relevant (there doesn't seem to be a lot of vendor interest in it (speaking as an Apache member, *not* as a vendor representative)) is definitely up for debate. There probably are some gains to be made in switching to a JSON config format, given how much of the project is JavaScript these days, but it might not be worth all of the work it would take to do it. Ian On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist lholm...@redhat.comwrote: Perhaps this has been brought up before, but why are we using an xml file? why not make it a json file. Plugman is written in node( js ) so why not have the plugin config file in it's native format. This will probably save a bit of code since the xml is converted to an object to manipulate anyway. i know this is a little off topic. thoughts? On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com wrote: I added some validation for plugin names (to follow reverse-domain-name convention) a couple of weeks ago but there needs to be more of it for sure. On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to track the meta tag addition. https://issues.apache.org/jira/browse/CB-5128 I agree with doing validation with plugman during publish time. We should decide soon which ones are going to be mandatory and which ones will be optional. Probably update the plugin spec + our docs around creating plugins as well. On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com wrote: Perhaps either plugman or the registry should do some validation, and have some required fields? I know that PhoneGap Build when you try to submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: +1 for adding metadata but should more of the metadata be compulsory? JBoss tools plugin discovery uses the cordova.io registry and some of the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on whether to use a plugin or not. Although information such as keywords does not seem like important it becomes quite useful when you are trying to find a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny mmo...@chromium.org wrote: +1 to repo / issue / website / docs etc metadata -1 *for now* to dependencies at specific versions, and testing related changes like mode, just because its not clear what the right solution to these problems is. We do need to address it, but those topics will likely move to separate discussions. On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist lholm...@redhat.com wrote: i was just thinking the same thing :) On Oct 18, 2013, at 12:06 PM, Carlos Santana csantan...@gmail.com wrote: plugin.xml metadata is looking more and more like a package.json (i.e. npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill stevengil...@gmail.com wrote: Yes I meant plugins.xml On Oct 18, 2013, at 5:43 AM, Lucas Holmquist lholm...@redhat.com wrote: On Oct 17, 2013, at 7:54 PM, Steven Gill stevengil...@gmail.com wrote: So looks like want to to start including more data on http://plugins.cordova.io. Repo tag - points to repo where plugin lives Issue tag - points to issue tracker (with component for jira) Testing related (can get discussed more in testing thread Mode tag - to differentiate between testing mode and normal mode JS module tag for test module Dependency related adding version number to dependency tags so they don't just grab latest always. Multiple approaches were discussed and this discussion should probably happen in a new thread. Thoughts on above? Suggestions for other meta data we should look into adding to config.xml? did you mean plugin.xml? -- Carlos Santana csantan...@gmail.com
Re: config.xml discussion, we need to talk
(Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org wrote: I use the IDE with the CLI and hope to make it better. In my mind, the old way is for making platform modifications, and the new way threads platforms/ as a build artifact. If you must control the platform code, you sacrifice easy upgrades and ease of multi-platform development, but gain control. If you want to use the CLI, you lose the ability to make modifications to directly platform code without worrying about the implications. -Michal On Fri, Oct 18, 2013 at 3:18 PM, Steven Gill stevengil...@gmail.com wrote: I like that better. I know that both methods use the command line, but the cordova-cli has cli in its name! We call the tool the cordova-cli so it might be more confusing going away from that and calling it anything else. Not saying we shouldn't be open to a name change though just because we called it X since its inception (or am I saying that? :P). When we write the docs about the other workflow (bin/create, plugman), maybe making the IDE an integral part of it would make it make more sense calling that workflow IDE. Just a thought. On Fri, Oct 18, 2013 at 12:09 PM, Jesse purplecabb...@gmail.com wrote: IDE or cordova-cli ?? @purplecabbage risingj.com On Fri, Oct 18, 2013 at 12:02 PM, Steven Gill stevengil...@gmail.com wrote: I think SinplePlatform vs MultiPlatform is misleading because you can use the CLI to do single platform development. On Fri, Oct 18, 2013 at 11:51 AM, Jesse purplecabb...@gmail.com wrote: SinglePlatform vs MultiPlatform makes the most sense to me. SinglePlatform = Focus on a single platform, and use plugman
Re: Windows 8.1 and other platform addition
On Fri, Oct 18, 2013 at 12:54 PM, Maxime LUCE max...@somatic.fr wrote: Hi everyone, As I said before, I'm working on the Windows 8.1 port of Cordova base on the Windows 8 one. I sent an email with my first thoughts about the improvements we have to do and there are few. In order to make platform addition easier in future, I created and resolved an issue on JIRA CB-5111 where I improve action-stack module in CLI to remove static platform check which makes cordova-cli more robust and more dynamic. https://issues.apache.org/jira/browse/CB-5111 In order to develop on CLI and plugman I have to : * npm link both * use a custom registry to have all plugin up to date with the windows81 platform configuration I think https://issues.apache.org/jira/browse/CB-5006 would address your use-case. Hopefully someone can get to it soon... I found some problems in the platform addition workflow : * There is no doc to tell us how to develop on cordova-cli and plugman (on plugman repo, there is a paragraph about this, but I think we must provide one on cordova wiki or cordova-docs) * There is no doc about how to create a custom registry (we have to find in cordova-registry repo how it work and this a big waste of time) * Allow multiple registry in plugman would be a great improvement to help community plugins integration in plugman * Mobile-spec tests are only working for unix based OS, so it can work only for platforms we can develop on unix. (what about Windows Phone and Windows 8 ?) What about it doesn't work on windows? Definitely bug-worthy if it's not working. I'm doing a lot of hacks to test my new platform on my computer which make me lose my time. Someone has ideas ? Cordialement. Maxime LUCE max...@touchit.fr 06 28 60 72 34 http://touchit.fr
Re: new meta data for plugin.xml
XML is also buying us a couple of small but nice features, such as optionally wrapping tags with a platform tag or (potentially) a mode tag, etc. That functionality would not be expressed as cleanly with JSON, so its not a pure win to move away from XML. Add to that the fact that we are already perceived to change stuff way too often for no due cause, I just really don't see the value. On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland iclell...@google.com wrote: I suspect that it is because plugin.xml was derived (intellectually, if not literally) from config.xml, which was an XML file because of the W3C Widgets spec, which we tried to adhere to. Whether that spec is still relevant (there doesn't seem to be a lot of vendor interest in it (speaking as an Apache member, *not* as a vendor representative)) is definitely up for debate. There probably are some gains to be made in switching to a JSON config format, given how much of the project is JavaScript these days, but it might not be worth all of the work it would take to do it. Ian On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist lholm...@redhat.com wrote: Perhaps this has been brought up before, but why are we using an xml file? why not make it a json file. Plugman is written in node( js ) so why not have the plugin config file in it's native format. This will probably save a bit of code since the xml is converted to an object to manipulate anyway. i know this is a little off topic. thoughts? On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com wrote: I added some validation for plugin names (to follow reverse-domain-name convention) a couple of weeks ago but there needs to be more of it for sure. On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to track the meta tag addition. https://issues.apache.org/jira/browse/CB-5128 I agree with doing validation with plugman during publish time. We should decide soon which ones are going to be mandatory and which ones will be optional. Probably update the plugin spec + our docs around creating plugins as well. On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com wrote: Perhaps either plugman or the registry should do some validation, and have some required fields? I know that PhoneGap Build when you try to submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: +1 for adding metadata but should more of the metadata be compulsory? JBoss tools plugin discovery uses the cordova.io registry and some of the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on whether to use a plugin or not. Although information such as keywords does not seem like important it becomes quite useful when you are trying to find a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny mmo...@chromium.org wrote: +1 to repo / issue / website / docs etc metadata -1 *for now* to dependencies at specific versions, and testing related changes like mode, just because its not clear what the right solution to these problems is. We do need to address it, but those topics will likely move to separate discussions. On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist lholm...@redhat.com wrote: i was just thinking the same thing :) On Oct 18, 2013, at 12:06 PM, Carlos Santana csantan...@gmail.com wrote: plugin.xml metadata is looking more and more like a package.json (i.e. npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill stevengil...@gmail.com wrote: Yes I meant plugins.xml On Oct 18, 2013, at 5:43 AM, Lucas Holmquist lholm...@redhat.com wrote: On Oct 17, 2013, at 7:54 PM, Steven Gill stevengil...@gmail.com wrote: So looks like want to to start including more data on http://plugins.cordova.io. Repo tag - points to repo where plugin lives Issue tag - points to issue tracker (with component for jira) Testing related (can get discussed more in testing thread Mode tag - to differentiate between testing mode and normal mode JS module tag for test module Dependency related adding version number to dependency tags so they don't just grab
Re: new meta data for plugin.xml
yea, this is understandable. wasn't really sure the reasoning, but it looks like diminishing returns here On Oct 21, 2013, at 10:06 AM, Michal Mocny mmo...@chromium.org wrote: XML is also buying us a couple of small but nice features, such as optionally wrapping tags with a platform tag or (potentially) a mode tag, etc. That functionality would not be expressed as cleanly with JSON, so its not a pure win to move away from XML. Add to that the fact that we are already perceived to change stuff way too often for no due cause, I just really don't see the value. On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland iclell...@google.com wrote: I suspect that it is because plugin.xml was derived (intellectually, if not literally) from config.xml, which was an XML file because of the W3C Widgets spec, which we tried to adhere to. Whether that spec is still relevant (there doesn't seem to be a lot of vendor interest in it (speaking as an Apache member, *not* as a vendor representative)) is definitely up for debate. There probably are some gains to be made in switching to a JSON config format, given how much of the project is JavaScript these days, but it might not be worth all of the work it would take to do it. Ian On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist lholm...@redhat.com wrote: Perhaps this has been brought up before, but why are we using an xml file? why not make it a json file. Plugman is written in node( js ) so why not have the plugin config file in it's native format. This will probably save a bit of code since the xml is converted to an object to manipulate anyway. i know this is a little off topic. thoughts? On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com wrote: I added some validation for plugin names (to follow reverse-domain-name convention) a couple of weeks ago but there needs to be more of it for sure. On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to track the meta tag addition. https://issues.apache.org/jira/browse/CB-5128 I agree with doing validation with plugman during publish time. We should decide soon which ones are going to be mandatory and which ones will be optional. Probably update the plugin spec + our docs around creating plugins as well. On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com wrote: Perhaps either plugman or the registry should do some validation, and have some required fields? I know that PhoneGap Build when you try to submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: +1 for adding metadata but should more of the metadata be compulsory? JBoss tools plugin discovery uses the cordova.io registry and some of the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on whether to use a plugin or not. Although information such as keywords does not seem like important it becomes quite useful when you are trying to find a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny mmo...@chromium.org wrote: +1 to repo / issue / website / docs etc metadata -1 *for now* to dependencies at specific versions, and testing related changes like mode, just because its not clear what the right solution to these problems is. We do need to address it, but those topics will likely move to separate discussions. On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist lholm...@redhat.com wrote: i was just thinking the same thing :) On Oct 18, 2013, at 12:06 PM, Carlos Santana csantan...@gmail.com wrote: plugin.xml metadata is looking more and more like a package.json (i.e. npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill stevengil...@gmail.com wrote: Yes I meant plugins.xml On Oct 18, 2013, at 5:43 AM, Lucas Holmquist lholm...@redhat.com wrote: On Oct 17, 2013, at 7:54 PM, Steven Gill stevengil...@gmail.com wrote: So looks like want to to start including more data on http://plugins.cordova.io. Repo tag - points to repo where plugin lives Issue tag - points to issue tracker (with component for jira) Testing related (can get discussed more in testing thread Mode tag - to differentiate between testing mode and normal mode JS module tag for test module Dependency related adding version number to dependency tags so they don't just grab latest always.
Re: Default template - size
I thought it used to be in the README.md (or somewhere else?), but I don't think the res/ directory is meant to be included at all. When updating the template, you're supposed to take the platform-specific things out of there and put them in the right spot (splash screen and icon). They aren't needed at all by the actually run-time. On Fri, Oct 18, 2013 at 7:05 PM, Brian LeRoux b...@brian.io wrote: ya merges also think we should redo that app to something more sane and tiny On Fri, Oct 18, 2013 at 12:53 PM, Shazron shaz...@gmail.com wrote: Didn't think about merges -- +1 merges for moi On Fri, Oct 18, 2013 at 12:41 PM, Jesse purplecabb...@gmail.com wrote: Also, the images we use are ridiculous large considering we want people to replace them. @purplecabbage risingj.com On Fri, Oct 18, 2013 at 12:38 PM, Michal Mocny mmo...@chromium.org wrote: +1 to merges/ I don't mind the 8megs shipped with the default helloworld, but it should not be copied into platform's www for sure. -Michal On Fri, Oct 18, 2013 at 3:01 PM, Ian Clelland iclell...@chromium.org wrote: I'd love to have this fixed as part of CB-2606; There's a lot we could do to make icons and splashscreens better. On Fri, Oct 18, 2013 at 2:52 PM, Shazron shaz...@gmail.com wrote: When someone creates a vanilla iOS project from the CLI, the default app is 8 MB. It's obvious why this is so, the www/res folder includes all the icons for all the platforms and is 8 MB. Can we change this (why include all icons -- the www should be agnostic), or is this a documentation problem.
Re: a new client for download stats
There's no restriction, we just wanted to know what tools people were using. That means we definitely want JBoss Tools to call home and identify itself! We want to know what fraction of the downloads are coming from JBoss, and to have those downloads count towards the overall plugin download counts. Braden On Sun, Oct 20, 2013 at 9:45 PM, Gorkem Ercan gorkem.er...@gmail.comwrote: Hi, As you may know JBoss Tools is introducing support for Cordova Plugins including the registry based installation (final release is due mid Dec). I plan the tool to be a good citizen and call home after every successful plugin fetch similar to what plugman does. I can more or less figure out the parameters that needs to be sent but there is a client field that identifies the client that has initiated the plugin download. Is there restriction on the client field? Can I just send something like jbosstools and everyone would be fine with it? Alternately, but not preferred, JBT can stay as a ghost downloader and do not ping after a successful download. -- Gorkem
Re: new meta data for plugin.xml
I'd be happier if it were JSON, but it's not, and the XML doesn't cause enough pain to be worth making the switch. Ian explained it accurately; it's mostly a historical accident that we're using XML. Braden On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist lholm...@redhat.comwrote: yea, this is understandable. wasn't really sure the reasoning, but it looks like diminishing returns here On Oct 21, 2013, at 10:06 AM, Michal Mocny mmo...@chromium.org wrote: XML is also buying us a couple of small but nice features, such as optionally wrapping tags with a platform tag or (potentially) a mode tag, etc. That functionality would not be expressed as cleanly with JSON, so its not a pure win to move away from XML. Add to that the fact that we are already perceived to change stuff way too often for no due cause, I just really don't see the value. On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland iclell...@google.com wrote: I suspect that it is because plugin.xml was derived (intellectually, if not literally) from config.xml, which was an XML file because of the W3C Widgets spec, which we tried to adhere to. Whether that spec is still relevant (there doesn't seem to be a lot of vendor interest in it (speaking as an Apache member, *not* as a vendor representative)) is definitely up for debate. There probably are some gains to be made in switching to a JSON config format, given how much of the project is JavaScript these days, but it might not be worth all of the work it would take to do it. Ian On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist lholm...@redhat.com wrote: Perhaps this has been brought up before, but why are we using an xml file? why not make it a json file. Plugman is written in node( js ) so why not have the plugin config file in it's native format. This will probably save a bit of code since the xml is converted to an object to manipulate anyway. i know this is a little off topic. thoughts? On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com wrote: I added some validation for plugin names (to follow reverse-domain-name convention) a couple of weeks ago but there needs to be more of it for sure. On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill stevengil...@gmail.com wrote: I have created an issue to track the meta tag addition. https://issues.apache.org/jira/browse/CB-5128 I agree with doing validation with plugman during publish time. We should decide soon which ones are going to be mandatory and which ones will be optional. Probably update the plugin spec + our docs around creating plugins as well. On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com wrote: Perhaps either plugman or the registry should do some validation, and have some required fields? I know that PhoneGap Build when you try to submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: +1 for adding metadata but should more of the metadata be compulsory? JBoss tools plugin discovery uses the cordova.io registry and some of the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on whether to use a plugin or not. Although information such as keywords does not seem like important it becomes quite useful when you are trying to find a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny mmo...@chromium.org wrote: +1 to repo / issue / website / docs etc metadata -1 *for now* to dependencies at specific versions, and testing related changes like mode, just because its not clear what the right solution to these problems is. We do need to address it, but those topics will likely move to separate discussions. On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist lholm...@redhat.com wrote: i was just thinking the same thing :) On Oct 18, 2013, at 12:06 PM, Carlos Santana csantan...@gmail.com wrote: plugin.xml metadata is looking more and more like a package.json (i.e. npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill stevengil...@gmail.com wrote: Yes I meant plugins.xml On Oct 18, 2013, at 5:43 AM, Lucas Holmquist lholm...@redhat.com wrote: On Oct 17, 2013, at 7:54 PM, Steven Gill stevengil...@gmail.com wrote: So looks like want to to start including more
www/config.xml plugin dependencies
Hi, the docs in https://cordova.apache.org/docs/en/3.1.0/config_ref_index.md.html#The%20config.xml%20File say that the feature element is only for the platform specific config.xml s, right? Is there a way to specify that my phonegap app needs a plugin on all platforms e.g. Globalization? Making up this example: https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html gap:dependency id=com.plugin.id url=https://github.com/myuser/someplugin; commit=428931ada3891801 subdir=some/path/here / We are building an app that uses Globalization in javascript; so there is no platform dependency How do I specifiy in www/config.xml that Globalization is needed as a plugin? Cheers Axel
Re: Review Request 14757: Cordova Plugin Registry Blog Post
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/#review27246 --- /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53061 s/what plugins/which plugins/ /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53062 Consider merging these two lines, and imho consider the reader an app developer instead of being abstract. Using the Cordova CLI, you can add plugins to your workspace with a single easy command: I wouldn't mention messy details (it badmouths the plugman flow, and sets up for a reply to say hey I did blah with CLI and now I have messy details, you liar) /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53063 if you dont already have one is implied. /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53064 Not sure we need to call out unpublish, but search command is interesting. Is it prefered to use plugman to search, or to visit plugins.cordova.io? Is the list the same? Maybe expand on that. /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53065 app developers - you, their - your, imho access - use - Michal Mocny On Oct. 18, 2013, 7:59 p.m., Max Woghiren wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/ --- (Updated Oct. 18, 2013, 7:59 p.m.) Review request for cordova. Repository: cordova-site Description --- A blog post outlining the basics of the Cordova plugin registry. Diffs - /README.md 1533594 /www/_posts/2013-10-21-cordova-registry.md PRE-CREATION Diff: https://reviews.apache.org/r/14757/diff/ Testing --- Thanks, Max Woghiren
Re: Requisite Introduction
Cool. One thing I would look at is whether Angular is using history.pushState / replaceState. They have been known to be buggy on Android. On Sun, Oct 20, 2013 at 3:22 AM, Dick Van den Brink d_vandenbr...@outlook.com wrote: Welcome! Seems like a nice bug to start with! ;) Sent from my Windows Phone From: Rich Trottmailto:rtr...@gmail.com Sent: 10/20/2013 13:03 To: dev@cordova.apache.orgmailto:dev@cordova.apache.org Subject: Requisite Introduction The Cordova contributor workflow wiki page says I should give a brief introductory mail to the list. I do what I'm told. My hopes are to: 1) Work with someone more knowledgable than I am to fix this bug (or be able to say conclusively that it's actually a bug in Android or Samsung): http://stackoverflow.com/questions/19459111/angularjs-phonegap-android-galaxy-s4-unexpected-exit (JIRA ticket coming momentarily.) 2) Once that's out of the way, maybe get serious about https://github.com/Trott/cordova-linter and perhaps get some feedback and assistance from people who know a lot more about Cordova etc. than I do. --Rich
Re: www/config.xml plugin dependencies
I don't think that we have app dependencies in Cordova (yet). If your app depends on a plugin, then you should install that plugin. Either cordova plugin add org.apache.cordova.globalization or plugman install org.apache.cordova.globalization (not sure about the command line params there) should add the plugin and modify your config.xml file appropriately. If you're concerned about automation / distribution, and want a simple way to declare all of your app's dependent plugins, rather than just documenting them, then you can use the technique that mobile-spec uses[1]: Create a dependency-only plugin which just lists all of the plugins on which your app depends, and as part of your create step, install that single plugin. Cordova will then recursively install all of the dependencies listed in it. [1] https://github.com/apache/cordova-mobile-spec/tree/master/dependencies-plugin On Mon, Oct 21, 2013 at 10:44 AM, axel.nenn...@telekom.de wrote: Hi, the docs in https://cordova.apache.org/docs/en/3.1.0/config_ref_index.md.html#The%20config.xml%20Filesay that the feature element is only for the platform specific config.xml s, right? Is there a way to specify that my phonegap app needs a plugin on all platforms e.g. Globalization? Making up this example: https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html gap:dependency id=com.plugin.id url= https://github.com/myuser/someplugin; commit=428931ada3891801 subdir=some/path/here / We are building an app that uses Globalization in javascript; so there is no platform dependency How do I specifiy in www/config.xml that Globalization is needed as a plugin? Cheers Axel
Re: config.xml discussion, we need to talk
Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org wrote: I use the IDE with the CLI and hope to make it better. In my mind, the old way is for making platform modifications, and the new way threads platforms/ as a build artifact. If you must control the
Re: config.xml discussion, we need to talk
Whoops, forgot my citation: [1] http://www.catb.org/jargon/html/magic-story.html On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.orgwrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.comwrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org wrote: I use the IDE with the CLI and hope to make it better.
Re: config.xml discussion, we need to talk
Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org wrote: I use the IDE with the CLI and hope to make it better. In my mind, the old way is for making platform modifications, and the new way threads platforms/ as a build artifact. If you must control the platform code, you sacrifice easy upgrades and ease of multi-platform development, but gain control. If you want to use the CLI, you lose the ability to make modifications to directly platform code without worrying about the implications. -Michal On Fri, Oct 18, 2013 at 3:18 PM, Steven Gill stevengil...@gmail.com wrote: I like that better. I know that both methods use the
Re: Requisite Introduction
Yeah. I suspect that there's a WebView problem here that we can't do anything about because Samsung has its own modified version of the WebView. On Oct 21, 2013 8:28 AM, Andrew Grieve agri...@chromium.org wrote: Cool. One thing I would look at is whether Angular is using history.pushState / replaceState. They have been known to be buggy on Android. On Sun, Oct 20, 2013 at 3:22 AM, Dick Van den Brink d_vandenbr...@outlook.com wrote: Welcome! Seems like a nice bug to start with! ;) Sent from my Windows Phone From: Rich Trottmailto:rtr...@gmail.com Sent: 10/20/2013 13:03 To: dev@cordova.apache.orgmailto:dev@cordova.apache.org Subject: Requisite Introduction The Cordova contributor workflow wiki page says I should give a brief introductory mail to the list. I do what I'm told. My hopes are to: 1) Work with someone more knowledgable than I am to fix this bug (or be able to say conclusively that it's actually a bug in Android or Samsung): http://stackoverflow.com/questions/19459111/angularjs-phonegap-android-galaxy-s4-unexpected-exit (JIRA ticket coming momentarily.) 2) Once that's out of the way, maybe get serious about https://github.com/Trott/cordova-linter and perhaps get some feedback and assistance from people who know a lot more about Cordova etc. than I do. --Rich
Re: config.xml discussion, we need to talk
+1 for More Magic/Less Magic On Oct 21, 2013 8:34 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny
RE: config.xml discussion, we need to talk
I've been meaning to catch up with this thread, and haven't had time to do it justice. My high-level takeaway so far is: doc must better clarify relative benefits of CLI vs. platform-level tooling. I've been revamping doc to try to address both workflows, so any lapses on that front are surely mine. There does not yet appear be be a full consensus here, but once there is I'd appreciate if we distill the main points here into an actionable JIRA assign it to me. I believe the Overview page would need more detail with which developers can make crucial decisions up front, but that changes may affect other sections in less obvious ways. --Mike Sierra From: Joe Bowser [bows...@gmail.com] Sent: Monday, October 21, 2013 11:40 AM To: dev Subject: Re: config.xml discussion, we need to talk +1 for More Magic/Less Magic On Oct 21, 2013 8:34 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm
Re: iOS only cordova-labs plugins (keyboard and statusbar, in plugins branch) - move to cordova-ios repo
INFRA request filed: https://issues.apache.org/jira/browse/INFRA-6902 On Sat, Oct 19, 2013 at 3:36 PM, Brian LeRoux b...@brian.io wrote: Discreet repos do have value for discreet issue tracking IMO even when you use Jira. For example, feature branching is easier to reason about. /me shrugs One big repo to rule them all has created more problems than perceived benifits in our past experience so maybe I'm just allergic. On Saturday, October 19, 2013, Michal Mocny wrote: Anis, when we were first ripping out the plugins getting ready for 3.0 we didn't yet have support for plugins in git repo subdirs. I think we had that functionality by 3.0 launch but by then we have created a bunch of repos and momentum followed through. We *could* merge them all into a cordova-plugins repo, but I'm not sure that has value. We *could* graduate plugins out of cordova-plugins into discrete repos, but I'm not sure that has value either. For end users, and for us devs, it really doesn't matter, so we should do whats most comfortable. Brian, at the moment we aren't using github for issue tracking anyway, so discrete issue tracking doesn't need to mean discrete git repo. Likely we do want to create a JIRA component for graduated plugins. The only benefit to moving to discrete repos I can think of is consistency, which may very well have value (esp for tooling support like coho). -Michal On Fri, Oct 18, 2013 at 6:57 PM, Brian LeRoux b...@brian.io wrote: I think having a staging area for plugins is a good idea and leaving cordova-labs as a prototyping area. Ideally we graduate plugins out of cordova-plugins if they get any sort of traction at all and require discreet issue tracking. On Fri, Oct 18, 2013 at 1:31 PM, Anis KADRI anis.ka...@gmail.com wrote: I am just curious. Why do that only for those plugins only and not every other plugins ? I know phonegap/phonegap-plugins was a bad idea but since git 1.7 there is [1]. I've never used it but just figured it might apply to our case. I also think namespacing is a bad idea. [1] http://schacon.github.io/git/git-read-tree.html#_sparse_checkout On Fri, Oct 18, 2013 at 12:57 PM, Shazron shaz...@gmail.com wrote: Great -- i *think* we have consensus, but I will wait until Monday to move forward just in case. Here's my updated proposal on what has been discussed today: 1. Ask INFRA to create a cordova-plugins repo 2. Move (with history) the cordova-labs plugins branch to the repo in (1) 3. Create a CordovaPreferences plugin in (1) with a generic API (and predefined constants) -- iOS to start On Fri, Oct 18, 2013 at 11:46 AM, Michal Mocny mmo...@chromium.org wrote: Sure we can debate the exact interface when it comes to it. Could use predefined constants instead of strings to help with typing/discoverability: navigator.cordovaPreferences.setPreference(win, fail, navigator.cordovaPreferences.PREFERENCE-iOS-GapBetweenPages, 0); On Fri, Oct 18, 2013 at 2:17 PM, Shazron shaz...@gmail.com wrote: Not feeling hot about the namespace thing - as Jesse said it might limit us. Ok - if we do a cordova-plugins repo it won't be hard to move the plugins branch to it with a filter-branch option, preserving history -- great. I think a generic preferences plugin is ok (wouldn't be hard to convert the interface anyway for the existing code I have for iOS) with the usual problems of user education/documentation for upgrades. Putting in the preference name itself might be error prone (who's a great speller here?), but I would amend the pseudo code to actually have a failure/success callback as well for these situations. navigator.cordovaPreferences.setPreference(win, fail, 'iOS-GapBetweenPages,0); navigator.cordovaPreferences.getPreference(win, fail, 'iOS-GapBetweenPages); On Fri, Oct 18, 2013 at 10:59 AM, Jesse purplecabb...@gmail.com wrote: If you namespace it to the platform, and later it makes sense to support it on another device, you will have even more issues. I think the best approach mentioned is the cordova-plugins repo which is like the wild-west that is purplecabbage/phonegap-plugins except it i
Brief Intro
Hello, I was feeling shy and dragging my feet for sending the brief intro to the list, but I wonder if this is truly a requirement for my pull-request to be considered / reviewed. I am based in Bay Area, CA and working on a mobile application targeting iOS and Android. We encountered an issue described in http://issues.apache.org/jira/browse/CB-4995, and patched our local copy in 2.8.15, but would love to have the fix permanently baked into the Cordova package if our fix is acceptable with the community. Going forward, I will surely benefit and learn tons from the community and hopefully be able to contribute back as well. Regards, Hyong
Re: Brief Intro
Thanks for contributing! Fixes like this make Cordova better. I'll have a look at your pull request follow up in your JIRA issue. On Mon, Oct 21, 2013 at 12:47 PM, 김형균 - Hyong Kim hyo...@gmail.com wrote: Hello, I was feeling shy and dragging my feet for sending the brief intro to the list, but I wonder if this is truly a requirement for my pull-request to be considered / reviewed. I am based in Bay Area, CA and working on a mobile application targeting iOS and Android. We encountered an issue described in http://issues.apache.org/jira/browse/CB-4995, and patched our local copy in 2.8.15, but would love to have the fix permanently baked into the Cordova package if our fix is acceptable with the community. Going forward, I will surely benefit and learn tons from the community and hopefully be able to contribute back as well. Regards, Hyong
Re: config.xml discussion, we need to talk
I think we need to be explicit, not talk about legacy or magic. I'd like to propose: Native Platform Dev -- Build Cordova apps on the metal. No helpers for moving across platforms. Web Project Dev -- Build web first projects that (mostly) treats native projects as build artifacts. On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson bra...@chromium.orgwrote: Whoops, forgot my citation: [1] http://www.catb.org/jargon/html/magic-story.html On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project
Re: www/config.xml plugin dependencies
Yes. Currently we are adding plugin be hand. The problem is that we have a distributes developer team. So when the UI developers change something in www to require a plugin and merge that with master; then when the other developers pull master again the plugin is missing and the Application hangs. This has led to some frustration and wasted time. I think it would really help if www - developers could express a dependency on plugins so that the next phonegap local android build updates to the now missing plugins... cheers Axel 2013/10/21 Ian Clelland iclell...@chromium.org I don't think that we have app dependencies in Cordova (yet). If your app depends on a plugin, then you should install that plugin. Either cordova plugin add org.apache.cordova.globalization or plugman install org.apache.cordova.globalization (not sure about the command line params there) should add the plugin and modify your config.xml file appropriately. If you're concerned about automation / distribution, and want a simple way to declare all of your app's dependent plugins, rather than just documenting them, then you can use the technique that mobile-spec uses[1]: Create a dependency-only plugin which just lists all of the plugins on which your app depends, and as part of your create step, install that single plugin. Cordova will then recursively install all of the dependencies listed in it. [1] https://github.com/apache/cordova-mobile-spec/tree/master/dependencies-plugin On Mon, Oct 21, 2013 at 10:44 AM, axel.nenn...@telekom.de wrote: Hi, the docs in https://cordova.apache.org/docs/en/3.1.0/config_ref_index.md.html#The%20config.xml%20Filesaythat the feature element is only for the platform specific config.xml s, right? Is there a way to specify that my phonegap app needs a plugin on all platforms e.g. Globalization? Making up this example: https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html gap:dependency id=com.plugin.id url= https://github.com/myuser/someplugin; commit=428931ada3891801 subdir=some/path/here / We are building an app that uses Globalization in javascript; so there is no platform dependency How do I specifiy in www/config.xml that Globalization is needed as a plugin? Cheers Axel
Re: Review Request 14757: Cordova Plugin Registry Blog Post
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/#review27248 --- /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53068 Merged this line with the previous line. I actually think I want to push back on aiming the post at app developers. If I were to change the audience to app developers, I'd remove the information on publishing plugins, since they don't care about that. A neutral audience makes sense. Reworded the sentence; good point. /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53069 No harm in having it there. It feels wrong to say first, you need to create an account. Most of the time, that's false. :) I changed the wording a bit, though, to make it a little less jarring. /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53071 I've removed the unpublish mention. I don't know that I want to add too many details, but I changed it to such as search for plugins by keyword. There's no preferred method of plugin searching. /www/_posts/2013-10-21-cordova-registry.md https://reviews.apache.org/r/14757/#comment53074 Changed access to use. - Max Woghiren On Oct. 18, 2013, 7:59 p.m., Max Woghiren wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/ --- (Updated Oct. 18, 2013, 7:59 p.m.) Review request for cordova. Repository: cordova-site Description --- A blog post outlining the basics of the Cordova plugin registry. Diffs - /README.md 1533594 /www/_posts/2013-10-21-cordova-registry.md PRE-CREATION Diff: https://reviews.apache.org/r/14757/diff/ Testing --- Thanks, Max Woghiren
Re: Review Request 14757: Cordova Plugin Registry Blog Post
On Oct. 21, 2013, 3:13 p.m., Michal Mocny wrote: /www/_posts/2013-10-21-cordova-registry.md, line 11 https://reviews.apache.org/r/14757/diff/1/?file=366404#file366404line11 s/what plugins/which plugins/ I believe what is correct here. Which is for when you're picking from a set of items; what is used when the options to choose from aren't known. - Max --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/#review27246 --- On Oct. 18, 2013, 7:59 p.m., Max Woghiren wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/ --- (Updated Oct. 18, 2013, 7:59 p.m.) Review request for cordova. Repository: cordova-site Description --- A blog post outlining the basics of the Cordova plugin registry. Diffs - /README.md 1533594 /www/_posts/2013-10-21-cordova-registry.md PRE-CREATION Diff: https://reviews.apache.org/r/14757/diff/ Testing --- Thanks, Max Woghiren
CommitterWorkflow
Hi, I've reviewed http://wiki.apache.org/cordova/CommitterWorkflow and there doesn't seem to be much content on CLI workflow. I'm specifically looking for a process which explains how to start from nothing and download the latest git repos (how does one even figure out which git repos to get) such that one can run all the release tests for a platform in order to send an email saying that the platform+cli is good for release cadence. Thanks - 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 14757: Cordova Plugin Registry Blog Post
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14757/ --- (Updated Oct. 21, 2013, 6:04 p.m.) Review request for cordova. Repository: cordova-site Description --- A blog post outlining the basics of the Cordova plugin registry. Diffs (updated) - /README.md 1533594 /www/_posts/2013-10-21-cordova-registry.md PRE-CREATION Diff: https://reviews.apache.org/r/14757/diff/ Testing --- Thanks, Max Woghiren
Re: config.xml discussion, we need to talk
On Mon, Oct 21, 2013 at 1:35 PM, Brian LeRoux b...@brian.io wrote: I think we need to be explicit, not talk about legacy or magic. I'd like to propose: Native Platform Dev -- Build Cordova apps on the metal. No helpers for moving across platforms. Web Project Dev -- Build web first projects that (mostly) treats native projects as build artifacts. +1 !! Thats perfect. On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson bra...@chromium.org wrote: Whoops, forgot my citation: [1] http://www.catb.org/jargon/html/magic-story.html On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As
Re: www/config.xml plugin dependencies
We've discussed adding dependancy to app's config.xml, but its interesting that you intend to have that work during build/prepare step. Previously I think this was discussed in terms of cordova create only, which wouldn't satisfy your use case. I think your use case is quite valid, but now im concerned about how to support removed dependancy over time, or manually installed plugins that arent in dependancy list... Maybe every plugin installed/removed *must* be reflected in the app's config.xml? -Michal On Mon, Oct 21, 2013 at 1:42 PM, Axel Nennker ignisvul...@gmail.com wrote: Yes. Currently we are adding plugin be hand. The problem is that we have a distributes developer team. So when the UI developers change something in www to require a plugin and merge that with master; then when the other developers pull master again the plugin is missing and the Application hangs. This has led to some frustration and wasted time. I think it would really help if www - developers could express a dependency on plugins so that the next phonegap local android build updates to the now missing plugins... cheers Axel 2013/10/21 Ian Clelland iclell...@chromium.org I don't think that we have app dependencies in Cordova (yet). If your app depends on a plugin, then you should install that plugin. Either cordova plugin add org.apache.cordova.globalization or plugman install org.apache.cordova.globalization (not sure about the command line params there) should add the plugin and modify your config.xml file appropriately. If you're concerned about automation / distribution, and want a simple way to declare all of your app's dependent plugins, rather than just documenting them, then you can use the technique that mobile-spec uses[1]: Create a dependency-only plugin which just lists all of the plugins on which your app depends, and as part of your create step, install that single plugin. Cordova will then recursively install all of the dependencies listed in it. [1] https://github.com/apache/cordova-mobile-spec/tree/master/dependencies-plugin On Mon, Oct 21, 2013 at 10:44 AM, axel.nenn...@telekom.de wrote: Hi, the docs in https://cordova.apache.org/docs/en/3.1.0/config_ref_index.md.html#The%20config.xml%20Filesaythatthe feature element is only for the platform specific config.xml s, right? Is there a way to specify that my phonegap app needs a plugin on all platforms e.g. Globalization? Making up this example: https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html gap:dependency id=com.plugin.id url= https://github.com/myuser/someplugin; commit=428931ada3891801 subdir=some/path/here / We are building an app that uses Globalization in javascript; so there is no platform dependency How do I specifiy in www/config.xml that Globalization is needed as a plugin? Cheers Axel
Re: config.xml discussion, we need to talk
+1 -- I like both of those quite a lot On Mon, Oct 21, 2013 at 1:35 PM, Brian LeRoux b...@brian.io wrote: I think we need to be explicit, not talk about legacy or magic. I'd like to propose: Native Platform Dev -- Build Cordova apps on the metal. No helpers for moving across platforms. Web Project Dev -- Build web first projects that (mostly) treats native projects as build artifacts. On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson bra...@chromium.org wrote: Whoops, forgot my citation: [1] http://www.catb.org/jargon/html/magic-story.html On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts
Review Request 14793: CB-5125: replace child process exec with spawn
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/ --- Review request for cordova. Repository: cordova-cli Description --- CB-5125: replace child process exec with spawn This avoid stdout from platform scripts kill exec process because goes over maxBuffer (~200KB) Also this give immediate feedback to user on the cli, any output from platform script doesn't get buffer it gets passed to event emmiter Diffs - src/compile.js 34c24fe8e66d477d74728e018c250cf5e267c351 src/emulate.js cd4c038a3c2125224d25715a3fc2cf3b9e9f3cb0 src/run.js dddc1fc6f7a168267decdb3f6d8c4471d3480893 Diff: https://reviews.apache.org/r/14793/diff/ Testing --- Tested Android, iOS (mac osx) node 0.10.18 Thanks, Carlos Santana
Re: Review Request 14793: CB-5125: replace child process exec with spawn
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/#review27257 --- Haven't reviewed it yet, but wanted to make sure you remember to update all of the tests that spy on exec before pushing - Steven Gill On Oct. 21, 2013, 6:49 p.m., Carlos Santana wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/ --- (Updated Oct. 21, 2013, 6:49 p.m.) Review request for cordova. Repository: cordova-cli Description --- CB-5125: replace child process exec with spawn This avoid stdout from platform scripts kill exec process because goes over maxBuffer (~200KB) Also this give immediate feedback to user on the cli, any output from platform script doesn't get buffer it gets passed to event emmiter Diffs - src/compile.js 34c24fe8e66d477d74728e018c250cf5e267c351 src/emulate.js cd4c038a3c2125224d25715a3fc2cf3b9e9f3cb0 src/run.js dddc1fc6f7a168267decdb3f6d8c4471d3480893 Diff: https://reviews.apache.org/r/14793/diff/ Testing --- Tested Android, iOS (mac osx) node 0.10.18 Thanks, Carlos Santana
Re: Review Request 14793: CB-5125: replace child process exec with spawn
On Oct. 21, 2013, 6:54 p.m., Steven Gill wrote: Haven't reviewed it yet, but wanted to make sure you remember to update all of the tests that spy on exec before pushing Thanks Steven good catch. Will start looking into that. - Carlos --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/#review27257 --- On Oct. 21, 2013, 6:49 p.m., Carlos Santana wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/ --- (Updated Oct. 21, 2013, 6:49 p.m.) Review request for cordova. Repository: cordova-cli Description --- CB-5125: replace child process exec with spawn This avoid stdout from platform scripts kill exec process because goes over maxBuffer (~200KB) Also this give immediate feedback to user on the cli, any output from platform script doesn't get buffer it gets passed to event emmiter Diffs - src/compile.js 34c24fe8e66d477d74728e018c250cf5e267c351 src/emulate.js cd4c038a3c2125224d25715a3fc2cf3b9e9f3cb0 src/run.js dddc1fc6f7a168267decdb3f6d8c4471d3480893 Diff: https://reviews.apache.org/r/14793/diff/ Testing --- Tested Android, iOS (mac osx) node 0.10.18 Thanks, Carlos Santana
Re: CommitterWorkflow
Probably http://wiki.apache.org/cordova/WorkingWithThree is the best we've got. On Mon, Oct 21, 2013 at 1:53 PM, Josh Soref jso...@blackberry.com wrote: Hi, I've reviewed http://wiki.apache.org/cordova/CommitterWorkflow and there doesn't seem to be much content on CLI workflow. I'm specifically looking for a process which explains how to start from nothing and download the latest git repos (how does one even figure out which git repos to get) such that one can run all the release tests for a platform in order to send an email saying that the platform+cli is good for release cadence. Thanks - 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: Platforms Meet-up @ Waterloo
Please tell me if this list is wrong:
Attending: Joe, Shaz, Anis, Bryan Higgins, Gorkem, Carlos
I'll start a private thread with all of you to exchange travel itinerary
info contact info
On Fri, Oct 18, 2013 at 12:51 PM, Andrew Grieve agri...@chromium.orgwrote:
WOOOHOOO!! That's awesome!!!
On Fri, Oct 18, 2013 at 12:47 PM, Carlos Santana csantan...@gmail.comwrote:
I think the Cordova Gods are on my side this week !
I got approval from my company for travel funding.
travel['Kw Hotel And Conference Ctr']('105 King Street
East').on('Mon28th').done('Wed30th');
If any if you want to meet Monday night let me know.
--Carlos
On Thu, Oct 17, 2013 at 12:24 PM, Simon MacDonald
simon.macdon...@gmail.com
wrote:
On Oct 17, 2013 11:54 AM, Joe Bowser bows...@gmail.com wrote:
It's cheaper to go to Eastern Europe from Vancouver than it is to fly
to this airport.
This is true of almost all flights inside Canada. Anyway have fun all
as I
won't be able to make it down.
Simon
--
Carlos Santana
csantan...@gmail.com
Re: www/config.xml plugin dependencies
A MUST would be strong I think. Although the two ways don't mix well. Using dependency and plugin-add simultaneously is probably wrong. So plugin-add could look for www/config.xml dependency elements and suggest to continue to use them if one is found. If none is found then it adds the plugin. Updating plugins during create/prepare would be a good start. Plugins could be removed when the subdirs of the plugins directory and the dependency elements indicate it. Axel Am 21.10.2013 20:35 schrieb Michal Mocny mmo...@chromium.org: We've discussed adding dependancy to app's config.xml, but its interesting that you intend to have that work during build/prepare step. Previously I think this was discussed in terms of cordova create only, which wouldn't satisfy your use case. I think your use case is quite valid, but now im concerned about how to support removed dependancy over time, or manually installed plugins that arent in dependancy list... Maybe every plugin installed/removed *must* be reflected in the app's config.xml? -Michal On Mon, Oct 21, 2013 at 1:42 PM, Axel Nennker ignisvul...@gmail.com wrote: Yes. Currently we are adding plugin be hand. The problem is that we have a distributes developer team. So when the UI developers change something in www to require a plugin and merge that with master; then when the other developers pull master again the plugin is missing and the Application hangs. This has led to some frustration and wasted time. I think it would really help if www - developers could express a dependency on plugins so that the next phonegap local android build updates to the now missing plugins... cheers Axel 2013/10/21 Ian Clelland iclell...@chromium.org I don't think that we have app dependencies in Cordova (yet). If your app depends on a plugin, then you should install that plugin. Either cordova plugin add org.apache.cordova.globalization or plugman install org.apache.cordova.globalization (not sure about the command line params there) should add the plugin and modify your config.xml file appropriately. If you're concerned about automation / distribution, and want a simple way to declare all of your app's dependent plugins, rather than just documenting them, then you can use the technique that mobile-spec uses[1]: Create a dependency-only plugin which just lists all of the plugins on which your app depends, and as part of your create step, install that single plugin. Cordova will then recursively install all of the dependencies listed in it. [1] https://github.com/apache/cordova-mobile-spec/tree/master/dependencies-plugin On Mon, Oct 21, 2013 at 10:44 AM, axel.nenn...@telekom.de wrote: Hi, the docs in https://cordova.apache.org/docs/en/3.1.0/config_ref_index.md.html#The%20config.xml%20Filesaythatthefeature element is only for the platform specific config.xml s, right? Is there a way to specify that my phonegap app needs a plugin on all platforms e.g. Globalization? Making up this example: https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html gap:dependency id=com.plugin.id url= https://github.com/myuser/someplugin; commit=428931ada3891801 subdir=some/path/here / We are building an app that uses Globalization in javascript; so there is no platform dependency How do I specifiy in www/config.xml that Globalization is needed as a plugin? Cheers Axel
Re: config.xml discussion, we need to talk
+1 Although I was about to suggest single platform development and multi platform development. Axel Am 21.10.2013 19:36 schrieb Brian LeRoux b...@brian.io: I think we need to be explicit, not talk about legacy or magic. I'd like to propose: Native Platform Dev -- Build Cordova apps on the metal. No helpers for moving across platforms. Web Project Dev -- Build web first projects that (mostly) treats native projects as build artifacts. On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson bra...@chromium.org wrote: Whoops, forgot my citation: [1] http://www.catb.org/jargon/html/magic-story.html On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many
Re: config.xml discussion, we need to talk
+1 to Native Platform Dev vs Web Project Dev On Mon, Oct 21, 2013 at 1:31 PM, Axel Nennker ignisvul...@gmail.com wrote: +1 Although I was about to suggest single platform development and multi platform development. Axel Am 21.10.2013 19:36 schrieb Brian LeRoux b...@brian.io: I think we need to be explicit, not talk about legacy or magic. I'd like to propose: Native Platform Dev -- Build Cordova apps on the metal. No helpers for moving across platforms. Web Project Dev -- Build web first projects that (mostly) treats native projects as build artifacts. On Mon, Oct 21, 2013 at 8:34 AM, Braden Shepherdson bra...@chromium.org wrote: Whoops, forgot my citation: [1] http://www.catb.org/jargon/html/magic-story.html On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.org wrote: Less Magic (bin/create, Plugman) and More Magic (CLI).[1] Mike Billau's suggestions look decent to me. How about classic instead of legacy? Removes the it sucks and will die someday connotation, since that's not true. Braden On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the
Code review of new ios plugins
Hey Shaz, Looking at the Keyboard Statusbar plugins, would you be opposed to using: clobbers target=cordova.plugins.statusBar / instead of: clobbers target=window.StatusBar / Would require a major version bump, but probably it has little usage since it's new in labs still? Thinking here is that since it's not implementing any spec, we should keep symbols off of window / navigator objects. Would be good to encourage plugins not to pollute the global namespace I think. Other points from code-review standpoint: - Why make StatusBar a function? It has no prototype methods. - You're calling exec() from the module scope. You should add a runs/ to the js-module to ensure it gets run at start-up. You should also delay deviceready until it executes. cordova-plugin-device has an example of this. - Might be nicer to make the status-bar state a callback with keepCallback=true so that the native code is agnostic to where the namespace is mapped.
Re: Platforms Meet-up @ Waterloo
I'm not sure if I'll make it for the hacking, but I'm going to try and
make it for the social event.
On 13-10-21 4:12 PM, Andrew Grieve agri...@chromium.org wrote:
Please tell me if this list is wrong:
Attending: Joe, Shaz, Anis, Bryan Higgins, Gorkem, Carlos
I'll start a private thread with all of you to exchange travel itinerary
info contact info
On Fri, Oct 18, 2013 at 12:51 PM, Andrew Grieve
agri...@chromium.orgwrote:
WOOOHOOO!! That's awesome!!!
On Fri, Oct 18, 2013 at 12:47 PM, Carlos Santana
csantan...@gmail.comwrote:
I think the Cordova Gods are on my side this week !
I got approval from my company for travel funding.
travel['Kw Hotel And Conference Ctr']('105 King Street
East').on('Mon28th').done('Wed30th');
If any if you want to meet Monday night let me know.
--Carlos
On Thu, Oct 17, 2013 at 12:24 PM, Simon MacDonald
simon.macdon...@gmail.com
wrote:
On Oct 17, 2013 11:54 AM, Joe Bowser bows...@gmail.com wrote:
It's cheaper to go to Eastern Europe from Vancouver than it is to
fly
to this airport.
This is true of almost all flights inside Canada. Anyway have fun all
as I
won't be able to make it down.
Simon
--
Carlos Santana
csantan...@gmail.com
-
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: build failure
Hey David, I just uploaded a patch that should hopefully things for ya. Let me know if there are any more problems. On 18 October 2013 18:51, Tim Kim timki...@gmail.com wrote: Hrmmm. Shoot. Funny how a '.0' can paint you into a corner. I'm not sure if there are any easy solutions to this one since the code always pulls the latest. I think what I'll do is add some logic such that the new version-compare in plugman can handle differing version strings. Unfortunately it's pretty much end of the day for me here, but I'll attempt for a fix this weekend. On 18 October 2013 18:27, David Kemp drk...@google.com wrote: Hi Tim, That has indeed fixed the master branch, but the 3.1 release branch still has the problem. I currently always build with the latest tool chain (plugman) so a non backward-compatible change to plugman will be an issue. That would require that the fix to mobilespec be back-patched to 3.1 as well. Not sure if that has any other side-effects. On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim timki...@gmail.com wrote: Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: Platforms Meet-up @ Waterloo
I'm probably attending too... - 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: Platforms Meet-up @ Waterloo
My cell is 416-435-5836. We will be driving in from Toronto. On Mon, Oct 21, 2013 at 4:44 PM, Josh Soref jso...@blackberry.com wrote: I'm probably attending too... - 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: CommitterWorkflow
The recent thread on the Native Platform dev vs Web Project dev workflows seems to have some application here. If the Apache Way is to distribute source (not saying it is a frequent way, but should be a supported way), then there isn't much documentation on how to get it up and running as Josh describes below. There is a workflow that isn't documented. Would it make sense to have verbage in cordova-docs that describes that process in a more consumery way than http://wiki.apache.org/cordova/WorkingWithThree ? Perhaps titled Building Cordova from Source. Then the user can jump into the Native Platform vs Web Project flows. If there are +1's, then I can create a Jira item. On Oct 21, 2013, at 1:53 PM, Josh Soref jso...@blackberry.com wrote: I'm specifically looking for a process which explains how to start from nothing and download the latest git repos (how does one even figure out which git repos to get) such that one can run all the release tests for a platform in order to send an email saying that the platform+cli is good for release cadence.
Some plugin questions
From the Cordova blog, there was an announcement of updated plugins (http://cordova.apache.org/news/2013/10/10/plugins-release.html), including one for Android WebSQL. The blog entry ends with: You can check out the individual release notes in each of the plugin repos for more details. But if you browse at the registry, like here: http://plugins.cordova.io/#/org.apache.cordova.websql I do not see any links to the repo for the plugin. Both links are just to straight downloads. Would it make sense to add a link to the source code repo as well? Also, org.apache.cordova.websql does not seem to be here, https://git-wip-us.apache.org/repos/asf. What is the expectation for a user to figure out if he or she needs this particular plugin? I seem to remember some posts on this list about issues w/ Android and WebSQL, so I *assume* this is the fix for it, but I don't see how a random folk would know this. Nothing is noted here either: http://cordova.apache.org/docs/en/3.1.0/cordova_storage_storage.md.html#Sto rage. So I rambled a bit - sorry. I guess two main questions/suggestions: 1) Should the plugin repository have a better link back to the source? (Maybe it does and I didn't see it.) 2) Should there be some warning in the core Storage docs about Android/WebSQL (if I'm remembering right).
Re: www/config.xml plugin dependencies
Maybe we do just go the npm style route. cordova plugin add (without ID) - reads deps from config and installs them. cordova plugin add --save-deps ID - adds plugin and adds to config cordova plugin add --save-deps (without ID)- takes installed plugins and adds to deps something like that? On Mon, Oct 21, 2013 at 4:24 PM, Axel Nennker ignisvul...@gmail.com wrote: A MUST would be strong I think. Although the two ways don't mix well. Using dependency and plugin-add simultaneously is probably wrong. So plugin-add could look for www/config.xml dependency elements and suggest to continue to use them if one is found. If none is found then it adds the plugin. Updating plugins during create/prepare would be a good start. Plugins could be removed when the subdirs of the plugins directory and the dependency elements indicate it. Axel Am 21.10.2013 20:35 schrieb Michal Mocny mmo...@chromium.org: We've discussed adding dependancy to app's config.xml, but its interesting that you intend to have that work during build/prepare step. Previously I think this was discussed in terms of cordova create only, which wouldn't satisfy your use case. I think your use case is quite valid, but now im concerned about how to support removed dependancy over time, or manually installed plugins that arent in dependancy list... Maybe every plugin installed/removed *must* be reflected in the app's config.xml? -Michal On Mon, Oct 21, 2013 at 1:42 PM, Axel Nennker ignisvul...@gmail.com wrote: Yes. Currently we are adding plugin be hand. The problem is that we have a distributes developer team. So when the UI developers change something in www to require a plugin and merge that with master; then when the other developers pull master again the plugin is missing and the Application hangs. This has led to some frustration and wasted time. I think it would really help if www - developers could express a dependency on plugins so that the next phonegap local android build updates to the now missing plugins... cheers Axel 2013/10/21 Ian Clelland iclell...@chromium.org I don't think that we have app dependencies in Cordova (yet). If your app depends on a plugin, then you should install that plugin. Either cordova plugin add org.apache.cordova.globalization or plugman install org.apache.cordova.globalization (not sure about the command line params there) should add the plugin and modify your config.xml file appropriately. If you're concerned about automation / distribution, and want a simple way to declare all of your app's dependent plugins, rather than just documenting them, then you can use the technique that mobile-spec uses[1]: Create a dependency-only plugin which just lists all of the plugins on which your app depends, and as part of your create step, install that single plugin. Cordova will then recursively install all of the dependencies listed in it. [1] https://github.com/apache/cordova-mobile-spec/tree/master/dependencies-plugin On Mon, Oct 21, 2013 at 10:44 AM, axel.nenn...@telekom.de wrote: Hi, the docs in https://cordova.apache.org/docs/en/3.1.0/config_ref_index.md.html#The%20config.xml%20Filesaythatthefeatureelement is only for the platform specific config.xml s, right? Is there a way to specify that my phonegap app needs a plugin on all platforms e.g. Globalization? Making up this example: https://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html gap:dependency id=com.plugin.id url= https://github.com/myuser/someplugin; commit=428931ada3891801 subdir=some/path/here / We are building an app that uses Globalization in javascript; so there is no platform dependency How do I specifiy in www/config.xml that Globalization is needed as a plugin? Cheers Axel
Re: Intro Jerome
Jerome, if you haven't seen it already, here is a good place to start: http://wiki.apache.org/cordova/ContributorWorkflow On Oct 19, 2013, at 3:06 PM, Jerome Schmaltz jerome.schma...@gmail.com wrote: Hi! My name is Jerome and it's my first experience as a committer for Apache. I've been programming since 11 and I love Apache projects which I use regularly in my daily work. I'm pretty excited to give a hand and I'll help as much as I can. Thanks Jerome
Re: Some plugin questions
The answer to part 1 is that we are working on it. https://issues.apache.org/jira/browse/CB-5128 https://issues.apache.org/jira/browse/CB-5130 On Mon, Oct 21, 2013 at 2:12 PM, Ray Camden rayca...@adobe.com wrote: From the Cordova blog, there was an announcement of updated plugins (http://cordova.apache.org/news/2013/10/10/plugins-release.html), including one for Android WebSQL. The blog entry ends with: You can check out the individual release notes in each of the plugin repos for more details. But if you browse at the registry, like here: http://plugins.cordova.io/#/org.apache.cordova.websql I do not see any links to the repo for the plugin. Both links are just to straight downloads. Would it make sense to add a link to the source code repo as well? Also, org.apache.cordova.websql does not seem to be here, https://git-wip-us.apache.org/repos/asf. What is the expectation for a user to figure out if he or she needs this particular plugin? I seem to remember some posts on this list about issues w/ Android and WebSQL, so I *assume* this is the fix for it, but I don't see how a random folk would know this. Nothing is noted here either: http://cordova.apache.org/docs/en/3.1.0/cordova_storage_storage.md.html#Sto rage. So I rambled a bit - sorry. I guess two main questions/suggestions: 1) Should the plugin repository have a better link back to the source? (Maybe it does and I didn't see it.) 2) Should there be some warning in the core Storage docs about Android/WebSQL (if I'm remembering right).
Re: CommitterWorkflow
+1 On Mon, Oct 21, 2013 at 2:12 PM, Marcel Kinard cmarc...@gmail.com wrote: The recent thread on the Native Platform dev vs Web Project dev workflows seems to have some application here. If the Apache Way is to distribute source (not saying it is a frequent way, but should be a supported way), then there isn't much documentation on how to get it up and running as Josh describes below. There is a workflow that isn't documented. Would it make sense to have verbage in cordova-docs that describes that process in a more consumery way than http://wiki.apache.org/cordova/WorkingWithThree ? Perhaps titled Building Cordova from Source. Then the user can jump into the Native Platform vs Web Project flows. If there are +1's, then I can create a Jira item. On Oct 21, 2013, at 1:53 PM, Josh Soref jso...@blackberry.com wrote: I'm specifically looking for a process which explains how to start from nothing and download the latest git repos (how does one even figure out which git repos to get) such that one can run all the release tests for a platform in order to send an email saying that the platform+cli is good for release cadence.
The Cordova plugin registry blog post is up!
The Cordova plugin registry blog post (reviewed herehttps://reviews.apache.org/r/14757/) has been committed. I want to add a couple of things to the readme, but figured I'd check here first. 1. The generated html file (ie. /public/news//mm/dd/blog-post.html) needs to be svn added, right? It's not in the instructions and I wasn't sure if there was a mechanism that would build it on the server. I eventually made another commit to add it. 2. I didn't know to add a !--more-- comment to specify the cutoff point for the front page until I looked at other posts. Is that the right way to do it?
Re: The Cordova plugin registry blog post is up!
Yes to both of your questions. 1) You need svn add the generated file. You should see a question mark when you do a svn status letting you know it hasn't been added. 2) The more tag is exactly what you use to handle the cutoff. I also learned this by looking at other posts. Would be a nice addition for the readme. Tweeted it out https://twitter.com/apachecordova/status/392411825246990336 On Mon, Oct 21, 2013 at 2:41 PM, Max Woghiren m...@chromium.org wrote: The Cordova plugin registry blog post (reviewed herehttps://reviews.apache.org/r/14757/) has been committed. I want to add a couple of things to the readme, but figured I'd check here first. 1. The generated html file (ie. /public/news//mm/dd/blog-post.html) needs to be svn added, right? It's not in the instructions and I wasn't sure if there was a mechanism that would build it on the server. I eventually made another commit to add it. 2. I didn't know to add a !--more-- comment to specify the cutoff point for the front page until I looked at other posts. Is that the right way to do it?
Re: build failure
Looks like it fixed it! On Oct 21, 2013 4:40 PM, Tim Kim timki...@gmail.com wrote: Hey David, I just uploaded a patch that should hopefully things for ya. Let me know if there are any more problems. On 18 October 2013 18:51, Tim Kim timki...@gmail.com wrote: Hrmmm. Shoot. Funny how a '.0' can paint you into a corner. I'm not sure if there are any easy solutions to this one since the code always pulls the latest. I think what I'll do is add some logic such that the new version-compare in plugman can handle differing version strings. Unfortunately it's pretty much end of the day for me here, but I'll attempt for a fix this weekend. On 18 October 2013 18:27, David Kemp drk...@google.com wrote: Hi Tim, That has indeed fixed the master branch, but the 3.1 release branch still has the problem. I currently always build with the latest tool chain (plugman) so a non backward-compatible change to plugman will be an issue. That would require that the fix to mobilespec be back-patched to 3.1 as well. Not sure if that has any other side-effects. On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim timki...@gmail.com wrote: Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: build failure
Woo! On 21 October 2013 15:59, David Kemp drk...@google.com wrote: Looks like it fixed it! On Oct 21, 2013 4:40 PM, Tim Kim timki...@gmail.com wrote: Hey David, I just uploaded a patch that should hopefully things for ya. Let me know if there are any more problems. On 18 October 2013 18:51, Tim Kim timki...@gmail.com wrote: Hrmmm. Shoot. Funny how a '.0' can paint you into a corner. I'm not sure if there are any easy solutions to this one since the code always pulls the latest. I think what I'll do is add some logic such that the new version-compare in plugman can handle differing version strings. Unfortunately it's pretty much end of the day for me here, but I'll attempt for a fix this weekend. On 18 October 2013 18:27, David Kemp drk...@google.com wrote: Hi Tim, That has indeed fixed the master branch, but the 3.1 release branch still has the problem. I currently always build with the latest tool chain (plugman) so a non backward-compatible change to plugman will be an issue. That would require that the fix to mobilespec be back-patched to 3.1 as well. Not sure if that has any other side-effects. On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim timki...@gmail.com wrote: Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: config.xml discussion, we need to talk
Steven, of course, that is what I meant. Did you ever finish that review of my PhonegGap book? ;-) the next one will be out in a few weeks (hopefully). John M. Wargo On Oct 18, 2013, at 2:29 PM, Steven Gill stevengil...@gmail.com wrote: John: If you decided to take a stab a blogging about it, please think about blogging on the cordova site! We can all review it before publishing it too! Erik: that video was awesome! Let me know when Gorkem does a release and I can post it on the cordova twitter feed. Michal: Could just be CLI vs Plugman workflow On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org wrote: I wonder if we should not work out better names for the two workflows. Both are kinda command-line-based so saying CLI vs old is confusing. As is saying the bin/ script flow confusing. Not sure if multi vs single platform flow is any better, since you can use both flows for one or more platforms. Anyway, if we have more obvious/catchy names, then we can be more clear in our communications which flow our answers are relevant to. i.e., use plugman to ... (only for ___ flow). i.e., Be carefully when editing in IDE ... (only for ___ flow). -Michal On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com wrote: Erik that's great! Where can we download it? On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org wrote: Awesome video!! On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit ede...@redhat.com wrote: On the topic of IDE support my collage Gorkem has made a nice wizard in eclipse that mimics the CLI have a look at this video http://www.youtube.com/watch?v=QUyUUtmTYok On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote: Great Bryan Totally agree !!! Cordialement. --- Maxime LUCE - Somatic maxime.l...@somatic.fr 06 28 60 72 34 De : Brian LeRouxmailto:b...@brian.io Envoyé : 18/10/2013 01:48 À : dev@cordova.apache.orgmailto:dev@cordova.apache.org Objet : Re: config.xml discussion, we need to talk I don't really appreciate comments that we don't talk to our users, or build apps in anger. Neither of those assertions are true. The origins of these initiatives are based on both community feedback, and direct experience. Keeping your focus on just pure platform side of a project is fine, of course, since the CLI delegates to the platform. This was also a deliberate learning from MANY attempts at an architecture that satisfies both approaches. It separates the concerns and respects the platform will be canonical for the common workflows supported. This is a very real example of Conway's Law btw. [1] Anyhow. Deep breath! Software has bugs, people will report them, and we'll continue to improve. This is a very large group with a very diverse community that spans regular old hackers to the humble web designers. We need to respect that, and maybe be a little more compassionate to each other too. All software is fucked up, and at the end of the day, it is our perpetual job to make it a little less fucked up. [1] http://en.wikipedia.org/wiki/Conway's_law [Inline image 1] On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams to...@devgeeks.org mailto:to...@devgeeks.org wrote: Late to the party due to timezone fun, but I just want to chime in in support of the CLI. As a dev working on an actual nontrivial real world app, I would like to let it be known that we (SpiderOak) have been heavy drinkers of the CLI Kool-Aid since its infancy. We have even managed to get to the point where ./platforms/**/* is just a build artefact (mostly by using hooks and tying the whole thing together with Grunt). We have a fast and fairly complex app (both many core plugins as well and a few custom/third party ones), that even includes the ability to white label it with relative ease. I feel pretty strongly in favour of the CLI and strongly advocate its use when asked in the #phonegap IRC channel. Just my opinion, but thought it was important to add to the discussion. - tommy / devgeeks On 18 Oct 2013 04:44, Anis KADRI anis.ka...@gmail.commailto: anis.ka...@gmail.com wrote: Sweet. So I think we all agree (expect Joe perhaps?) that both approaches should be supported :-) On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana csantan...@gmail.com mailto:csantan...@gmail.com wrote: I meant in addition of .cordova/lib also allow also to do something like cordova platform add ios --path=./cordova_components/cordova-ios On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana csantan...@gmail.com mailto:csantan...@gmail.com wrote: ++1 to install from a given directory instead of .cordova/libs. On Thu, Oct 17, 2013 at 12:10 PM, Viras vi...@users.sourceforge.net mailto:vi...@users.sourceforge.net wrote: This might be true - it took me quite some
Re: Default template - size
I brought this up with fil a while back and it's a documented issue in jira. He said config.xml had to be fixed to support different platform icons before something could be done about this. I can dig up the email and forward it off tomorrow. John M. Wargo On Oct 18, 2013, at 3:01 PM, Steven Gill stevengil...@gmail.com wrote: They should be in the merge folder under each platform instead of the www. On Fri, Oct 18, 2013 at 11:52 AM, Shazron shaz...@gmail.com wrote: When someone creates a vanilla iOS project from the CLI, the default app is 8 MB. It's obvious why this is so, the www/res folder includes all the icons for all the platforms and is 8 MB. Can we change this (why include all icons -- the www should be agnostic), or is this a documentation problem.
Re: config.xml discussion, we need to talk
To plugman or not to plugman, that is the question. Or Different styles of plugin management. John M. Wargo On Oct 18, 2013, at 3:03 PM, Steven Gill stevengil...@gmail.com wrote: I think SinplePlatform vs MultiPlatform is misleading because you can use the CLI to do single platform development. On Fri, Oct 18, 2013 at 11:51 AM, Jesse purplecabb...@gmail.com wrote: SinglePlatform vs MultiPlatform makes the most sense to me. SinglePlatform = Focus on a single platform, and use plugman and the platform scripts directly. Useful when you only have that particular device to test on, or only have access to that device's marketplace. Also useful for platform developers who are focused primarily on the native code. ( aka DivideAndConquer ) MultiPlatform = Build your app for a bunch of platforms at the same time. Great for when you know you are targeting multiple stores/devices. ( aka DucksInARow or MagicBullet ) I tend to lean towards the SinglePlatform, so maybe someone else could enumerate more Multi benefits. @purplecabbage risingj.com On Fri, Oct 18, 2013 at 11:28 AM, Steven Gill stevengil...@gmail.com wrote: John: If you decided to take a stab a blogging about it, please think about blogging on the cordova site! We can all review it before publishing it too! Erik: that video was awesome! Let me know when Gorkem does a release and I can post it on the cordova twitter feed. Michal: Could just be CLI vs Plugman workflow On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny mmo...@chromium.org wrote: I wonder if we should not work out better names for the two workflows. Both are kinda command-line-based so saying CLI vs old is confusing. As is saying the bin/ script flow confusing. Not sure if multi vs single platform flow is any better, since you can use both flows for one or more platforms. Anyway, if we have more obvious/catchy names, then we can be more clear in our communications which flow our answers are relevant to. i.e., use plugman to ... (only for ___ flow). i.e., Be carefully when editing in IDE ... (only for ___ flow). -Michal On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI anis.ka...@gmail.com wrote: Erik that's great! Where can we download it? On Oct 18, 2013 8:01 AM, Andrew Grieve agri...@chromium.org wrote: Awesome video!! On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit ede...@redhat.com wrote: On the topic of IDE support my collage Gorkem has made a nice wizard in eclipse that mimics the CLI have a look at this video http://www.youtube.com/watch?v=QUyUUtmTYok On 18 Oct,2013, at 4:29 , Maxime LUCE max...@somatic.fr wrote: Great Bryan Totally agree !!! Cordialement. --- Maxime LUCE - Somatic maxime.l...@somatic.fr 06 28 60 72 34 De : Brian LeRouxmailto:b...@brian.io Envoyé : 18/10/2013 01:48 À : dev@cordova.apache.orgmailto:dev@cordova.apache.org Objet : Re: config.xml discussion, we need to talk I don't really appreciate comments that we don't talk to our users, or build apps in anger. Neither of those assertions are true. The origins of these initiatives are based on both community feedback, and direct experience. Keeping your focus on just pure platform side of a project is fine, of course, since the CLI delegates to the platform. This was also a deliberate learning from MANY attempts at an architecture that satisfies both approaches. It separates the concerns and respects the platform will be canonical for the common workflows supported. This is a very real example of Conway's Law btw. [1] Anyhow. Deep breath! Software has bugs, people will report them, and we'll continue to improve. This is a very large group with a very diverse community that spans regular old hackers to the humble web designers. We need to respect that, and maybe be a little more compassionate to each other too. All software is fucked up, and at the end of the day, it is our perpetual job to make it a little less fucked up. [1] http://en.wikipedia.org/wiki/Conway's_law [Inline image 1] On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams to...@devgeeks.org mailto:to...@devgeeks.org wrote: Late to the party due to timezone fun, but I just want to chime in in support of the CLI. As a dev working on an actual nontrivial real world app, I would like to let it be known that we (SpiderOak) have been heavy drinkers of the CLI Kool-Aid since its infancy. We have even managed to get to the point where ./platforms/**/* is just a build artefact (mostly by using hooks and tying the whole thing together with Grunt). We have a fast and fairly complex app (both many core plugins as well and a few custom/third party ones), that even includes the ability to white label it with relative ease. I feel pretty strongly in favour of the CLI and strongly advocate
2.9.1 Backport release
Having a tonne of fun putting the bunny back in the box. Here is a list of plugin defects [1] that have been closed between 2.9.0 and 3.1.0 Please have a look and decide if you think each is worth the effort of backporting. [1] https://issues.apache.org/jira/browse/CB-5136 @purplecabbage risingj.com
Re: new meta data for plugin.xml
Not so much an accident as very deliberate!
When we started this is how you worked with JSON:
var data = eval('' + my_json_string + '')
We then had some fun w/ Crockford's JSON lib licensing. [1] Specifically
IBM did not like the enforceability of The Software shall be used for
Good, not Evil. clause. Doug offered to rewrite it: The Software shall be
used for Good, not Evil, unless you are IBM. But surprisingly this was not
enough. So, we wrote our own JSON lib. Yup. JavaScript was pretty awesome 5
years ago.
/me grumbles about lawn or something
[1] http://www.json.org/license.html
On Mon, Oct 21, 2013 at 7:41 AM, Braden Shepherdson bra...@chromium.orgwrote:
I'd be happier if it were JSON, but it's not, and the XML doesn't cause
enough pain to be worth making the switch.
Ian explained it accurately; it's mostly a historical accident that we're
using XML.
Braden
On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist lholm...@redhat.com
wrote:
yea, this is understandable. wasn't really sure the reasoning, but it
looks like diminishing returns here
On Oct 21, 2013, at 10:06 AM, Michal Mocny mmo...@chromium.org wrote:
XML is also buying us a couple of small but nice features, such as
optionally wrapping tags with a platform tag or (potentially) a
mode
tag, etc. That functionality would not be expressed as cleanly with
JSON,
so its not a pure win to move away from XML.
Add to that the fact that we are already perceived to change stuff way
too
often for no due cause, I just really don't see the value.
On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland iclell...@google.com
wrote:
I suspect that it is because plugin.xml was derived (intellectually,
if
not
literally) from config.xml, which was an XML file because of the W3C
Widgets spec, which we tried to adhere to.
Whether that spec is still relevant (there doesn't seem to be a lot of
vendor interest in it (speaking as an Apache member, *not* as a vendor
representative)) is definitely up for debate. There probably are some
gains
to be made in switching to a JSON config format, given how much of the
project is JavaScript these days, but it might not be worth all of the
work
it would take to do it.
Ian
On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist lholm...@redhat.com
wrote:
Perhaps this has been brought up before, but why are we using an xml
file? why not make it a json file.
Plugman is written in node( js ) so why not have the plugin config
file
in it's native format. This will probably save a bit of code since
the
xml
is converted to an object to manipulate anyway.
i know this is a little off topic.
thoughts?
On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com
wrote:
I have created an issue to keep track of the registry refactor.
https://issues.apache.org/jira/browse/CB-5130
On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com
wrote:
I added some validation for plugin names (to follow
reverse-domain-name convention) a couple of weeks ago but there
needs
to be more of it for sure.
On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill
stevengil...@gmail.com
wrote:
I have created an issue to track the meta tag addition.
https://issues.apache.org/jira/browse/CB-5128
I agree with doing validation with plugman during publish time. We
should
decide soon which ones are going to be mandatory and which ones
will
be
optional. Probably update the plugin spec + our docs around
creating
plugins as well.
On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com
wrote:
Perhaps either plugman or the registry should do some validation,
and
have
some required fields? I know that PhoneGap Build when you try
to
submit a
plugin they error out if you are missing some fields that they
require.
On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan
gorkem.er...@gmail.com
wrote:
+1 for adding metadata but should more of the metadata be
compulsory?
JBoss tools plugin discovery uses the cordova.io registry and
some
of
the
plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a
screenshot
that shows how the case. http://snag.gy/J8rl6.jpg is a
screenshot
of
a
few
plugins that has most of its data. As you can see with the
missing
descriptions etc. it is not possible to do an informed decision
on
whether
to use a plugin or not. Although information such as keywords
does
not
seem
like important it becomes quite useful when you are trying to
find
a
certain plugin.
--
Gorkem
On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny
mmo...@chromium.org
wrote:
+1 to repo / issue / website / docs etc metadata
-1 *for now* to dependencies at specific versions, and testing
related
Re: 2.9.1 Backport release
On 10/21/13 7:38 PM, Jesse purplecabb...@gmail.com wrote: Having a tonne of fun putting the bunny back in the box. Here is a list of plugin defects [1] that have been closed between 2.9.0 and 3.1.0 Please have a look and decide if you think each is worth the effort of backporting. [1] https://issues.apache.org/jira/browse/CB-5136 While I don't intend to ever use old versions, here's a short opinion on each: + CB-4656 https://issues.apache.org/jira/browse/CB-4656 ( android ) + CB-4958 https://issues.apache.org/jira/browse/CB-4958 ( iOS 7 ) + CB-4471 https://issues.apache.org/jira/browse/CB-4471 ( android ) - CB-4181 https://issues.apache.org/jira/browse/CB-4181 ( iOS ) - CB-4192 https://issues.apache.org/jira/browse/CB-4192 ( all ) + CB-4900 https://issues.apache.org/jira/browse/CB-4900 ( Win8 ) - CB-4592 https://issues.apache.org/jira/browse/CB-4592 ( BB ) + CB-4090 https://issues.apache.org/jira/browse/CB-4090 ( WPx ) + CB-2607 https://issues.apache.org/jira/browse/CB-2607 ( WPx ) + CB-1543 https://issues.apache.org/jira/browse/CB-1543 ( WPx ) - CB-3569 https://issues.apache.org/jira/browse/CB-3569 ( android ) - CB-4480 https://issues.apache.org/jira/browse/CB-4480 ( iOS ) - CB-2828 https://issues.apache.org/jira/browse/CB-2828 ( WPx ) + CB-4054 https://issues.apache.org/jira/browse/CB-4054 ( WPx ) - CB-4264 https://issues.apache.org/jira/browse/CB-4264 ( iOS ) + CB-4514 https://issues.apache.org/jira/browse/CB-4514 ( android ) + CB-4771 https://issues.apache.org/jira/browse/CB-4771 ( all ) x CB-4090 https://issues.apache.org/jira/browse/CB-4090 ( WPx ) -- you listed this already + CB-4521 https://issues.apache.org/jira/browse/CB-4521 ( android ) + CB-4147 https://issues.apache.org/jira/browse/CB-4147 ( iOS ) - CB-4864 https://issues.apache.org/jira/browse/CB-4864 ( android ) x CB-4988 https://issues.apache.org/jira/browse/CB-4988 ( iOS 7 ) -- this is really CB-4930 + CB-3747 https://issues.apache.org/jira/browse/CB-3747 ( android ) + CB-4858 https://issues.apache.org/jira/browse/CB-4858 ( android ) + CB-4087 https://issues.apache.org/jira/browse/CB-4087 ( android ) + CB-4930 https://issues.apache.org/jira/browse/CB-4930 ( iOS 7 ) + CB-4926 https://issues.apache.org/jira/browse/CB-4926 ( win8 ) + CB-4586 https://issues.apache.org/jira/browse/CB-4586 ( android ) + CB-4847 https://issues.apache.org/jira/browse/CB-4847 ( iOS 7 ) x CB-4471 https://issues.apache.org/jira/browse/CB-4471 ( android ) -- you listed this already + CB-3628 https://issues.apache.org/jira/browse/CB-3628 ( android ) -- good luck, the bug has no indication of what work was done x CB-4847 https://issues.apache.org/jira/browse/CB-4847 ( iOS 7 ) -- you listed this already Key: + probably worth it - not worth it x duplicate of another line in the list Roughly: - I don't see any reason to do work on mobile-spec -- it's a test right? - For really obscure things, you have better things to do w/ your time. - For crashers, it's probably worth doing - For missing functionality to key areas, it's probably worth doing (PUT is not in this bucket IMO, if people need it, let them upgrade to 3.x) - For ugly behavior on a platform, it's probably worth doing - 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: config.xml discussion, we need to talk
Don't forget the short lived deviceReady! ;-) Most suggestions so far can't be easily understood at first glance. Legacy, merges, workflow and so on aren't words a reader is going to understand immediately when they look at the docs and decide if that is an article they want to read. We can't name it using terms we use, but instead naming it as something that unfamiliar developers will intuitively understand. John M. Wargo On Oct 21, 2013, at 11:26 AM, Mike Billau mike.bil...@gmail.com wrote: Lets make the name as confusing as possible, to live up to our history (callback, phonegap, cordova.) ;) Personally I think that the names should try to describe the difference between the workflows instead of trying to prescribe some type of usage, since there are unknown and developing use cases. To me the main difference between the workflows is that with the CLI, things get merged for you automatically, so I'm in favor of something like CLI/Merges Workflow and Non-CLI/Legacy Workflow, and in the very first sentence of Non-CLI/Legacy we say It's called Legacy because it was the pre-3.0 worfklow, not because it is no longer supported. Michal, we created an item to track the doc changes: https://issues.apache.org/jira/browse/CB-5122 I think the bulk of the workflow discussion can fit into the Development Paths section in the main Overview Guide. I'll get started but will continue to monitor this thread. On Mon, Oct 21, 2013 at 10:01 AM, Michal Mocny mmo...@chromium.org wrote: (Okay, this thread at high risk of bikeshedding, just going to mention that ;) But I do think it would be great to settle once and for all. I like the distinction Steven/Brian are making: Project flow vs Platform flow. I'm not sure that those names are immediately 100% clear (I'll ponder over it) but I like the focus points. I think Ian nails the description: CLI encourages the Your cordova web view *IS* your application mindset I don't have a big preference one way or the other regarding attaching the word legacy to the Platform Flow. I like that it conveys: the flow you are used to and there exists a new flow now that you should evaluate but I don't like that it may also convey this flow is going to be deprecated which I don't think is true. Whatever we call it, I think its important to signal that Platform workflow is for supporting mucking with platform internals not for single platform dev. Single platform dev can be done using CLI just as easily. Should we create a wiki/doc which explains the flow and lists the pros/cons? On Mon, Oct 21, 2013 at 9:20 AM, Ian Clelland iclell...@google.com wrote: Legacy, though, sounds like it's something that we're actively moving away from; something that we support only grudgingly, and which we might deprecate at the drop of a hat. The platform-only workflow supports legitimate use-cases which CLI probably will never cover -- things like embedding a cordova web view inside of a larger platform-native project. The major difference I see with CLI is that it encourages the Your cordova web view *IS* your application mindset. (And if that's true, then why wouldn't you aim for cross-platform development?) The pre-CLI workflow is still the way to build all other sorts of applications. Ian On Fri, Oct 18, 2013 at 11:30 PM, purplecabbage purplecabb...@gmail.com wrote: I like merge-flow and legacy-flow Sent from my iPhone On Oct 18, 2013, at 6:59 PM, Carlos Santana csantan...@gmail.com wrote: Cross Platform - use Merge Flow Single Platform - use Legacy Flow Using Multi Platform or Cross Platform is also fine Using Flow or Mode is also fine On Friday, October 18, 2013, Brian LeRoux wrote: Ya, to me the difference is that one workflow embraces the native platform and tooling (plugman and bin/scripts) while the other focuses on building a web project (cli/merges/etc). As a dev, if I'm ONLY worried about one platform (like a Cordova implementor or many of our community folk) then bin/scripts suffices. As soon as I'm concerned with more than one platform the CLI workflows kick in. That was the use case anyhow. On Fri, Oct 18, 2013 at 3:21 PM, Steven Gill stevengil...@gmail.com wrote: Brian suggested Project Development (CLI workflow) vs Platform Development (bin/scripts) On Fri, Oct 18, 2013 at 3:09 PM, Steven Gill stevengil...@gmail.com wrote: We need more suggestions! Anis suggested picking to arbitrary names that don't reflect the workflows but would be easy to refer to. On Fri, Oct 18, 2013 at 12:41 PM, Michal Mocny mmo...@chromium.org wrote: I use the IDE with the CLI and hope to make it better. In my mind, the old way is for making platform modifications, and the new way threads platforms/ as a build artifact. If you must control the platform code, you sacrifice easy upgrades and ease of multi-platform
RE: Some plugin questions
The websql plugin is in the cordova-labs repo. See https://github.com/apache/cordova-labs/tree/plugins/websql for details :) You are right, there are issues with websql on android! Sent from my Windows Phone From: Ray Camdenmailto:rayca...@adobe.com Sent: 10/22/2013 4:13 To: dev@cordova.apache.orgmailto:dev@cordova.apache.org Subject: Some plugin questions From the Cordova blog, there was an announcement of updated plugins (http://cordova.apache.org/news/2013/10/10/plugins-release.html), including one for Android WebSQL. The blog entry ends with: You can check out the individual release notes in each of the plugin repos for more details. But if you browse at the registry, like here: http://plugins.cordova.io/#/org.apache.cordova.websql I do not see any links to the repo for the plugin. Both links are just to straight downloads. Would it make sense to add a link to the source code repo as well? Also, org.apache.cordova.websql does not seem to be here, https://git-wip-us.apache.org/repos/asf. What is the expectation for a user to figure out if he or she needs this particular plugin? I seem to remember some posts on this list about issues w/ Android and WebSQL, so I *assume* this is the fix for it, but I don't see how a random folk would know this. Nothing is noted here either: http://cordova.apache.org/docs/en/3.1.0/cordova_storage_storage.md.html#Sto rage. So I rambled a bit - sorry. I guess two main questions/suggestions: 1) Should the plugin repository have a better link back to the source? (Maybe it does and I didn't see it.) 2) Should there be some warning in the core Storage docs about Android/WebSQL (if I'm remembering right).
Re: Code review of new ios plugins
Answers inline. Looking at the Keyboard Statusbar plugins, would you be opposed to using: clobbers target=cordova.plugins.statusBar / instead of: clobbers target=window.StatusBar / Agreed. Would require a major version bump, but probably it has little usage since it's new in labs still? Agreed, major version bump. Thinking here is that since it's not implementing any spec, we should keep symbols off of window / navigator objects. Would be good to encourage plugins not to pollute the global namespace I think. Agreed. Other points from code-review standpoint: - Why make StatusBar a function? It has no prototype methods. Originally it had prototype methods, but I changed that - yup we can remove that. - You're calling exec() from the module scope. You should add a runs/ to the js-module to ensure it gets run at start-up. You should also delay deviceready until it executes. cordova-plugin-device has an example of this. Great - wasn't too sure about how that all worked, let's change that. - Might be nicer to make the status-bar state a callback with keepCallback=true so that the native code is agnostic to where the namespace is mapped. Agreed. Thanks Andrew! I'll add an issue for this.
Re: Code review of new ios plugins
https://issues.apache.org/jira/browse/CB-5138 On Mon, Oct 21, 2013 at 5:10 PM, Shazron shaz...@gmail.com wrote: Answers inline. Looking at the Keyboard Statusbar plugins, would you be opposed to using: clobbers target=cordova.plugins.statusBar / instead of: clobbers target=window.StatusBar / Agreed. Would require a major version bump, but probably it has little usage since it's new in labs still? Agreed, major version bump. Thinking here is that since it's not implementing any spec, we should keep symbols off of window / navigator objects. Would be good to encourage plugins not to pollute the global namespace I think. Agreed. Other points from code-review standpoint: - Why make StatusBar a function? It has no prototype methods. Originally it had prototype methods, but I changed that - yup we can remove that. - You're calling exec() from the module scope. You should add a runs/ to the js-module to ensure it gets run at start-up. You should also delay deviceready until it executes. cordova-plugin-device has an example of this. Great - wasn't too sure about how that all worked, let's change that. - Might be nicer to make the status-bar state a callback with keepCallback=true so that the native code is agnostic to where the namespace is mapped. Agreed. Thanks Andrew! I'll add an issue for this.
Re: new meta data for plugin.xml
Thanks Brian. It's interesting to hear the history.
Sent from my iPhone
On Oct 21, 2013, at 7:45 PM, Brian LeRoux b...@brian.io wrote:
Not so much an accident as very deliberate!
When we started this is how you worked with JSON:
var data = eval('' + my_json_string + '')
We then had some fun w/ Crockford's JSON lib licensing. [1] Specifically
IBM did not like the enforceability of The Software shall be used for
Good, not Evil. clause. Doug offered to rewrite it: The Software shall be
used for Good, not Evil, unless you are IBM. But surprisingly this was not
enough. So, we wrote our own JSON lib. Yup. JavaScript was pretty awesome 5
years ago.
/me grumbles about lawn or something
[1] http://www.json.org/license.html
On Mon, Oct 21, 2013 at 7:41 AM, Braden Shepherdson
bra...@chromium.orgwrote:
I'd be happier if it were JSON, but it's not, and the XML doesn't cause
enough pain to be worth making the switch.
Ian explained it accurately; it's mostly a historical accident that we're
using XML.
Braden
On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist lholm...@redhat.com
wrote:
yea, this is understandable. wasn't really sure the reasoning, but it
looks like diminishing returns here
On Oct 21, 2013, at 10:06 AM, Michal Mocny mmo...@chromium.org wrote:
XML is also buying us a couple of small but nice features, such as
optionally wrapping tags with a platform tag or (potentially) a
mode
tag, etc. That functionality would not be expressed as cleanly with
JSON,
so its not a pure win to move away from XML.
Add to that the fact that we are already perceived to change stuff way
too
often for no due cause, I just really don't see the value.
On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland iclell...@google.com
wrote:
I suspect that it is because plugin.xml was derived (intellectually,
if
not
literally) from config.xml, which was an XML file because of the W3C
Widgets spec, which we tried to adhere to.
Whether that spec is still relevant (there doesn't seem to be a lot of
vendor interest in it (speaking as an Apache member, *not* as a vendor
representative)) is definitely up for debate. There probably are some
gains
to be made in switching to a JSON config format, given how much of the
project is JavaScript these days, but it might not be worth all of the
work
it would take to do it.
Ian
On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist lholm...@redhat.com
wrote:
Perhaps this has been brought up before, but why are we using an xml
file? why not make it a json file.
Plugman is written in node( js ) so why not have the plugin config
file
in it's native format. This will probably save a bit of code since
the
xml
is converted to an object to manipulate anyway.
i know this is a little off topic.
thoughts?
On Oct 18, 2013, at 5:31 PM, Steven Gill stevengil...@gmail.com
wrote:
I have created an issue to keep track of the registry refactor.
https://issues.apache.org/jira/browse/CB-5130
On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI anis.ka...@gmail.com
wrote:
I added some validation for plugin names (to follow
reverse-domain-name convention) a couple of weeks ago but there
needs
to be more of it for sure.
On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill
stevengil...@gmail.com
wrote:
I have created an issue to track the meta tag addition.
https://issues.apache.org/jira/browse/CB-5128
I agree with doing validation with plugman during publish time. We
should
decide soon which ones are going to be mandatory and which ones
will
be
optional. Probably update the plugin spec + our docs around
creating
plugins as well.
On Fri, Oct 18, 2013 at 11:54 AM, Shazron shaz...@gmail.com
wrote:
Perhaps either plugman or the registry should do some validation,
and
have
some required fields? I know that PhoneGap Build when you try
to
submit a
plugin they error out if you are missing some fields that they
require.
On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan
gorkem.er...@gmail.com
wrote:
+1 for adding metadata but should more of the metadata be
compulsory?
JBoss tools plugin discovery uses the cordova.io registry and
some
of
the
plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a
screenshot
that shows how the case. http://snag.gy/J8rl6.jpg is a
screenshot
of
a
few
plugins that has most of its data. As you can see with the
missing
descriptions etc. it is not possible to do an informed decision
on
whether
to use a plugin or not. Although information such as keywords
does
not
seem
like important it becomes quite useful when you are trying to
find
a
certain plugin.
--
Gorkem
On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny
mmo...@chromium.org
wrote:
+1 to repo / issue / website / docs etc metadata
-1 *for now* to dependencies at specific versions, and testing
related
changes like mode, just because its not clear
Cordova Issue Workflow
Google https://www.google.ca/?q=cordova+issue+workflow tells me that there's a ContributorWorkflow: http://wiki.apache.org/cordova/ContributorWorkflow But: 1. Creating/finding an issue is buried in text in the middle of the About Commit Messages -- that can't possibly be where one creates or finds a bug in anyone's actual workflow. 2. It doesn't say how/when issues are updated. 3. It doesn't say if one should try to have an issue assigned if they're working on it. 4. Review Board is a tool for committers to review each others' changes. As a contributor generally you won't use Review Board - the pull request should be sufficient. -- There's no link to review board. 5. It doesn't explain the Version fields (found/fixed) -- neither who should fill them out/according to whatŠ 6. It doesn't explain how an issue should be resolved / what steps should be taken. There seems to be a difference between something being Fixed and something being Resolved. - 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.
Wiki permission
Could someone please add JoshSoref to the list of accounts able to edit the wikiŠ - 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.
update jasmine-node form 1.8.x to 1.11.x for cordova-cli?
I notice that there is a new version of jasmine-node 1.11.0 [1] I tested with 1.11.0 today and didn't find problems at the surface. It is OK to update the dependency to use the new version? [1] https://npmjs.org/package/jasmine-node -- Carlos Santana csantan...@gmail.com
Review Request 14822: CB-5125 add tests for chil process spawn
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14822/ --- Review request for cordova. Repository: cordova-cli Description --- CB-5125 add tests for chil process spawn CB-5125: replace child process exec with spawn Diffs - spec/compile.spec.js 3b0fe0d0e9d399b57d4d632838e0e88e8fb2f35d spec/emulate.spec.js 79b5176b145b3b1535747bbce8d6973d45abb58c spec/run.spec.js 7d13a969459581a637ba026826af11c388d5bbb7 src/compile.js 34c24fe8e66d477d74728e018c250cf5e267c351 src/emulate.js cd4c038a3c2125224d25715a3fc2cf3b9e9f3cb0 src/run.js dddc1fc6f7a168267decdb3f6d8c4471d3480893 Diff: https://reviews.apache.org/r/14822/diff/ Testing --- Thanks, Carlos Santana
Re: Review Request 14793: CB-5125: replace child process exec with spawn
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/#review27272 --- I added test cases here: https://reviews.apache.org/r/14822/ - Carlos Santana On Oct. 21, 2013, 6:49 p.m., Carlos Santana wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14793/ --- (Updated Oct. 21, 2013, 6:49 p.m.) Review request for cordova. Repository: cordova-cli Description --- CB-5125: replace child process exec with spawn This avoid stdout from platform scripts kill exec process because goes over maxBuffer (~200KB) Also this give immediate feedback to user on the cli, any output from platform script doesn't get buffer it gets passed to event emmiter Diffs - src/compile.js 34c24fe8e66d477d74728e018c250cf5e267c351 src/emulate.js cd4c038a3c2125224d25715a3fc2cf3b9e9f3cb0 src/run.js dddc1fc6f7a168267decdb3f6d8c4471d3480893 Diff: https://reviews.apache.org/r/14793/diff/ Testing --- Tested Android, iOS (mac osx) node 0.10.18 Thanks, Carlos Santana
