Re: Upgrading Guides
That looks good Benn. The upgrading docs should look almost identical across platforms, and I think you've started it well (the big bold note about having to add the old core apis as plugins now). A few things that I think need doing for those docs to be complete: - Plugins need READMEs. I imagine most of them will look identical other than particular ids and file references. Instructions on how to install the plugin manually, with plugman, and with cordova-cli should be provided in there. - Link to the plugins in the upgrading guides, from there users can look at the readmes to install them. - The upgrading with cordova cli section can then be expanded with specific commands to run to install all of the core plugins and get the same app state as in pre-3.0. Maybe add notes to encourage the user to think about which apis are really necessary for them in their app. Let me know how that sounds folks and I can add that to the windows phone upgrading guide. From there the other platforms can follow suit with the same general upgrading notes. On 7/15/13 8:15 PM, Benn Mapes benn.ma...@gmail.com wrote: There is a document that talks about the cordova-cli : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/cli/ index.md But I don't see any mention of how to install the core plugins (or any plugins...) For the windows phone upgrade guides I did something like this : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/plat forms/wp8/upgrading.md But I feel we might need a little bit more elaboration on this. On Mon, Jul 15, 2013 at 6:58 PM, Shazron shaz...@gmail.com wrote: What's the story here? I assume we all have a common one, in that we require the user to install cordova-cli through npm, etc and instruct them on how to add the core plugins using this tool. Have I missed a doc somewhere already written? (probably)
Re: Post 3.0 release committer and community meeting
Count me in for the hangouts etc. On Tue, Jul 16, 2013 at 12:22 AM, Ken Wallis kwal...@blackberry.com wrote: Definitely a good idea. Sent from my BlackBerry 10 smartphone. From: Brian LeRoux Sent: Monday, July 15, 2013 5:45 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Post 3.0 release committer and community meeting Hey everyone, we're in the final stretch to releasing 3.0 and I think long past due to have an open discussion w/ the committership and larger community. I think we should let the dust settle from 3.0 for a couple of weeks before having this meeting. I'd like to propose the week of August 12th. If that all sounds good, we could setup a Google Hangout, and get an agenda started: - release artifacts and process redux - 4.0 goals, timeline, and priorities Comments pls! - 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: Plugin packages on Android
What or where exactly is the deprecation policy? It's probably not semverhttp://semver.org/, because breaking changes need a major version update in semver. Hence, breaking these plugins would require 4.0, not 3.1. But I guess this is just not how you have set it up. On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve agri...@chromium.org wrote: On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux b...@brian.io wrote: A package namespace is not a part of the API? Are we saying we in Cordova draw the semantic line at a method signature? (Its certainly not a normal view on what defines an API. Anyhow! Super not important.) One more time! Specifics. What packages are changing in precisely what files? Right now we're discussing a completely undefined scope in light of an obviously standard best practice. On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve agri...@chromium.org wrote: -1 to shims. A plugin's java package name shouldn't be considered a part of its API. That's why there is a mapping in the config.xml. Shouldn't have to change any require() statements, or any JS at all. Those use plugin IDs, not java namespaces. Replace-all on the package statement at the top of the file, and change the reference in plugin.xml. I'd put this change in the polish category. That's what we should be doing now, no? ^^ this is the specifics. pkg stmts for plugin files + refs in plugin.xml. This is different from the phonegap-cordova change because a) no core files are changed and b) we've already changed the pkg name by adding .core On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj f...@adobe.com wrote: +1 wait until 3.1. +1 add shims for less breakage Also worth pointing out that we'll need to add this to the deprecation list on the wiki On 7/15/13 11:30 AM, Simon MacDonald simon.macdon...@gmail.com wrote: The reason things broke back then was we didn't leave in shims to point anyone compiling against com.phonegap.api to org.apache.cordova.api. That was quickly corrected. I agree with the package name change but with 3.0 shipping this week(?). It should probably wait until the next version. Simon Mac Donald http://hi.im/simonmacdonald On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux b...@brian.io wrote: No. You are proposing an API change. A package is most certainly a part of the API! When we moved from `com.phonegap` to `org.apache` there was a huge outcry b/c it broke all existing community plugins. I'm completely open to changing stuff for 3.0 but, again, what specifically are you proposing we change? On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com wrote: I agree. The only downside I see is that it will be hard to dissociate core plugins from other but I don't think it's really that important. Also because it's not a giant change it could happen for 3.0. On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren m...@chromium.org wrote: I'm not proposing any API changes in this email; example (1) does mention the relocation of FileHelper.java, but that's more to illustrate the benefits of repackaging the plugins. I would think the plugin package change should happen *for* 3.0, before people actually start using the plugins all bundled in one package. It's not a giant change. On Mon, Jul 15, 2013 at 1:16 PM, Brian LeRoux b...@brian.io wrote: I think all of this makes good sense but will have to land sometime post 3.0 as that we're pretty much in the final stretch now anyhow. Which APIs are you specifically proposing we change? On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren m...@chromium.org wrote: On Android, all Cordova plugins are in the package org.apache.cordova.core. It makes sense to put each plugin into its own package. Aside from 3.0's conceptual shift into plugins as completely individual entities and the fact that plugins aren't really core, here's some rationale: 1. If two plugins have a file with the same name, we'll avoid collisions. For instance, core Cordova has FileHelper.java. This is the wrong place for it in 3.0 and we'd like to move it to the plugins that use it (removing unused methods in each plugin's version). However, this will lead to a collision in apps that use two of these plugins, since they'll both be in the same package. 2. All plugin files will be separated into their packages in your IDE. This makes working on an individual plugin easier‹you can see the associated files at a glance. If I'm
Re: Post 3.0 release committer and community meeting
Sounds good On 7/16/13 12:10 AM, David Pfahler da...@excellenteasy.com wrote: Count me in for the hangouts etc. On Tue, Jul 16, 2013 at 12:22 AM, Ken Wallis kwal...@blackberry.com wrote: Definitely a good idea. Sent from my BlackBerry 10 smartphone. From: Brian LeRoux Sent: Monday, July 15, 2013 5:45 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Post 3.0 release committer and community meeting Hey everyone, we're in the final stretch to releasing 3.0 and I think long past due to have an open discussion w/ the committership and larger community. I think we should let the dust settle from 3.0 for a couple of weeks before having this meeting. I'd like to propose the week of August 12th. If that all sounds good, we could setup a Google Hangout, and get an agenda started: - release artifacts and process redux - 4.0 goals, timeline, and priorities Comments pls! - 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: Plugin packages on Android
We definitely do not follow semver http://wiki.apache.org/cordova/DeprecationPolicy On 7/16/13 12:15 AM, David Pfahler da...@excellenteasy.com wrote: What or where exactly is the deprecation policy? It's probably not semverhttp://semver.org/, because breaking changes need a major version update in semver. Hence, breaking these plugins would require 4.0, not 3.1. But I guess this is just not how you have set it up. On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve agri...@chromium.org wrote: On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux b...@brian.io wrote: A package namespace is not a part of the API? Are we saying we in Cordova draw the semantic line at a method signature? (Its certainly not a normal view on what defines an API. Anyhow! Super not important.) One more time! Specifics. What packages are changing in precisely what files? Right now we're discussing a completely undefined scope in light of an obviously standard best practice. On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve agri...@chromium.org wrote: -1 to shims. A plugin's java package name shouldn't be considered a part of its API. That's why there is a mapping in the config.xml. Shouldn't have to change any require() statements, or any JS at all. Those use plugin IDs, not java namespaces. Replace-all on the package statement at the top of the file, and change the reference in plugin.xml. I'd put this change in the polish category. That's what we should be doing now, no? ^^ this is the specifics. pkg stmts for plugin files + refs in plugin.xml. This is different from the phonegap-cordova change because a) no core files are changed and b) we've already changed the pkg name by adding .core On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj f...@adobe.com wrote: +1 wait until 3.1. +1 add shims for less breakage Also worth pointing out that we'll need to add this to the deprecation list on the wiki On 7/15/13 11:30 AM, Simon MacDonald simon.macdon...@gmail.com wrote: The reason things broke back then was we didn't leave in shims to point anyone compiling against com.phonegap.api to org.apache.cordova.api. That was quickly corrected. I agree with the package name change but with 3.0 shipping this week(?). It should probably wait until the next version. Simon Mac Donald http://hi.im/simonmacdonald On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux b...@brian.io wrote: No. You are proposing an API change. A package is most certainly a part of the API! When we moved from `com.phonegap` to `org.apache` there was a huge outcry b/c it broke all existing community plugins. I'm completely open to changing stuff for 3.0 but, again, what specifically are you proposing we change? On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI anis.ka...@gmail.com wrote: I agree. The only downside I see is that it will be hard to dissociate core plugins from other but I don't think it's really that important. Also because it's not a giant change it could happen for 3.0. On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren m...@chromium.org wrote: I'm not proposing any API changes in this email; example (1) does mention the relocation of FileHelper.java, but that's more to illustrate the benefits of repackaging the plugins. I would think the plugin package change should happen *for* 3.0, before people actually start using the plugins all bundled in one package. It's not a giant change. On Mon, Jul 15, 2013 at 1:16 PM, Brian LeRoux b...@brian.io wrote: I think all of this makes good sense but will have to land sometime post 3.0 as that we're pretty much in the final stretch now anyhow. Which APIs are you specifically proposing we change? On Mon, Jul 15, 2013 at 9:14 AM, Max Woghiren m...@chromium.org wrote: On Android, all Cordova plugins are in the package org.apache.cordova.core. It makes sense to put each plugin into its own package. Aside from 3.0's conceptual shift into plugins as completely individual entities and the fact that plugins aren't really core, here's some rationale: 1. If two plugins have a file with the same name, we'll avoid collisions. For instance, core Cordova has FileHelper.java. This is the wrong place for it in 3.0 and we'd like to move it to the plugins that use it (removing unused methods in each plugin's version). However, this will lead to a collision in apps that use two of these plugins, since they'll both be in the same package. 2. All plugin files will be separated into their packages in
Re: Post 3.0 release committer and community meeting
Sensible timezone for Asia/Aus please :) On Tue, Jul 16, 2013 at 4:22 PM, Filip Maj f...@adobe.com wrote: Sounds good On 7/16/13 12:10 AM, David Pfahler da...@excellenteasy.com wrote: Count me in for the hangouts etc. On Tue, Jul 16, 2013 at 12:22 AM, Ken Wallis kwal...@blackberry.com wrote: Definitely a good idea. Sent from my BlackBerry 10 smartphone. From: Brian LeRoux Sent: Monday, July 15, 2013 5:45 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Post 3.0 release committer and community meeting Hey everyone, we're in the final stretch to releasing 3.0 and I think long past due to have an open discussion w/ the committership and larger community. I think we should let the dust settle from 3.0 for a couple of weeks before having this meeting. I'd like to propose the week of August 12th. If that all sounds good, we could setup a Google Hangout, and get an agenda started: - release artifacts and process redux - 4.0 goals, timeline, and priorities Comments pls! - 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. -- http://www.wizcorp.jp/Ally Ogilvie Lead Developer - MobDev. | Wizcorp Inc. http://www.wizcorp.jp/ -- TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Websitehttp://www.wizcorp.jp/ | Twitter https://twitter.com/Wizcorp | Facebookhttp://www.facebook.com/Wizcorp | LinkedIn http://www.linkedin.com/company/wizcorp
Re: 3.0.0 Testing thread
I keep getting invalid version 3.0.0rc1 on plugman. :( On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: Upgrading Guides
The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. On Tue, Jul 16, 2013 at 2:50 AM, Filip Maj f...@adobe.com wrote: That looks good Benn. The upgrading docs should look almost identical across platforms, and I think you've started it well (the big bold note about having to add the old core apis as plugins now). A few things that I think need doing for those docs to be complete: - Plugins need READMEs. I imagine most of them will look identical other than particular ids and file references. Instructions on how to install the plugin manually, with plugman, and with cordova-cli should be provided in there. I don't think we want to tell them how to install the plugin manually. What would that even look like? - Link to the plugins in the upgrading guides, from there users can look at the readmes to install them. - The upgrading with cordova cli section can then be expanded with specific commands to run to install all of the core plugins and get the same app state as in pre-3.0. Maybe add notes to encourage the user to think about which apis are really necessary for them in their app. Let me know how that sounds folks and I can add that to the windows phone upgrading guide. From there the other platforms can follow suit with the same general upgrading notes. On 7/15/13 8:15 PM, Benn Mapes benn.ma...@gmail.com wrote: There is a document that talks about the cordova-cli : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/cli/ index.md But I don't see any mention of how to install the core plugins (or any plugins...) For the windows phone upgrade guides I did something like this : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/plat forms/wp8/upgrading.md But I feel we might need a little bit more elaboration on this. On Mon, Jul 15, 2013 at 6:58 PM, Shazron shaz...@gmail.com wrote: What's the story here? I assume we all have a common one, in that we require the user to install cordova-cli through npm, etc and instruct them on how to add the core plugins using this tool. Have I missed a doc somewhere already written? (probably)
Re: 3.0.0 Testing thread
https://issues.apache.org/jira/browse/CB-4264 Turns out it was a false positive failure, the test needs to be improved. But so far all systems go for iOS. On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: 3.0.0 Testing thread
Changing to 3.0.0-rc1 might do the trick. On Tue, Jul 16, 2013 at 9:31 AM, Joe Bowser bows...@gmail.com wrote: I'm running the latest. The issue was with the use of semver. The version template must return a valid semver version, which 3.0.0rc1 is not. On Tue, Jul 16, 2013 at 6:22 AM, Shazron shaz...@gmail.com wrote: Hmm I'm running plugman 0.9.1 - what version did you run Joe On Tue, Jul 16, 2013 at 6:20 AM, Joe Bowser bows...@gmail.com wrote: I keep getting invalid version 3.0.0rc1 on plugman. :( On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: 3.0.0 Testing thread
Has anyone managed to get plugman to uninstall a plugin? The dependencies plugin never cleanly installs or uninstalls. On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote: https://issues.apache.org/jira/browse/CB-4264 Turns out it was a false positive failure, the test needs to be improved. But so far all systems go for iOS. On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: 3.0.0 Testing thread
I'm using the master version of the cordova-cli, installing a plugin is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir, id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1
test
failing:
File API DirectoryReader interface readEntries file.spec.109 should
return
an empty entry list on the second call.
Expected 0 not to be 0.
To confirm
To confirm that you would like shirleya.fu...@gmail.com added to the dev mailing list, please send a short reply to this address: dev-sc.1373960447.iohjpbmggoobjdlomiio-shirleya.fui26= gmail@cordova.apache.org
Re: 3.0.0 Testing thread
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one wont put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a plugin is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir, id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1
test
failing:
File API DirectoryReader interface readEntries file.spec.109 should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: 3.0.0 Testing thread
I installed plugman 0.9.6 before using cordova-cli from master, and that is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one wont put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a plugin is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir, id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS, with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109 should
return
an empty entry list on the second call.
Expected 0 not to be 0.
New iOS 7 UI and backwards compatibility
Hi, I haven't found any discussion about this searching through my mail. But the UI is broken in iOS 7. I actually don't know if I'm allowed to discuss the details. It's glaringly obvious, though, and it makes compatibility with iOS 6 somewhat of a chore for cordova-based apps, especially with the position splash screen unless I'm mistaken. So, before I go hacking around with our view controller to accommodate both 6 7, has this been taken care of already, and I'm just overlooking it? We're trying to get an app out the door as soon as iOS 7 launches. Thanks, PJ Dillon Sulia, Inc
Re: 3.0.0 Testing thread
Found and filed an issue with FileTransfer. The new
CordovaResourceApi changes broke FileTransfer. That needs to get
fixed ASAP before we can do a tag with our current way of doing
things. :S
On Tue, Jul 16, 2013 at 7:50 AM, Shazron shaz...@gmail.com wrote:
I installed plugman 0.9.6 before using cordova-cli from master, and that is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one wont put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a plugin is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir, id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS, with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109 should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: 3.0.0 Testing thread
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which version ) and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com wrote:
I installed plugman 0.9.6 before using cordova-cli from master, and that is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a plugin is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir, id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: 3.0.0 Testing thread
I pointed plugman to cordova-plugman/main.js (all latest from the repo) and
it still shows the same error.
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one wont put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a plugin is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir, id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS, with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109 should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: New iOS 7 UI and backwards compatibility
There have been no splash screen fixes since 2.9.0 that I'm aware of. Please file a bug on our jira:https://issues.apache.org/jira/browse/CB On Tue, Jul 16, 2013 at 10:56 AM, PJ Dillon p...@sulia.com wrote: Hi, I haven't found any discussion about this searching through my mail. But the UI is broken in iOS 7. I actually don't know if I'm allowed to discuss the details. It's glaringly obvious, though, and it makes compatibility with iOS 6 somewhat of a chore for cordova-based apps, especially with the position splash screen unless I'm mistaken. So, before I go hacking around with our view controller to accommodate both 6 7, has this been taken care of already, and I'm just overlooking it? We're trying to get an app out the door as soon as iOS 7 launches. Thanks, PJ Dillon Sulia, Inc
Re: 3.0.0 Testing thread
I'm getting 5 tests failing, all with the File API:
file.spec.104 - File API FileWriter should be able to write binary
data from an ArrayBuffer
file.spec.105 - File API FileWriter should be able to write binary
data from a Blob
file.spec.106 - File API FileWriter should be able to write a File to
a FileWriter
file.spec.107 - File API FileWriter should be able to write a sliced
File to a FileWriter
file.spec.108 - File API FileWriter should be able to write binary
data from a File
I think these are all related to the recent Resource API work,
correct? I do remember these passing earlier in the week.
On Tue, Jul 16, 2013 at 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a bug when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which version ) and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com wrote:
I installed plugman 0.9.6 before using cordova-cli from master, and that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found. Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: New iOS 7 UI and backwards compatibility
Yeah... NDA and all that jazz. Technically, the Apple Dev Forums would be the proper place to discuss the issue, though you have to put up with PG-haters and conflicting posts that then tell you to talk to PG and not the forum. (These posts are not by Apple, just by other Devs on the forum, so I take their opinion with a grain of salt, since they are almost always the uninformed-about-what-PG type, IMO) I would do a search on the forums on how to handle splashes on multiple iOS versions (though I think you will end up with a second splash being generated from PG - not sure ATM how to address that easily), as well has how to deal with the status bar issue. There is some pretty simple code that should at least get you back to iOS 6-style metrics. Finally, based only on past experience, support for the newest iOS release is a couple weeks or longer after Apple has released it. No one can offer support for beta OSes, and things can and do break across beta versions. The GM release may not provide enough time to get a iOS 7-supported PG out the door by release date. My point being that it may be better to muck around in your view controller to support what you need now, if you need to release the day of the iOS 7 release. Just make sure to take a backup or use version control so that if you muck a bit too far, you can get back easily. Sent from my phone. ___ Kerri Shotts photoKandy Studios, LLC On the Web: http://www.photokandy.com/ Social Media: Twitter: @photokandy, http://twitter.com/photokandy Tumblr: http://photokandy.tumblr.com/ Github: https://github.com/kerrishotts https://github.com/organizations/photokandyStudios CoderWall: https://coderwall.com/kerrishotts Apps on the Apple Store: https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 Books: http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book http://www.packtpub.com/phonegap-social-app-development/book On Jul 16, 2013, at 9:56, PJ Dillon p...@sulia.com wrote: Hi, I haven't found any discussion about this searching through my mail. But the UI is broken in iOS 7. I actually don't know if I'm allowed to discuss the details. It's glaringly obvious, though, and it makes compatibility with iOS 6 somewhat of a chore for cordova-based apps, especially with the position splash screen unless I'm mistaken. So, before I go hacking around with our view controller to accommodate both 6 7, has this been taken care of already, and I'm just overlooking it? We're trying to get an app out the door as soon as iOS 7 launches. Thanks, PJ Dillon Sulia, Inc
Re: New iOS 7 UI and backwards compatibility
Would help if I paid attention to which group things are in... ;) thought it was in the main forum for some reason (not enough caffeine). Do file bugs; filing bugs is pretty safe (since how else can devs fix issues related to iOS7.) That said, I would still expect the support to be an issue, since something could easily break in beta 4. In fact people on the forums have been complaining about breaks between beta 2 and 3. Also, do search the forums for the status bar piece (unless that has been dealt with in 2.9.0/3.0) since there is a really simple line of code you can add to get back to iOS6 metrics. (Side note: clearly Apple wants us to go this new direction, so whether or not PG should even build this in by default is debatable in my opinion. We all, native and non-native devs alike have to live in this new world and adjust our UI to reflect what makes sense here for each app. Perhaps a config.xml setting might be useful, though, although it should be equally doable in JS/CSS/HTML to do the required changes. Do note that this is not just a hardship faced by us: all native devs are also having to take a hard look at their app and statistics to see if supporting iOS 6 and 7 is feasible or not, and judging from the forum, a large number are going iOS7 only. ) Sent from my phone. ___ Kerri Shotts photoKandy Studios, LLC On the Web: http://www.photokandy.com/ Social Media: Twitter: @photokandy, http://twitter.com/photokandy Tumblr: http://photokandy.tumblr.com/ Github: https://github.com/kerrishotts https://github.com/organizations/photokandyStudios CoderWall: https://coderwall.com/kerrishotts Apps on the Apple Store: https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 Books: http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book http://www.packtpub.com/phonegap-social-app-development/book On Jul 16, 2013, at 10:14, Andrew Grieve agri...@chromium.org wrote: There have been no splash screen fixes since 2.9.0 that I'm aware of. Please file a bug on our jira:https://issues.apache.org/jira/browse/CB On Tue, Jul 16, 2013 at 10:56 AM, PJ Dillon p...@sulia.com wrote: Hi, I haven't found any discussion about this searching through my mail. But the UI is broken in iOS 7. I actually don't know if I'm allowed to discuss the details. It's glaringly obvious, though, and it makes compatibility with iOS 6 somewhat of a chore for cordova-based apps, especially with the position splash screen unless I'm mistaken. So, before I go hacking around with our view controller to accommodate both 6 7, has this been taken care of already, and I'm just overlooking it? We're trying to get an app out the door as soon as iOS 7 launches. Thanks, PJ Dillon Sulia, Inc
Is a config.xml without an author valid?
When the config.xml for mobile-spec was re-written recently the author element was removed and I'm just wondering if this is valid. In the BlackBerry implementation we've always required one and I'm wondering if this behaviour is wrong, or if I should add one to mobile-spec. Thanks, Jeff - 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: Is a config.xml without an author valid?
I think it should be necessary but we never got that far in terms of validating config.xml or anything like that On 7/16/13 8:38 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: When the config.xml for mobile-spec was re-written recently the author element was removed and I'm just wondering if this is valid. In the BlackBerry implementation we've always required one and I'm wondering if this behaviour is wrong, or if I should add one to mobile-spec. Thanks, Jeff - 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: 3.0.0 Testing thread
Yes, when you clone down either of the tools, ALWAYS run `npm install` in
its directory to reinitialize the dependencies. Even when just updating
the code for the tools, run `npm install` just in case in case the deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com wrote:
I installed plugman 0.9.6 before using cordova-cli from master, and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com wrote:
I'm using the master version of the cordova-cli, installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
RE: Upgrading Guides
FYI: I split the Upgrading Guide into more digestible platform-specific docs available under Platform Guides (edge/guide/platforms/*/upgrading.md). I haven't yet scrutinized whether the content is still relevant, but that's a good idea to note the CLI-based workflow. For now I'll link the CLI guide from from each as applicable. (Slightly complicated b/c not all platforms are supported by CLI.) --Mike S From: Shazron [shaz...@gmail.com] Sent: Monday, July 15, 2013 9:58 PM To: dev@cordova.apache.org Subject: Upgrading Guides What's the story here? I assume we all have a common one, in that we require the user to install cordova-cli through npm, etc and instruct them on how to add the core plugins using this tool. Have I missed a doc somewhere already written? (probably)
Re: 3.0.0 Testing thread
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin doesn't use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm install` in
its directory to reinitialize the dependencies. Even when just updating
the code for the tools, run `npm install` just in case in case the deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com wrote:
I installed plugman 0.9.6 before using cordova-cli from master, and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli, installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform, project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir, plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: Upgrading Guides
What Andrew said - I would think us documenting the CLI way would be adequate Will there be people that only work on one platform and want to use plugman on its own in their existing project structure? Yes, we just point them to the plugman docs I suppose. The upgrading document is great Benn, thanks! However, I feel it is incomplete (speaking for iOS) for the majority of our users. They have no clue on how to install the core plugins, we have to either add explicit instructions on how to add a core plugin based on the release tarball (which will include the core plugins as source), or just install from the canonical git repo URL (not sure about plugin discovery by name here?) It's should be a separate doc maybe, but there could be a guide on how to upgrade from a non-CLI structured project to a CLI structured one. On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. On Tue, Jul 16, 2013 at 2:50 AM, Filip Maj f...@adobe.com wrote: That looks good Benn. The upgrading docs should look almost identical across platforms, and I think you've started it well (the big bold note about having to add the old core apis as plugins now). A few things that I think need doing for those docs to be complete: - Plugins need READMEs. I imagine most of them will look identical other than particular ids and file references. Instructions on how to install the plugin manually, with plugman, and with cordova-cli should be provided in there. I don't think we want to tell them how to install the plugin manually. What would that even look like? - Link to the plugins in the upgrading guides, from there users can look at the readmes to install them. - The upgrading with cordova cli section can then be expanded with specific commands to run to install all of the core plugins and get the same app state as in pre-3.0. Maybe add notes to encourage the user to think about which apis are really necessary for them in their app. Let me know how that sounds folks and I can add that to the windows phone upgrading guide. From there the other platforms can follow suit with the same general upgrading notes. On 7/15/13 8:15 PM, Benn Mapes benn.ma...@gmail.com wrote: There is a document that talks about the cordova-cli : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/cli/ index.md But I don't see any mention of how to install the core plugins (or any plugins...) For the windows phone upgrade guides I did something like this : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/plat forms/wp8/upgrading.md But I feel we might need a little bit more elaboration on this. On Mon, Jul 15, 2013 at 6:58 PM, Shazron shaz...@gmail.com wrote: What's the story here? I assume we all have a common one, in that we require the user to install cordova-cli through npm, etc and instruct them on how to add the core plugins using this tool. Have I missed a doc somewhere already written? (probably)
Re: 3.0.0 Testing thread
I'm testing on the HTC One running stock 4.2.2. The Google one without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org wrote:
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin doesn't use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm install` in
its directory to reinitialize the dependencies. Even when just updating
the code for the tools, run `npm install` just in case in case the deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com wrote:
I installed plugman 0.9.6 before using cordova-cli from master, and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli, installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in the
dependencies-plugin on cordova-mobile-spec) on master for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries
file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
cordova-cli platform remove/platform add causes subsequent plugin remove/ plugin add to fail
if you need to replace/update a platform in your mobilespec project, the sequence - cordova platform remove android - cordova platform add android - cordova plugin remove org.cordova.mobile-spec-dependencies - cordova plugin add ../cordova-mobile-spec/dependencies-plugin will not work correctly. instead use: - cordova platform remove android - cordova plugin remove org.cordova.mobile-spec-dependencies - cordova platform add android - cordova plugin add ../cordova-mobile-spec/dependencies-plugin Since platform add attempts to preserve plugins, but does it incorrectly, I created a bug for this: https://issues.apache.org/jira/browse/CB-4275
Re: Bash command-line completion for CLI
On Mon, Jul 15, 2013 at 4:19 PM, Carlos Santana csantan...@gmail.comwrote: Sweet ! I was thinking on doing this also. Thanks! I saved it as a gist for now. I also have the same for git commands if someone is interested https://gist.github.com/csantanapr I see that the one I have for git use complete -o default -o nospace -F Ian Do you know what - default and - nospace add to the mix, I tried to google couldn't figure it out. -o nospace tells complete not to put a space at the end of the completed word -- I actually need to do that on directory completion for cordova.completion. -o default tells complete to use filenames from the current directory if it can't generate any completions. (Technically, -o default means to delegate to the readline library to supply completions, and readline looks for matching filenames) Ian --Carlos On Mon, Jul 15, 2013 at 2:44 PM, Filip Maj f...@adobe.com wrote: Thanks Ian! Make that three beers coming your way On 7/15/13 9:42 AM, Brian LeRoux b...@brian.io wrote: Oh this rules, thanks so much Ian, I'll add to those beers! On Mon, Jul 15, 2013 at 9:33 AM, Michael Brooks mich...@michaelbrooks.ca wrote: Beautiful Ian! This has been on my backlog of tasks, so I'm happy to see that you've spearheaded it. I'll give the completion and shot and see how it works. I'll also buy you a beer if you're coming to Portland this week! Michael On Mon, Jul 15, 2013 at 7:59 AM, Ian Clelland iclell...@chromium.orgwrote: Thanks, guys! Let me know what's broken :) Ian On Mon, Jul 15, 2013 at 8:52 AM, Lucas Holmquist lholm...@redhat.com wrote: coolio, i will be trying this On Jul 15, 2013, at 1:06 AM, Kerri Shotts kerrisho...@gmail.com wrote: Nice! I'll definitely be trying it out on my system! ___ Kerri Shotts photoKandy Studios, LLC On the Web: [http://www.photokandy.com/: http://www.photokandy.com/] Social Media: Twitter: @photokandy, [http://twitter.com/photokandy: http://twitter.com/photokandy] Tumblr: [http://photokandy.tumblr.com/: http://photokandy.tumblr.com/] Github: [https://github.com/kerrishotts: https://github.com/kerrishotts] [https://github.com/organizations/photokandyStudios: https://github.com/organizations/photokandyStudios] CoderWall: [https://coderwall.com/kerrishotts: https://coderwall.com/kerrishotts] Apps on the Apple Store: [https://itunes.apple.com/us/artist/photokandy-studios- llc/id498577828: https://itunes.apple.com/us/artist/photokandy- studios-llc/id498577828] Books: [http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book: http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book] [http://www.packtpub.com/phonegap-social-app-development/book: http://www.packtpub.com/phonegap-social-app-development/book] So, after spending two days typing out cordova-cli command lines by hand (nice long ones like cordova plugin rm org.apache.cordova.core.file-transfer, mostly), I finally broke down and added proper completion for my shell. I've created a JIRA issue to hold the code, as a New Feature ticket. I'm not planning on committing anything like this until it's had a bit wider exposure, if people find it useful. I've been using it daily since writing it, and a few others here have tried it, and their feedback has made it more useful and stable. It's CB-4200, if anybody wants to try it. Source it in your .bashrc file on OS X, or add it to /etc/bash_completion.d on debian-based systems. Ian -- Carlos Santana csantan...@gmail.com
Re: 3.0.0 Testing thread
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org wrote:
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm install`
in
its directory to reinitialize the dependencies. Even when just updating
the code for the tools, run `npm install` just in case in case the deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com
wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which version
)
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from master,
and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli, installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin? The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test
needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron
shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in
the
dependencies-plugin on cordova-mobile-spec) on master for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries
file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
3.0.0 as a beta release?
As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Re: 3.0.0 as a beta release?
This is why I'm upgrading from 2.5 to 2.9 now. On Tue, Jul 16, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Re: cordova-cli platform remove/platform add causes subsequent plugin remove/ plugin add to fail
Thx for filing On 7/16/13 10:22 AM, David Kemp drk...@google.com wrote: if you need to replace/update a platform in your mobilespec project, the sequence - cordova platform remove android - cordova platform add android - cordova plugin remove org.cordova.mobile-spec-dependencies - cordova plugin add ../cordova-mobile-spec/dependencies-plugin will not work correctly. instead use: - cordova platform remove android - cordova plugin remove org.cordova.mobile-spec-dependencies - cordova platform add android - cordova plugin add ../cordova-mobile-spec/dependencies-plugin Since platform add attempts to preserve plugins, but does it incorrectly, I created a bug for this: https://issues.apache.org/jira/browse/CB-4275
Re: 3.0.0 Testing thread
Okay, seems it was a bad rebase when Ian made the base64 change. Will be
fixed shortly. Weird that these would pass at all for anyone in the past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org wrote:
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com
wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from master,
and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli, installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin?
The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test
needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron
shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified in
the
dependencies-plugin on cordova-mobile-spec) on master
for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries
file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: 3.0.0 as a beta release?
Unfortunately, any .0 release of PhoneGap/Cordova in the past had major bugs and hick ups for me, so my policy is to wait for the (obligatory) .1 release. I would welcome it a lot if we could be a little more humble about the releases and call it a beta, release the beta officially and see what problems people have with it. 3.0 should be a stable, ready-for-production release. On Tue, Jul 16, 2013 at 7:43 PM, David Lewis lewi...@gmail.com wrote: This is why I'm upgrading from 2.5 to 2.9 now. On Tue, Jul 16, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Documenting Plugin Spec
Currently exists in the plugman repo. Should we set up a sub guide under cordova-docs plugin guides?
Re: Bash command-line completion for CLI
Thanks Ian for the explanation On Tue, Jul 16, 2013 at 1:24 PM, Ian Clelland iclell...@chromium.orgwrote: On Mon, Jul 15, 2013 at 4:19 PM, Carlos Santana csantan...@gmail.com wrote: Sweet ! I was thinking on doing this also. Thanks! I saved it as a gist for now. I also have the same for git commands if someone is interested https://gist.github.com/csantanapr I see that the one I have for git use complete -o default -o nospace -F Ian Do you know what - default and - nospace add to the mix, I tried to google couldn't figure it out. -o nospace tells complete not to put a space at the end of the completed word -- I actually need to do that on directory completion for cordova.completion. -o default tells complete to use filenames from the current directory if it can't generate any completions. (Technically, -o default means to delegate to the readline library to supply completions, and readline looks for matching filenames) Ian --Carlos On Mon, Jul 15, 2013 at 2:44 PM, Filip Maj f...@adobe.com wrote: Thanks Ian! Make that three beers coming your way On 7/15/13 9:42 AM, Brian LeRoux b...@brian.io wrote: Oh this rules, thanks so much Ian, I'll add to those beers! On Mon, Jul 15, 2013 at 9:33 AM, Michael Brooks mich...@michaelbrooks.ca wrote: Beautiful Ian! This has been on my backlog of tasks, so I'm happy to see that you've spearheaded it. I'll give the completion and shot and see how it works. I'll also buy you a beer if you're coming to Portland this week! Michael On Mon, Jul 15, 2013 at 7:59 AM, Ian Clelland iclell...@chromium.orgwrote: Thanks, guys! Let me know what's broken :) Ian On Mon, Jul 15, 2013 at 8:52 AM, Lucas Holmquist lholm...@redhat.com wrote: coolio, i will be trying this On Jul 15, 2013, at 1:06 AM, Kerri Shotts kerrisho...@gmail.com wrote: Nice! I'll definitely be trying it out on my system! ___ Kerri Shotts photoKandy Studios, LLC On the Web: [http://www.photokandy.com/: http://www.photokandy.com/] Social Media: Twitter: @photokandy, [http://twitter.com/photokandy: http://twitter.com/photokandy] Tumblr: [http://photokandy.tumblr.com/: http://photokandy.tumblr.com/] Github: [https://github.com/kerrishotts: https://github.com/kerrishotts] [https://github.com/organizations/photokandyStudios: https://github.com/organizations/photokandyStudios] CoderWall: [https://coderwall.com/kerrishotts: https://coderwall.com/kerrishotts] Apps on the Apple Store: [https://itunes.apple.com/us/artist/photokandy-studios- llc/id498577828: https://itunes.apple.com/us/artist/photokandy- studios-llc/id498577828] Books: [http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book : http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book ] [http://www.packtpub.com/phonegap-social-app-development/book: http://www.packtpub.com/phonegap-social-app-development/book ] So, after spending two days typing out cordova-cli command lines by hand (nice long ones like cordova plugin rm org.apache.cordova.core.file-transfer, mostly), I finally broke down and added proper completion for my shell. I've created a JIRA issue to hold the code, as a New Feature ticket. I'm not planning on committing anything like this until it's had a bit wider exposure, if people find it useful. I've been using it daily since writing it, and a few others here have tried it, and their feedback has made it more useful and stable. It's CB-4200, if anybody wants to try it. Source it in your .bashrc file on OS X, or add it to /etc/bash_completion.d on debian-based systems. Ian -- Carlos Santana csantan...@gmail.com -- Carlos Santana csantan...@gmail.com
Re: Documenting Plugin Spec
Yes please! On Tue, Jul 16, 2013 at 10:53 AM, Filip Maj f...@adobe.com wrote: Currently exists in the plugman repo. Should we set up a sub guide under cordova-docs plugin guides?
Re: Documenting Plugin Spec
+1 On Tuesday, July 16, 2013, Anis KADRI wrote: Yes please! On Tue, Jul 16, 2013 at 10:53 AM, Filip Maj f...@adobe.com javascript:; wrote: Currently exists in the plugman repo. Should we set up a sub guide under cordova-docs plugin guides?
Can someone reset my password on the WIki?
I tried this link and it never sent me an email https://wiki.apache.org/cordova/ContributorWorkflow?action=recoverpass emails is csantan...@gmail.com for the wiki.apache.org -- Carlos Santana csantan...@gmail.com
Re: 3.0.0 as a beta release?
On Tue, Jul 16, 2013 at 10:38 AM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. We have messaging? I don't think anyone trusts a .0 release ever. Seriously, can you name a .0 release that actually was super polished? The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable There should still be a 3.0 final, IMO - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Anyone who expects a major release to be solid is fooling themselves. I'm going to pick on Android, because it's easy to do so. Android 1.0 had a huge series of hilarious bugs, Android 2.0 was so bad that 2.1 had to be rushed out. 3.0 was so half-baked that it was tablet-only, and 4.0 (ICS) still had numerous issues that weren't fully ironed out until Jellybean (4.1). I will save my comments about this release until after it's out, but I do think that we should release 3.0 as a regular release like we release anything else. As far as the platform code is concerned, it's just as solid, it's the CLI that's still an alpha that needs work.
Re: 3.0.0 as a beta release?
I'm not in favor of of this. The basic flows work. There should be visibility into these perceived issues in the form of blog post. On Tue, Jul 16, 2013 at 10:43 AM, David Lewis lewi...@gmail.com wrote: This is why I'm upgrading from 2.5 to 2.9 now. On Tue, Jul 16, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Re: 3.0.0 as a beta release?
No need to apologize. These labeling semantics are unnecessary and not at all hubris. Wait if you want. We'll just keep shipping code that constantly improves over the last release. On Tue, Jul 16, 2013 at 10:50 AM, David Pfahler da...@excellenteasy.com wrote: Unfortunately, any .0 release of PhoneGap/Cordova in the past had major bugs and hick ups for me, so my policy is to wait for the (obligatory) .1 release. I would welcome it a lot if we could be a little more humble about the releases and call it a beta, release the beta officially and see what problems people have with it. 3.0 should be a stable, ready-for-production release. On Tue, Jul 16, 2013 at 7:43 PM, David Lewis lewi...@gmail.com wrote: This is why I'm upgrading from 2.5 to 2.9 now. On Tue, Jul 16, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Cordova has a Blog/News! Announce 3.0?
The Cordova Blog is live http://cordova.apache.org/#news You can use your RSS reader to subscribe A new blog post needs to be added when cutting a new release The step should be added to the Wiki (but I don't access) https://wiki.apache.org/cordova/CuttingReleases A tasks you be added to the JIRA item for announcing release (but I can't find the JIRA #) I want to thank Andrew with putting up with me on setting up the blog, me being a noob to the Cordova community -- Carlos Santana csantan...@gmail.com
Re: 3.0.0 as a beta release?
I'm hearing .0 releases are always flawed, so it's fine for ours to be too. We should instead try to avoid falling into/perpetuating a pattern that we can all agree is unfortunate. Publicizing this release as beta is a solid step in this direction—the responsibility should be ours to be clear about the state of a release, not the user's to have to be constantly wary. Also, known-issue visibility in blog post form does sound good. On Tue, Jul 16, 2013 at 1:59 PM, Brian LeRoux b...@brian.io wrote: I'm not in favor of of this. The basic flows work. There should be visibility into these perceived issues in the form of blog post. On Tue, Jul 16, 2013 at 10:43 AM, David Lewis lewi...@gmail.com wrote: This is why I'm upgrading from 2.5 to 2.9 now. On Tue, Jul 16, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Re: 3.0.0 as a beta release?
Blog post on rough edges of 3.0 with pointers to the issue tracker is really all we need to do here. I suspect more committers are using IDE's like Eclipse, Xcode, and Android Studio than are web developers building mobile apps. Any other bugs I'm reading for 3.0 are not showstopping from a platform perspective but there are definite revisions needed to be in the plugin user space. That said, we should make sure tests are passing before committing stuff to master so that it doesn't feel so scrambly when we do cut a release. On Tue, Jul 16, 2013 at 11:08 AM, Max Woghiren m...@chromium.org wrote: I'm hearing .0 releases are always flawed, so it's fine for ours to be too. We should instead try to avoid falling into/perpetuating a pattern that we can all agree is unfortunate. Publicizing this release as beta is a solid step in this direction—the responsibility should be ours to be clear about the state of a release, not the user's to have to be constantly wary. Also, known-issue visibility in blog post form does sound good. On Tue, Jul 16, 2013 at 1:59 PM, Brian LeRoux b...@brian.io wrote: I'm not in favor of of this. The basic flows work. There should be visibility into these perceived issues in the form of blog post. On Tue, Jul 16, 2013 at 10:43 AM, David Lewis lewi...@gmail.com wrote: This is why I'm upgrading from 2.5 to 2.9 now. On Tue, Jul 16, 2013 at 1:38 PM, Andrew Grieve agri...@chromium.org wrote: As I'm going through all of the polish details, reading through the upgrade guides, and thinking about API-type things that we'd still like to change, I'm wondering if it would be wise to message 3.0 as an early-adopter or beta release. One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. The beta / early adopter label would mean: - No 3.0 final, we can just go with calling 3.1 stable - User expectations will be that CLI may have bugs or rough edges (e.g. when you remove a platform, any modifications you make will be deleted) (e.g. I don't think there's a way to plugin ls that shows the @src of your plugins - URL+hash+subdir) (e.g. There is no way yet for apps to depend on plugins by adding them to your config.xml typing cordova plugin sync) Usually major releases come with the expectation that they are better more solid worthy of attention. I feel like 3.0 will be more of an alpha in terms of quality / stability of code changing. Thoughts?
Re: 3.0.0 Testing thread
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.orgwrote:
Okay, seems it was a bad rebase when Ian made the base64 change. Will be
fixed shortly. Weird that these would pass at all for anyone in the past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org wrote:
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com
wrote:
I had the same error that you got, but running npm install in the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from master,
and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a plugin?
The
dependencies plugin never cleanly installs or uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test
needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron
shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified
in
the
dependencies-plugin on cordova-mobile-spec) on master
for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries
file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
Re: 3.0.0 Testing thread
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change. Will be
fixed shortly. Weird that these would pass at all for anyone in the past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com
wrote:
I had the same error that you got, but running npm install in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a
plugin?
The
dependencies plugin never cleanly installs or
uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test
needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron
shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified
in
the
dependencies-plugin on cordova-mobile-spec) on
master
for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries
file.spec.109
should
return
an empty entry list on the second call.
Expected 0 not to be 0.
RE: Upgrading Guides
I'll add links to the CLI doc from each Upgrading doc, then expand the CLI doc a bit to discuss in general terms how to upgrade from a non-CLI project. Not familiar with any platform-specific variations, info about which would belong on each platform's Upgrading Guide, but I assume it's basically: create a new project; then move in the assets. And thanks for the nice comment, Andrew. --Mike S From: Shazron [shaz...@gmail.com] Sent: Tuesday, July 16, 2013 12:58 PM To: dev@cordova.apache.org Subject: Re: Upgrading Guides What Andrew said - I would think us documenting the CLI way would be adequate Will there be people that only work on one platform and want to use plugman on its own in their existing project structure? Yes, we just point them to the plugman docs I suppose. The upgrading document is great Benn, thanks! However, I feel it is incomplete (speaking for iOS) for the majority of our users. They have no clue on how to install the core plugins, we have to either add explicit instructions on how to add a core plugin based on the release tarball (which will include the core plugins as source), or just install from the canonical git repo URL (not sure about plugin discovery by name here?) It's should be a separate doc maybe, but there could be a guide on how to upgrade from a non-CLI structured project to a CLI structured one. On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. On Tue, Jul 16, 2013 at 2:50 AM, Filip Maj f...@adobe.com wrote: That looks good Benn. The upgrading docs should look almost identical across platforms, and I think you've started it well (the big bold note about having to add the old core apis as plugins now). A few things that I think need doing for those docs to be complete: - Plugins need READMEs. I imagine most of them will look identical other than particular ids and file references. Instructions on how to install the plugin manually, with plugman, and with cordova-cli should be provided in there. I don't think we want to tell them how to install the plugin manually. What would that even look like? - Link to the plugins in the upgrading guides, from there users can look at the readmes to install them. - The upgrading with cordova cli section can then be expanded with specific commands to run to install all of the core plugins and get the same app state as in pre-3.0. Maybe add notes to encourage the user to think about which apis are really necessary for them in their app. Let me know how that sounds folks and I can add that to the windows phone upgrading guide. From there the other platforms can follow suit with the same general upgrading notes. On 7/15/13 8:15 PM, Benn Mapes benn.ma...@gmail.com wrote: There is a document that talks about the cordova-cli : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/cli/ index.md But I don't see any mention of how to install the core plugins (or any plugins...) For the windows phone upgrade guides I did something like this : https://github.com/apache/cordova-docs/blob/master/docs/en/edge/guide/plat forms/wp8/upgrading.md But I feel we might need a little bit more elaboration on this. On Mon, Jul 15, 2013 at 6:58 PM, Shazron shaz...@gmail.com wrote: What's the story here? I assume we all have a common one, in that we require the user to install cordova-cli through npm, etc and instruct them on how to add the core plugins using this tool. Have I missed a doc somewhere already written? (probably)
Re: 3.0.0 Testing thread
Ok I'm branching 3.0.x and versioning, tagging iOS as 3.0.0rc1 based on my
mobile-spec results (all pass) yesterday.
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.orgwrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change. Will
be
fixed shortly. Weird that these would pass at all for anyone in the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case
the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com
wrote:
I had the same error that you got, but running npm install in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest from
the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a
plugin?
The
dependencies plugin never cleanly installs or
uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the
test
needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron
shaz...@gmail.com
wrote:
So far I went and tested with the plugins
(specified
in
the
dependencies-plugin on cordova-mobile-spec) on
Re: 3.0.0 Testing thread
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change. Will be
fixed shortly. Weird that these would pass at all for anyone in the past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works. It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp drk...@google.com
wrote:
I had the same error that you got, but running npm install in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version, the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a
plugin?
The
dependencies plugin never cleanly installs or
uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the test
needs
to be
improved.
But so far all systems go for iOS.
On Mon, Jul 15, 2013 at 6:54 PM, Shazron
shaz...@gmail.com
wrote:
So far I went and tested with the plugins (specified
in
the
dependencies-plugin on cordova-mobile-spec) on
master
for
iOS,
with
1
test
failing:
File API DirectoryReader interface readEntries
file.spec.109
should
return
an
Re: 3.0.0 Testing thread
On Tue, Jul 16, 2013 at 2:42 PM, Joe Bowser bows...@gmail.com wrote:
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
Yes, no and maybe.
That was the android bridge issue; cordova-js/lib/android/exec.js. It will
be apart of cordova-android as soon as I package up the patched cordova-js
and move it to cordova-android/framework/assets/www.
Ian
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org
wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change. Will
be
fixed shortly. Weird that these would pass at all for anyone in the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case
the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp
drk...@google.com
wrote:
I had the same error that you got, but running npm install
in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron
shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest from
the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version,
the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a
plugin?
The
dependencies plugin never cleanly installs or
uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CB-4264
Turns out it was a false positive failure, the
test
needs
to be
improved.
But so far all systems go
Re: Upgrading Guides
On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: 3.0.0 Testing thread
Wait, we're mixing and matching JS on the RC1 tag? I think we should
re-tag the JS.
On Tue, Jul 16, 2013 at 11:45 AM, Ian Clelland iclell...@google.com wrote:
On Tue, Jul 16, 2013 at 2:42 PM, Joe Bowser bows...@gmail.com wrote:
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
Yes, no and maybe.
That was the android bridge issue; cordova-js/lib/android/exec.js. It will
be apart of cordova-android as soon as I package up the patched cordova-js
and move it to cordova-android/framework/assets/www.
Ian
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org
wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change. Will
be
fixed shortly. Weird that these would pass at all for anyone in the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in case
the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp
drk...@google.com
wrote:
I had the same error that you got, but running npm install
in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron
shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest from
the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version,
the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform, project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a
plugin?
The
dependencies plugin never cleanly installs or
uninstalls.
On Tue, Jul 16, 2013 at 6:37 AM, Shazron
shaz...@gmail.com
wrote:
Re: 3.0.0 Testing thread
I've moved the latest cordova-js into cordova android, and pushed to
master. All of the mobilespec auto tests are passing for me. (With
mobile-spec-dependencies and all of its dependent plugins installed through
plugman)
Ian
On Tue, Jul 16, 2013 at 2:45 PM, Ian Clelland iclell...@google.com wrote:
On Tue, Jul 16, 2013 at 2:42 PM, Joe Bowser bows...@gmail.com wrote:
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
Yes, no and maybe.
That was the android bridge issue; cordova-js/lib/android/exec.js. It will
be apart of cordova-android as soon as I package up the patched cordova-js
and move it to cordova-android/framework/assets/www.
Ian
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org
wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change.
Will be
fixed shortly. Weird that these would pass at all for anyone in the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in
case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp
drk...@google.com
wrote:
I had the same error that you got, but running npm install
in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron
shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest
from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version,
the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform,
project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
On Tue, Jul 16, 2013 at 7:21 AM, Joe Bowser
bows...@gmail.com
wrote:
Has anyone managed to get plugman to uninstall a
plugin?
The
dependencies plugin never cleanly installs or
uninstalls.
Re: 3.0.0 Testing thread
I'm going to re-tag the JS. Since the only commit is this fix, none of
the other platforms should need re-testing, but grabbing a random JS
isn't the right way to do things, IMO.
On Tue, Jul 16, 2013 at 11:58 AM, Ian Clelland iclell...@chromium.org wrote:
I've moved the latest cordova-js into cordova android, and pushed to
master. All of the mobilespec auto tests are passing for me. (With
mobile-spec-dependencies and all of its dependent plugins installed through
plugman)
Ian
On Tue, Jul 16, 2013 at 2:45 PM, Ian Clelland iclell...@google.com wrote:
On Tue, Jul 16, 2013 at 2:42 PM, Joe Bowser bows...@gmail.com wrote:
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
Yes, no and maybe.
That was the android bridge issue; cordova-js/lib/android/exec.js. It will
be apart of cordova-android as soon as I package up the patched cordova-js
and move it to cordova-android/framework/assets/www.
Ian
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org
wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change.
Will be
fixed shortly. Weird that these would pass at all for anyone in the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in
case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp
drk...@google.com
wrote:
I had the same error that you got, but running npm install
in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron
shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest
from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version,
the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform,
project_dir,
plugin_dir,
plugins_dir, options, callback);
} has no method 'uninstallPlatform']
Re: 3.0.0 Testing thread
Agreed. It's not random, but there's nothing in the process that guarantees
that. It should be tagged, and the tagged version should go out with the
-android repo.
Tag it (3.0.0rc2 -- or 3.0.0-rc2 to be semver-conformant), and you can
re-build and package it with cordova-android.
On Tue, Jul 16, 2013 at 3:14 PM, Joe Bowser bows...@gmail.com wrote:
I'm going to re-tag the JS. Since the only commit is this fix, none of
the other platforms should need re-testing, but grabbing a random JS
isn't the right way to do things, IMO.
On Tue, Jul 16, 2013 at 11:58 AM, Ian Clelland iclell...@chromium.org
wrote:
I've moved the latest cordova-js into cordova android, and pushed to
master. All of the mobilespec auto tests are passing for me. (With
mobile-spec-dependencies and all of its dependent plugins installed
through
plugman)
Ian
On Tue, Jul 16, 2013 at 2:45 PM, Ian Clelland iclell...@google.com
wrote:
On Tue, Jul 16, 2013 at 2:42 PM, Joe Bowser bows...@gmail.com wrote:
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
Yes, no and maybe.
That was the android bridge issue; cordova-js/lib/android/exec.js. It
will
be apart of cordova-android as soon as I package up the patched
cordova-js
and move it to cordova-android/framework/assets/www.
Ian
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org
wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve
agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change.
Will be
fixed shortly. Weird that these would pass at all for anyone in
the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve
agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into
it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve
agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File
plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run
`npm
install` in
its directory to reinitialize the dependencies. Even when
just
updating
the code for the tools, run `npm install` just in case in
case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that
works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp
drk...@google.com
wrote:
I had the same error that you got, but running npm
install
in
the
cordova-cli directory installed a fresh one (not sure
which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron
shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli
from
master,
and
that
is
the latest on npm - but I assume you mean the latest
from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older
version,
the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function
uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if
Re: 3.0.0 Testing thread
All tests pass, cordova-android 3.0.0rc1 has been tagged.
On Tue, Jul 16, 2013 at 12:14 PM, Joe Bowser bows...@gmail.com wrote:
I'm going to re-tag the JS. Since the only commit is this fix, none of
the other platforms should need re-testing, but grabbing a random JS
isn't the right way to do things, IMO.
On Tue, Jul 16, 2013 at 11:58 AM, Ian Clelland iclell...@chromium.org wrote:
I've moved the latest cordova-js into cordova android, and pushed to
master. All of the mobilespec auto tests are passing for me. (With
mobile-spec-dependencies and all of its dependent plugins installed through
plugman)
Ian
On Tue, Jul 16, 2013 at 2:45 PM, Ian Clelland iclell...@google.com wrote:
On Tue, Jul 16, 2013 at 2:42 PM, Joe Bowser bows...@gmail.com wrote:
Has the issue been resolved, and is it plugin-related or is it part of
cordova-android?
Yes, no and maybe.
That was the android bridge issue; cordova-js/lib/android/exec.js. It will
be apart of cordova-android as soon as I package up the patched cordova-js
and move it to cordova-android/framework/assets/www.
Ian
On Tue, Jul 16, 2013 at 11:36 AM, Ian Clelland iclell...@chromium.org
wrote:
That's right -- the issue was android-specific.
Ian
On Tue, Jul 16, 2013 at 2:32 PM, Shazron shaz...@gmail.com wrote:
No need to re-get and re-tag JS right for the other platforms?
On Tue, Jul 16, 2013 at 10:46 AM, Andrew Grieve agri...@chromium.org
wrote:
Okay, seems it was a bad rebase when Ian made the base64 change.
Will be
fixed shortly. Weird that these would pass at all for anyone in the
past
week!
On Tue, Jul 16, 2013 at 1:27 PM, Andrew Grieve agri...@chromium.org
wrote:
Okay - on my N4 4.2.2 they are failing as well. I'll look into it.
On Tue, Jul 16, 2013 at 1:11 PM, Joe Bowser bows...@gmail.com
wrote:
I'm testing on the HTC One running stock 4.2.2. The Google one
without
sense and the other crap.
On Jul 16, 2013 9:51 AM, Andrew Grieve agri...@chromium.org
wrote:
Joe - what setup are you seeing the failures for? I'm running
latest
everything and on 4.1.1 emulator all file tests pass.
Shouldn't be related to ResourceApi change, as the File plugin
doesn't
use
it.
On Tue, Jul 16, 2013 at 11:51 AM, Filip Maj f...@adobe.com
wrote:
Yes, when you clone down either of the tools, ALWAYS run `npm
install` in
its directory to reinitialize the dependencies. Even when just
updating
the code for the tools, run `npm install` just in case in
case the
deps
changed
On 7/16/13 8:06 AM, Shazron shaz...@gmail.com wrote:
aha, cordova-cli specified plugman 0.9.3 -- and that works.
It's
a
bug
when
cordova-cli uses the latest plugman
On Tue, Jul 16, 2013 at 8:03 AM, David Kemp
drk...@google.com
wrote:
I had the same error that you got, but running npm install
in
the
cordova-cli directory installed a fresh one (not sure which
version )
and
everything worked fine
On Tue, Jul 16, 2013 at 10:50 AM, Shazron
shaz...@gmail.com
wrote:
I installed plugman 0.9.6 before using cordova-cli from
master,
and
that
is
the latest on npm - but I assume you mean the latest
from the
cordova-plugman repo
On Tue, Jul 16, 2013 at 7:42 AM, David Kemp
drk...@google.com
wrote:
the newest cli needs the newest plugman.
Also if you uninstall plugins with the older version,
the
new
one
wont
put
them in.
On Tue, Jul 16, 2013 at 10:27 AM, Shazron
shaz...@gmail.com
wrote:
I'm using the master version of the cordova-cli,
installing a
plugin
is
fine, but uninstall throws this error:
$ ../cordova-cli/bin/cordova plugin remove
org.apache.cordova.core.console
[TypeError: Object function uninstallPlugin(platform,
project_dir,
id,
plugins_dir, options, callback) {
if (!platform_modules[platform]) {
var err = new Error(platform + not
supported.);
if (callback) return callback(err);
else throw err;
}
var plugin_dir = path.join(plugins_dir, id);
if (!fs.existsSync(plugin_dir)) {
var err = new Error('Plugin ' + id + ' not
found.
Already
uninstalled?');
if (callback) return callback(err);
else throw err;
}
var current_stack = new action_stack();
options.is_top_level = true;
runUninstall(current_stack, platform,
Re: 3.0.0 Testing thread
So is this semver version thing going to be a problem for people using plugman on its own then? (at least on the rc1 anyways) On Tue, Jul 16, 2013 at 6:31 AM, Joe Bowser bows...@gmail.com wrote: I'm running the latest. The issue was with the use of semver. The version template must return a valid semver version, which 3.0.0rc1 is not. On Tue, Jul 16, 2013 at 6:22 AM, Shazron shaz...@gmail.com wrote: Hmm I'm running plugman 0.9.1 - what version did you run Joe On Tue, Jul 16, 2013 at 6:20 AM, Joe Bowser bows...@gmail.com wrote: I keep getting invalid version 3.0.0rc1 on plugman. :( On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: Documenting Plugin Spec
+1 On Tue, Jul 16, 2013 at 11:03 AM, Shazron shaz...@gmail.com wrote: +1 On Tuesday, July 16, 2013, Anis KADRI wrote: Yes please! On Tue, Jul 16, 2013 at 10:53 AM, Filip Maj f...@adobe.comjavascript:; wrote: Currently exists in the plugman repo. Should we set up a sub guide under cordova-docs plugin guides?
Re: 3.0.0 Testing thread
Never mind - saw https://issues.apache.org/jira/browse/CB-4140 On Tue, Jul 16, 2013 at 12:47 PM, Shazron shaz...@gmail.com wrote: So is this semver version thing going to be a problem for people using plugman on its own then? (at least on the rc1 anyways) On Tue, Jul 16, 2013 at 6:31 AM, Joe Bowser bows...@gmail.com wrote: I'm running the latest. The issue was with the use of semver. The version template must return a valid semver version, which 3.0.0rc1 is not. On Tue, Jul 16, 2013 at 6:22 AM, Shazron shaz...@gmail.com wrote: Hmm I'm running plugman 0.9.1 - what version did you run Joe On Tue, Jul 16, 2013 at 6:20 AM, Joe Bowser bows...@gmail.com wrote: I keep getting invalid version 3.0.0rc1 on plugman. :( On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: 3.0.0 Testing thread
I guess it will. Fkn semver man I see a few workarounds: - massage any versions returned with 'rc' strings in it so they are semver compatible - remove engine constraint checking in plugman - remove engine tags from plugin.xmls On 7/16/13 12:47 PM, Shazron shaz...@gmail.com wrote: So is this semver version thing going to be a problem for people using plugman on its own then? (at least on the rc1 anyways) On Tue, Jul 16, 2013 at 6:31 AM, Joe Bowser bows...@gmail.com wrote: I'm running the latest. The issue was with the use of semver. The version template must return a valid semver version, which 3.0.0rc1 is not. On Tue, Jul 16, 2013 at 6:22 AM, Shazron shaz...@gmail.com wrote: Hmm I'm running plugman 0.9.1 - what version did you run Joe On Tue, Jul 16, 2013 at 6:20 AM, Joe Bowser bows...@gmail.com wrote: I keep getting invalid version 3.0.0rc1 on plugman. :( On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: 3.0.0 Testing thread
On Tue, Jul 16, 2013 at 3:53 PM, Filip Maj f...@adobe.com wrote: I guess it will. Fkn semver man I see a few workarounds: - massage any versions returned with 'rc' strings in it so they are semver compatible Or append -rc1 rather than rc1 when we tag RC releases. Semver is cool with that; it just doesn't like the 0rc1 that shows up in the version number right now. Ian - remove engine constraint checking in plugman - remove engine tags from plugin.xmls On 7/16/13 12:47 PM, Shazron shaz...@gmail.com wrote: So is this semver version thing going to be a problem for people using plugman on its own then? (at least on the rc1 anyways) On Tue, Jul 16, 2013 at 6:31 AM, Joe Bowser bows...@gmail.com wrote: I'm running the latest. The issue was with the use of semver. The version template must return a valid semver version, which 3.0.0rc1 is not. On Tue, Jul 16, 2013 at 6:22 AM, Shazron shaz...@gmail.com wrote: Hmm I'm running plugman 0.9.1 - what version did you run Joe On Tue, Jul 16, 2013 at 6:20 AM, Joe Bowser bows...@gmail.com wrote: I keep getting invalid version 3.0.0rc1 on plugman. :( On Mon, Jul 15, 2013 at 6:54 PM, Shazron shaz...@gmail.com wrote: So far I went and tested with the plugins (specified in the dependencies-plugin on cordova-mobile-spec) on master for iOS, with 1 test failing: File API DirectoryReader interface readEntries file.spec.109 should return an empty entry list on the second call. Expected 0 not to be 0.
Re: 3.0.0 as a beta release?
On Tue, Jul 16, 2013 at 10:38 AM, Andrew Grieve agri...@chromium.orgwrote: One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. We've known this all along. That is precisely why I wanted the ability to manage projects and plugins outside of Cordova-CLI. That is also why plugman can also be used as a standalone tool. People are still able to use the platform provided create/build/emulate scripts. If you don't use CLI, you're still able to load your project in XCode/Eclipse/Android Studio etc... I think both options should be offered for as long as possible. Some people like the command-line some people don't. As far as beta vs final, I think that as long as we're comfortable with our exec bridge and our plugin management it should be a final release. Every other issue can be managed separately in the plugin land as Brian mentioned. This is a major architectural change and I don't expect most developers will upgrade right away unless they're early adopters. Labeling it beta or final won't change that fact I think. The important thing is to document everything related to 3.0 as much as possible.
Re: Upgrading Guides
I think we should document both. On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Upgrading Guides
On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Cordova has a Blog/News! Announce 3.0?
Created JIRA issue here https://issues.apache.org/jira/browse/CB-4276 Will update the wiki once we're through this release (to flesh out the process) Thank YOU Carlos! On Tue, Jul 16, 2013 at 2:05 PM, Carlos Santana csantan...@gmail.comwrote: The Cordova Blog is live http://cordova.apache.org/#news You can use your RSS reader to subscribe A new blog post needs to be added when cutting a new release The step should be added to the Wiki (but I don't access) https://wiki.apache.org/cordova/CuttingReleases A tasks you be added to the JIRA item for announcing release (but I can't find the JIRA #) I want to thank Andrew with putting up with me on setting up the blog, me being a noob to the Cordova community -- Carlos Santana csantan...@gmail.com
Re: Upgrading Guides
+1 document both, but we should be clear that CLI is the new fancy and will eventually become the only supported (whatever that means) workflow at some point in the future. On Tue, Jul 16, 2013 at 5:00 PM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: 3.0.0 as a beta release?
The scripts + plugman workflow works fine. If it didn't, CLI wouldn't either :-} I also agree that one workflow is better than two. It could be one workflow once we figure out a way to allow people to import their projects into their IDEs and/or work on a specific platform without worrying about their native/js code being destroyed at build time. On Tue, Jul 16, 2013 at 1:47 PM, Andrew Grieve agri...@chromium.org wrote: Agree that the core + the plugins are as solid as ever, it's really just the new workflow (CLI) that has rough edges. Agree that a blog post should be the mechanism for delivering the message. I haven't tried the create scripts + plugman workflow, but hopefully that does work well. I am worried about us having two different documented workflows though (CLI vs non-CLI). Seems like a lot of documentation to write and that it could end up sounding confusing (when should one be used over the other, what are the goods bads of either). We do have our own blog now (yay). Any volunteers for drafting the release announcement for it so that we have a bit of time to mull over the message we're sending? For blog posts, I think a vote should be had before anything goes live, maybe in the form of Ship it reviewboard reviews? On Tue, Jul 16, 2013 at 4:36 PM, Anis KADRI anis.ka...@gmail.com wrote: On Tue, Jul 16, 2013 at 10:38 AM, Andrew Grieve agri...@chromium.org wrote: One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. We've known this all along. That is precisely why I wanted the ability to manage projects and plugins outside of Cordova-CLI. That is also why plugman can also be used as a standalone tool. People are still able to use the platform provided create/build/emulate scripts. If you don't use CLI, you're still able to load your project in XCode/Eclipse/Android Studio etc... I think both options should be offered for as long as possible. Some people like the command-line some people don't. As far as beta vs final, I think that as long as we're comfortable with our exec bridge and our plugin management it should be a final release. Every other issue can be managed separately in the plugin land as Brian mentioned. This is a major architectural change and I don't expect most developers will upgrade right away unless they're early adopters. Labeling it beta or final won't change that fact I think. The important thing is to document everything related to 3.0 as much as possible.
Re: 3.0.0 as a beta release?
I think we are getting antsy over something that we shouldn't be. Let's document both flows. I'm sure more issues and edge cases will creep up. We will shake these out over the coming weeks. On 7/16/13 2:26 PM, Anis KADRI anis.ka...@gmail.com wrote: The scripts + plugman workflow works fine. If it didn't, CLI wouldn't either :-} I also agree that one workflow is better than two. It could be one workflow once we figure out a way to allow people to import their projects into their IDEs and/or work on a specific platform without worrying about their native/js code being destroyed at build time. On Tue, Jul 16, 2013 at 1:47 PM, Andrew Grieve agri...@chromium.org wrote: Agree that the core + the plugins are as solid as ever, it's really just the new workflow (CLI) that has rough edges. Agree that a blog post should be the mechanism for delivering the message. I haven't tried the create scripts + plugman workflow, but hopefully that does work well. I am worried about us having two different documented workflows though (CLI vs non-CLI). Seems like a lot of documentation to write and that it could end up sounding confusing (when should one be used over the other, what are the goods bads of either). We do have our own blog now (yay). Any volunteers for drafting the release announcement for it so that we have a bit of time to mull over the message we're sending? For blog posts, I think a vote should be had before anything goes live, maybe in the form of Ship it reviewboard reviews? On Tue, Jul 16, 2013 at 4:36 PM, Anis KADRI anis.ka...@gmail.com wrote: On Tue, Jul 16, 2013 at 10:38 AM, Andrew Grieve agri...@chromium.org wrote: One prime example of something that I think people will get tripped up by is that when you use Xcode or Eclipse, your changes will be often blown away by cordova prepare. I think we should explore solutions to this (e.g. in Xcode, have the project reference the root www/ and merges/ instead of the derived one). Another thing we could do is rename www - derived_www/. We've known this all along. That is precisely why I wanted the ability to manage projects and plugins outside of Cordova-CLI. That is also why plugman can also be used as a standalone tool. People are still able to use the platform provided create/build/emulate scripts. If you don't use CLI, you're still able to load your project in XCode/Eclipse/Android Studio etc... I think both options should be offered for as long as possible. Some people like the command-line some people don't. As far as beta vs final, I think that as long as we're comfortable with our exec bridge and our plugin management it should be a final release. Every other issue can be managed separately in the plugin land as Brian mentioned. This is a major architectural change and I don't expect most developers will upgrade right away unless they're early adopters. Labeling it beta or final won't change that fact I think. The important thing is to document everything related to 3.0 as much as possible.
Cordova-JS Tests
Got them running passing now. No need to retag, but put commit on release branch. as has been said, dont commit to JS if you havent built run tests
Tagging Plugins
Any blockers on me mass tagging the plugins?
Re: Tagging Plugins
I have commits for file + file-transfer for wp that I would like in 3.0.0 Cheers, Jesse Sent from my iPhone5 On Jul 16, 2013, at 3:39 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: Tagging Plugins
go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: Upgrading Guides
For https://issues.apache.org/jira/browse/CB-4222 I added this note at the bottom of the 2.9.0 - 3.0.0 Upgrading Guide for iOS: NOTE: Starting with Cordova 3.0.0, projects do not come with any plugins, you will have to install the ones you require for your project using the `plugman` CLI utility - see the Core Plugin Install Guide. Note the currently non-existent Core Plugin Install Guide which is common for all platforms. I talked to Steve, this doc should show two methods - the Cordova CLI way and the plugman way of how to install the core plugins. Since the Upgrading Guides are for legacy methods, it refers to the plugman way. Mike Sierra, not sure if this is a good method or we should cram everything into the CLI doc. On Tue, Jul 16, 2013 at 2:14 PM, Andrew Grieve agri...@chromium.org wrote: +1 document both, but we should be clear that CLI is the new fancy and will eventually become the only supported (whatever that means) workflow at some point in the future. On Tue, Jul 16, 2013 at 5:00 PM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Upgrading Guides
SGTM! On 7/16/13 4:59 PM, Shazron shaz...@gmail.com wrote: For https://issues.apache.org/jira/browse/CB-4222 I added this note at the bottom of the 2.9.0 - 3.0.0 Upgrading Guide for iOS: NOTE: Starting with Cordova 3.0.0, projects do not come with any plugins, you will have to install the ones you require for your project using the `plugman` CLI utility - see the Core Plugin Install Guide. Note the currently non-existent Core Plugin Install Guide which is common for all platforms. I talked to Steve, this doc should show two methods - the Cordova CLI way and the plugman way of how to install the core plugins. Since the Upgrading Guides are for legacy methods, it refers to the plugman way. Mike Sierra, not sure if this is a good method or we should cram everything into the CLI doc. On Tue, Jul 16, 2013 at 2:14 PM, Andrew Grieve agri...@chromium.org wrote: +1 document both, but we should be clear that CLI is the new fancy and will eventually become the only supported (whatever that means) workflow at some point in the future. On Tue, Jul 16, 2013 at 5:00 PM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Tagging Plugins
iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: Upgrading Guides
SGTM as well. On Tue, Jul 16, 2013 at 8:02 PM, Filip Maj f...@adobe.com wrote: SGTM! On 7/16/13 4:59 PM, Shazron shaz...@gmail.com wrote: For https://issues.apache.org/jira/browse/CB-4222 I added this note at the bottom of the 2.9.0 - 3.0.0 Upgrading Guide for iOS: NOTE: Starting with Cordova 3.0.0, projects do not come with any plugins, you will have to install the ones you require for your project using the `plugman` CLI utility - see the Core Plugin Install Guide. Note the currently non-existent Core Plugin Install Guide which is common for all platforms. I talked to Steve, this doc should show two methods - the Cordova CLI way and the plugman way of how to install the core plugins. Since the Upgrading Guides are for legacy methods, it refers to the plugman way. Mike Sierra, not sure if this is a good method or we should cram everything into the CLI doc. On Tue, Jul 16, 2013 at 2:14 PM, Andrew Grieve agri...@chromium.org wrote: +1 document both, but we should be clear that CLI is the new fancy and will eventually become the only supported (whatever that means) workflow at some point in the future. On Tue, Jul 16, 2013 at 5:00 PM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Tagging Plugins
The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: Upgrading Guides
Yar On Jul 16, 2013 5:23 PM, Andrew Grieve agri...@chromium.org wrote: SGTM as well. On Tue, Jul 16, 2013 at 8:02 PM, Filip Maj f...@adobe.com wrote: SGTM! On 7/16/13 4:59 PM, Shazron shaz...@gmail.com wrote: For https://issues.apache.org/jira/browse/CB-4222 I added this note at the bottom of the 2.9.0 - 3.0.0 Upgrading Guide for iOS: NOTE: Starting with Cordova 3.0.0, projects do not come with any plugins, you will have to install the ones you require for your project using the `plugman` CLI utility - see the Core Plugin Install Guide. Note the currently non-existent Core Plugin Install Guide which is common for all platforms. I talked to Steve, this doc should show two methods - the Cordova CLI way and the plugman way of how to install the core plugins. Since the Upgrading Guides are for legacy methods, it refers to the plugman way. Mike Sierra, not sure if this is a good method or we should cram everything into the CLI doc. On Tue, Jul 16, 2013 at 2:14 PM, Andrew Grieve agri...@chromium.org wrote: +1 document both, but we should be clear that CLI is the new fancy and will eventually become the only supported (whatever that means) workflow at some point in the future. On Tue, Jul 16, 2013 at 5:00 PM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Documenting Plugin Spec
Added as a sub-guide to the Plugin Development. On 7/16/13 12:52 PM, Lorin Beer lorin.beer@gmail.com wrote: +1 On Tue, Jul 16, 2013 at 11:03 AM, Shazron shaz...@gmail.com wrote: +1 On Tuesday, July 16, 2013, Anis KADRI wrote: Yes please! On Tue, Jul 16, 2013 at 10:53 AM, Filip Maj f...@adobe.comjavascript:; wrote: Currently exists in the plugman repo. Should we set up a sub guide under cordova-docs plugin guides?
Re: Tagging Plugins
Waiting on the OK from Jesse for windows and then we are good to tag On Tue, Jul 16, 2013 at 5:33 PM, Bryan Higgins br...@bryanhiggins.netwrote: The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: Tagging Plugins
It might not even be today, but it will be before Friday. Can you tag the rest? @purplecabbage risingj.com On Tue, Jul 16, 2013 at 6:06 PM, Steven Gill stevengil...@gmail.com wrote: Waiting on the OK from Jesse for windows and then we are good to tag On Tue, Jul 16, 2013 at 5:33 PM, Bryan Higgins br...@bryanhiggins.net wrote: The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: Upgrading Guides
I have pushed the first draft of coreplugininstall.md to docs under the plugins folder for now. I am not sure what the best directory to have it under is and I need to make sure that some of the links in it work. Would love someone to look over it (Mike Sierra maybe?) On Tue, Jul 16, 2013 at 5:35 PM, Brian LeRoux b...@brian.io wrote: Yar On Jul 16, 2013 5:23 PM, Andrew Grieve agri...@chromium.org wrote: SGTM as well. On Tue, Jul 16, 2013 at 8:02 PM, Filip Maj f...@adobe.com wrote: SGTM! On 7/16/13 4:59 PM, Shazron shaz...@gmail.com wrote: For https://issues.apache.org/jira/browse/CB-4222 I added this note at the bottom of the 2.9.0 - 3.0.0 Upgrading Guide for iOS: NOTE: Starting with Cordova 3.0.0, projects do not come with any plugins, you will have to install the ones you require for your project using the `plugman` CLI utility - see the Core Plugin Install Guide. Note the currently non-existent Core Plugin Install Guide which is common for all platforms. I talked to Steve, this doc should show two methods - the Cordova CLI way and the plugman way of how to install the core plugins. Since the Upgrading Guides are for legacy methods, it refers to the plugman way. Mike Sierra, not sure if this is a good method or we should cram everything into the CLI doc. On Tue, Jul 16, 2013 at 2:14 PM, Andrew Grieve agri...@chromium.org wrote: +1 document both, but we should be clear that CLI is the new fancy and will eventually become the only supported (whatever that means) workflow at some point in the future. On Tue, Jul 16, 2013 at 5:00 PM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 1:41 PM, Anis KADRI anis.ka...@gmail.com wrote: I think we should document both. But we've already done the CLI docs. :P On Tue, Jul 16, 2013 at 11:48 AM, Joe Bowser bows...@gmail.com wrote: On Tue, Jul 16, 2013 at 6:21 AM, Andrew Grieve agri...@chromium.org wrote: The CLI guide reads quite well! Great work whoever put it together! :) Just occurred to me that for 3.0 - 3.1, we can probably just write a single CLI upgrade guide instead of writing one for each platform (might need caveats per-platform still). Should we document how to create plugman-only projects as well as CLI projects? If so, we'll need a good top-level explainer page that explains the difference. If not, then I don't think we should mention it in our readme. I'm hoping that we can document only the CLI flow so that there will be less diversity in project structures out there, and it will let us focus on doing one thing well. I think we should document plugman-only projects, because that's what exists today. It's much easier to start to use plugman for a project than to use the CLI, especially if you've done your own modifications to the Java code in your Cordova project, which a few people have done. I see nothing here that helps our existing users maintain their codebases. If this project teaches you anything, it should teach you that just because you want people to use your project a certain way, it doesn't mean that they will.
Re: Tagging Plugins
How about I do a mass 3.0.0rc1 tag on them and then for 3.0.0 tag we make sure to get the fully working file file transfer. I want to update all of the readmes for the plugins pointing to the coreplugininstall guide still (once we figure out what directory to host it and the link for it). -Steve On Tue, Jul 16, 2013 at 6:16 PM, Jesse purplecabb...@gmail.com wrote: It might not even be today, but it will be before Friday. Can you tag the rest? @purplecabbage risingj.com On Tue, Jul 16, 2013 at 6:06 PM, Steven Gill stevengil...@gmail.com wrote: Waiting on the OK from Jesse for windows and then we are good to tag On Tue, Jul 16, 2013 at 5:33 PM, Bryan Higgins br...@bryanhiggins.net wrote: The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
PG Day / OSCON
I'll be in Portland for PG Day and OSCON, arriving Wed afternoon. Would be awesome to meet other folks. Ping me if you'd like to get together for beverages / meal / activity. -- Marcel Kinard
Re: Tagging Plugins
I think this is a good idea. Would be good to be able to test cordova plugin add URL_TO_PLUGIN@3.0.0rc1. (maybe that's what you meant Steve) On Tue, Jul 16, 2013 at 10:06 PM, Steven Gill stevengil...@gmail.comwrote: How about I do a mass 3.0.0rc1 tag on them and then for 3.0.0 tag we make sure to get the fully working file file transfer. I want to update all of the readmes for the plugins pointing to the coreplugininstall guide still (once we figure out what directory to host it and the link for it). -Steve On Tue, Jul 16, 2013 at 6:16 PM, Jesse purplecabb...@gmail.com wrote: It might not even be today, but it will be before Friday. Can you tag the rest? @purplecabbage risingj.com On Tue, Jul 16, 2013 at 6:06 PM, Steven Gill stevengil...@gmail.com wrote: Waiting on the OK from Jesse for windows and then we are good to tag On Tue, Jul 16, 2013 at 5:33 PM, Bryan Higgins br...@bryanhiggins.net wrote: The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
Re: PG Day / OSCON
I'll be arriving Thursday evening. On Tue, Jul 16, 2013 at 10:39 PM, Marcel Kinard cmarc...@gmail.com wrote: I'll be in Portland for PG Day and OSCON, arriving Wed afternoon. Would be awesome to meet other folks. Ping me if you'd like to get together for beverages / meal / activity. -- Marcel Kinard
Re: PG Day / OSCON
I arrive Thursday evening as well, along with a number of BlackBerry folks. Would love to meet up. Sent from my BlackBerry 10 smartphone. From: Andrew Grieve Sent: Tuesday, July 16, 2013 10:48 PM To: dev Reply To: dev@cordova.apache.org Subject: Re: PG Day / OSCON I'll be arriving Thursday evening. On Tue, Jul 16, 2013 at 10:39 PM, Marcel Kinard cmarc...@gmail.com wrote: I'll be in Portland for PG Day and OSCON, arriving Wed afternoon. Would be awesome to meet other folks. Ping me if you'd like to get together for beverages / meal / activity. -- Marcel Kinard - 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: Tagging Plugins
Yup. I want to be able to test using the tag. Also finish off the RC to see how the release package looks and figure out what we want to change (if anything) for 3.0 final. I will tag it shortly. On Jul 16, 2013 7:44 PM, Andrew Grieve agri...@chromium.org wrote: I think this is a good idea. Would be good to be able to test cordova plugin add URL_TO_PLUGIN@3.0.0rc1. (maybe that's what you meant Steve) On Tue, Jul 16, 2013 at 10:06 PM, Steven Gill stevengil...@gmail.com wrote: How about I do a mass 3.0.0rc1 tag on them and then for 3.0.0 tag we make sure to get the fully working file file transfer. I want to update all of the readmes for the plugins pointing to the coreplugininstall guide still (once we figure out what directory to host it and the link for it). -Steve On Tue, Jul 16, 2013 at 6:16 PM, Jesse purplecabb...@gmail.com wrote: It might not even be today, but it will be before Friday. Can you tag the rest? @purplecabbage risingj.com On Tue, Jul 16, 2013 at 6:06 PM, Steven Gill stevengil...@gmail.com wrote: Waiting on the OK from Jesse for windows and then we are good to tag On Tue, Jul 16, 2013 at 5:33 PM, Bryan Higgins br...@bryanhiggins.net wrote: The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
[TypeError: Invalid Version: 3.0.0rc1]
So... Did we figure out how to test rc1 with this error? One suggestion was to just retag @ 3.0.0-rc1. Sound good?
Reminder to go through JIRA issues
I've gone through for iOS / JS. Joe's done Android. There's still lots though. If you don't intend them to be fixed soon, remove the Fix For label instead of bumping. https://issues.apache.org/jira/issues/?jql=project%20%3D%20CB%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%223.0.0%22%20ORDER%20BY%20component%20ASC%2C%20priority%20DESC
Re: Tagging Plugins
`./coho tag-release --version 3.0.0rc1 -r plugins` doesn't work due to the lack of release branchs for plugins! no. Manually tagging! On Tue, Jul 16, 2013 at 8:02 PM, Steven Gill stevengil...@gmail.com wrote: Yup. I want to be able to test using the tag. Also finish off the RC to see how the release package looks and figure out what we want to change (if anything) for 3.0 final. I will tag it shortly. On Jul 16, 2013 7:44 PM, Andrew Grieve agri...@chromium.org wrote: I think this is a good idea. Would be good to be able to test cordova plugin add URL_TO_PLUGIN@3.0.0rc1. (maybe that's what you meant Steve) On Tue, Jul 16, 2013 at 10:06 PM, Steven Gill stevengil...@gmail.com wrote: How about I do a mass 3.0.0rc1 tag on them and then for 3.0.0 tag we make sure to get the fully working file file transfer. I want to update all of the readmes for the plugins pointing to the coreplugininstall guide still (once we figure out what directory to host it and the link for it). -Steve On Tue, Jul 16, 2013 at 6:16 PM, Jesse purplecabb...@gmail.com wrote: It might not even be today, but it will be before Friday. Can you tag the rest? @purplecabbage risingj.com On Tue, Jul 16, 2013 at 6:06 PM, Steven Gill stevengil...@gmail.com wrote: Waiting on the OK from Jesse for windows and then we are good to tag On Tue, Jul 16, 2013 at 5:33 PM, Bryan Higgins br...@bryanhiggins.net wrote: The bb plugins should be good to go. On Tue, Jul 16, 2013 at 8:14 PM, Andrew Grieve agri...@chromium.org wrote: iOS and Android are good on the plugin front I believe. I see there still active BB commits going in though. Status of these? On Tue, Jul 16, 2013 at 6:52 PM, Brian LeRoux b...@brian.io wrote: go go go On Tue, Jul 16, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: Any blockers on me mass tagging the plugins?
