Re: Stale branches in cordova-js (and others)
Yep, delete em. On 22 October 2014 12:50, Andrew Grieve agri...@chromium.org wrote: On Wed, Oct 22, 2014 at 12:52 PM, Josh Soref jso...@blackberry.com wrote: There are a number of branches in cordova-js. I think there should be two kinds of branches: 1. Release branches (or tags that are created as branches) 2. Feature branches Well, two other kinds of branches: 3. Merged feature branches 4. Stale/abandoned branches I'd like to remove things that fall into #3/#4: Merged: * future (bhiggins) * pl (filmaj) Stale/abandoned: * playbookFile (timkim) -- note that cordova no longer supports PlayBook... * bb_media_fix (timkim) * async_base64_android (agrieve) -- there's no sign of this being merged in, and no obvious sign of a bug for it Go ahead and delete
Re: remotely loaded pages
I wonder how it solves the problems of serving the
correct version of cordova.js and cordova_plugin.js depending on the
version of the native code that is installed on the different versions of
the mobile App in production.
When you connect to the IP that's being served by connect-phonegap, the
client will send its device.version and device.platform to the server. On
the server's side, there's a res folder within connect-phonegap with all
the various version and platforms of the cordova.js, cordova_plugins.js and
plugins/.
On 21 August 2014 11:20, Carlos Santana csantan...@gmail.com wrote:
Sorry Brian, I thought it was a development time tool to allow for fast
development cycle associated with PhoneGap Developer App.
I guess they can use it and run the connect-phonegap in a production
node-js backend system, I wonder how it solves the problems of serving the
correct version of cordova.js and cordova_plugin.js depending on the
version of the native code that is installed on the different versions of
the mobile App in production.
On Thu, Aug 21, 2014 at 2:06 PM, Brian LeRoux b...@brian.io wrote:
totally, though connect-phonegap *could* be considered production worthy
(it is being used significantly by the pg downstream community)
On Thu, Aug 21, 2014 at 10:53 AM, Carlos Santana csantan...@gmail.com
wrote:
Brain I think that's OK at development time everything is fair game :-)
The problem is developers doing stupid things like loading a cordova.js
from a place they don't know for a in production app being used by end
users, that's just kamikaze
That's OK if they want to shoot themselves in the foot, but then don't
come
crying to JIRA claiming that is a problem with Cordova project.
On Thu, Aug 21, 2014 at 1:30 PM, Brian LeRoux b...@brian.io wrote:
phonegap-connect serves up remote cordova.js (negotiates the
requestor
to
send the right file)
no deaths yet!
https://github.com/phonegap/connect-phonegap/blob/master/lib/middleware/cordova/cordova.js#L29
On Wed, Aug 20, 2014 at 8:57 PM, Ally Ogilvie aogil...@wizcorp.jp
wrote:
That's a good difference to point out.
My personal position is that scenarios where developer is in
control
and
loaded locally (i.e. directupdate, appmobi, spellcaster) is a
valid
scenario for Cordova
I agree, because as cordova.js and cordovaLib are version linked,
it
makes
sense that once an index.html is pulled in, it's cordova.js to load
is
already in the client application.
Loading an external cordova.js would be suicidal. So we save the
file
locally to write into it's HEAD our known path to codova.js
On Thu, Aug 21, 2014 at 9:37 AM, Carlos Santana
csantan...@gmail.com
wrote:
I want to make clarification there is a notable difference
between
loading
a remotely-loaded *(non-local) *HTML pages with Cordova vs. a
downloaded
webapp to be loaded from a *local* HTML.
IBM Worklight has a feature Direct update
http://www-01.ibm.com/support/knowledgecenter/api/content/SSZH4A_6.2.0/com.ibm.worklight.dev.doc/admin/c_direct_updates_app_versions_to_mob.html?locale=en
The scenario is a download and local load of html/cordova.
Similar
scenario
as spellcaster and appmobi
For this scenario there is control from app developer of the code
being
loaded.
What Marcel is asking is a *non-local* load of arbitrary
html/code
not
control by developer, developer loading a free html page own
someone
else
and doing kind of a document.location.replace('
http://somerandom.com/thisotherguy.html')
My personal position is that scenarios where developer is in
control
and
loaded locally (i.e. directupdate, appmobi, spellcaster) is a
valid
scenario for Cordova. loading a random cordova.js directly from a
non-local
random place not guarantee to be supported.
On Wed, Aug 20, 2014 at 12:07 PM, Brian LeRoux b...@brian.io
wrote:
Very much so. So much so, I think we should even consider such
functionality as 'core'. Could dovetail w/ Serviceworker.
On Wed, Aug 20, 2014 at 7:26 AM, Andrew Grieve
agri...@chromium.org
wrote:
I think this is a very desired plugin that many end up
re-writing,
and
it's
far better than setting the content src directly to a remote
URL.
E.g. just stumbled across this yesterday:
http://docs.appmobi.com/index.php/live-update/
On Wed, Aug 20, 2014 at 7:57 AM, Michal Mocny
mmo...@chromium.org
wrote:
Make it available Ally, of course that sounds interesting!
Re: Engine confusion
Should cordova-plugman be renamed to node? - The cordova-plugman version returning node's version sounds like a bug. It should be Plugman's NPM version number so far as I know. Yep, Braden is correct. That is totally a bug. Filed here: https://issues.apache.org/jira/browse/CB-6023 On 11 February 2014 08:05, Braden Shepherdson bra...@chromium.org wrote: The intention is that it allows plugins to specify that they require at least a certain version of the native code for each platform. This would be for things like added a new transport type to the bridge, as when we added binary data transmission on iOS and Android a year or so ago. Any plugins published that relied on it would specify at least that level of cordova-android and cordova-ios, whichever releases the changes made it into. It turns out that the native code is stable enough that this is hardly ever relevant. Answering your questions: - The cordova-plugman version returning node's version sounds like a bug. It should be Plugman's NPM version number so far as I know. - Very few. Most of the significant changes happened several versions ago; in most cases = 3.0 is sufficient. - Build time (more precisely, plugin install time). There are currently no constraints or checks for eg. what versions of Android a plugin supports. - This is true even of the cordova one, which is actually the version of the `cordova` CLI tool if memory serves. Braden On Tue, Feb 11, 2014 at 10:20 AM, Jonathan Bond-Caron jbo...@gdesolutions.com wrote: I'm a bit confused about 'engines' To my surprise, cordova-plugman actually returns node's version: https://github.com/apache/cordova-plugman/blob/master/src/util/default-engines.js Some questions: - Should cordova-plugman be renamed to node? - Are there many plugins that depend on version x of cordova-android, cordova-ios, xcode, ...? - Are 'engines' meant be build time requirements vs. runtime (~webview) requirements? It all looks like build time, with the exception of cordova where cordova.js exec() is required by the plugins. J -- Timothy Kim
Re: Engines and plugins
Howdy,
I think there are too many default engines defined.
for instance
engine name=cordova-android version==1.8.0 /
is essentially the same as
engine name=cordova version==1.8.0 platform=android /
Could someone remind the reason for having platform specific default
engine names? If
they exist for a historic reason can we remove it from the documentation
and guide people to use the platform attribute?
The main reasoning for the default engines (ie, cordova-android,
cordova-ios, etc) was the ability to have the plugin be able to install on
different versions of a particular platform. For example, say your project
is deployed on both iOS and android with your own custom plugin. However,
if the case should arise where your custom plugin only works on say 3.3.0
of android but up to 3.2.0 on iOS then you'll be able to define it with
something like:
engine name=cordova-android version=3.3.0 /
engine name=cordova-ios version=3.2.0 /
As for the regular Cordova engine, that one is basically a shortcut. It
basically says you don't really care about knowing which particular
platform you want to install on but that platform needs to be of some
version of Cordova that a user specifies.
And specifying custom Apache Cordova-based frameworks is a different
beast altogether. It actually gives the responsibility to integrate a
custom engine with plugman to the plug-ins with the scriptSrc attribute.
I do not think this will scale considering that the engine and plug-in
ideally have a different life cycle. I think plugman should actually
provide a way for custom engines to provide this information.
I guess the scriptSrc wasn't the most ideal way of doing this, but I wasn't
too sure how custom engines were being used at that point. So I left it as
the responsibility of the to the custom engine.
I hope that helps!
On 14 January 2014 08:56, Marcel Kinard cmarc...@gmail.com wrote:
Sounds like the ouput of this how it works should go in cordova-docs. If
it's not clear to us, then it won't be clear to users. ;-)
On Jan 13, 2014, at 9:36 PM, Andrew Grieve agri...@chromium.org wrote:
On Mon, Jan 13, 2014 at 6:14 PM, Gorkem Ercan gorkem.er...@gmail.com
wrote:
On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
FYI to others - the docs for this is found here (seems to have some
incorrectly formatted markdown too :( ) :
http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
My understanding was that:
engine name=cordova-android version==1.8.0 /
is the same as:
engine name=cordova-android version==1.8.0 platform=android /
not:
engine name=cordova version==1.8.0 platform=android /
What is actually different here? I know the implementation assumes all
platforms when it sees cordova but it does not have to, it could just
look take platform attribute into account. I am just
trying to understand the reasons for the cordova-${platform} engine
names.
The difference is name=cordova-android vs name=cordova.
Not positive, but I think:
cordova-android refers to the version of the cordova-android repo that
you're using.
cordova refers to the cadence version of cordova that you're using
(version of CLI tools or version of cordova-js)
--
Timothy Kim
Re: cordova serve broken
Ya the cordova serve command isn't working for me either. Just did these steps: npm install cordova -g cordova create foo cd foo cordova platform add ios cordova serve ios // says it's now serving on http://0.0.0.0:8000/ // browse to localhost:8000 // see '404 Not Found' On 12 November 2013 14:04, Brian LeRoux b...@brian.io wrote: My definition of working is deployed not 'works on my machine'. =) I'm not comfortable pushing just this. Steve and/or Braden: are we stable to push a release now that this is apparently fixed? On Tue, Nov 12, 2013 at 1:54 PM, Josh Soref jso...@blackberry.com wrote: Brian wrote: did you try navigating to localhost:8000?? I just updated to latest (deployed) bits and its still broken for me (can we start a new thread about ./platforms/html5 ?) Jenny is testing cordova-cli @master (git fetch¹d today), and we¹re using cordova-blackberry@3.2.x (git fetch¹d today). She did: cordova create 'A new App' a b cd 'A new App¹ cordova platform add blackberry10 cordova serve And then saw: Static file server running on port 8000 (i.e. http://localhost:8000) CTRL + C to shut down And then when we visited http://localhost:8000, we saw a page with ³Package Metadata², there¹s a link for ³blackberry10² and Š well, that¹s my definition of ³working². - 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. -- Timothy Kim
Re: engines tag breaks cordova cli / plugman for BB10
Hrm, looks like the version script is having trouble finding where the www/cordova.js file is located. The issue is if you try calling the version script from different levels of the cli created project, it won't be able to resolve where the cordova.js file should be. On 6 November 2013 13:10, Don Coleman don.cole...@gmail.com wrote: When plugin.xml contains an engines tag, the plugin fails to install with cordova or plugman If the engines tag is removed from plugin.xml, the plugin installs OK $ cordova create foo $ cd foo $ cordova platform add blackberry10 $ cordova plugin add https://github.com/chariotsolutions/phonegap-nfc Fetching plugin from https://github.com/chariotsolutions/phonegap-nfc;... Starting installation of com.chariotsolutions.nfc.plugin for blackberry10 [TypeError: Invalid Version: The file www/cordova.js does not exist.] $ cordova -v 3.1.0-0.2.0 $ plugman -v plugman version 0.14.0 $ uname -a Darwin xvi 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64 -- Timothy Kim
Re: engines tag breaks cordova cli / plugman for BB10
After a little more digging, the fix for that issue should be in for 3.2.0. You can update the platforms/blackberry10/cordova/lib/version.js file with this one: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=blob;f=blackberry10/bin/templates/project/cordova/lib/version.js;h=694451fc702a9d700b9d9f7c6fc6e3e78da20b7d;hb=19cfe94a5a64379a4a3cd6cfaf2acaecb6d24671 On 6 November 2013 13:31, Tim Kim timki...@gmail.com wrote: Hrm, looks like the version script is having trouble finding where the www/cordova.js file is located. The issue is if you try calling the version script from different levels of the cli created project, it won't be able to resolve where the cordova.js file should be. On 6 November 2013 13:10, Don Coleman don.cole...@gmail.com wrote: When plugin.xml contains an engines tag, the plugin fails to install with cordova or plugman If the engines tag is removed from plugin.xml, the plugin installs OK $ cordova create foo $ cd foo $ cordova platform add blackberry10 $ cordova plugin add https://github.com/chariotsolutions/phonegap-nfc Fetching plugin from https://github.com/chariotsolutions/phonegap-nfc ... Starting installation of com.chariotsolutions.nfc.plugin for blackberry10 [TypeError: Invalid Version: The file www/cordova.js does not exist.] $ cordova -v 3.1.0-0.2.0 $ plugman -v plugman version 0.14.0 $ uname -a Darwin xvi 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64 -- Timothy Kim -- Timothy Kim
Re: Plugman engine check and WP7/8
Howdy all, I like Carlos' suggestions in this jira ticket for dealing with Windows scripts:https://issues.apache.org/jira/browse/CB-5187 Appending a .bat or using cmd /c seem pretty easy fixes in this case. I'm +1 either way. I propose to think about 'cordova' engine settings (in default-engines.js) as a fallback in case we don't have any platform specific engine for some platform. So in case of engine.attrib[name] == 'cordova' we should check if there is engine with ['cordova-' + platform] name first and if it does not exist use 'cordova' engine settings only. For example we already do this by the following line, but we need both engines (cordova and cordova-wp8) specified in plugin.xml file. Thoughts? The reason for having both cordova and cordova-platform in your plugin.xml engine definition is so that you can override the base cordova version if a platform needs to have a different version. eg, engines engine name=cordova version==2.7.0 / // this plugin will work on all platforms =2.7.0 engine name=cordova-android version==3.0.0 / // except for android which needs to be = 3.0.0 /engines // make sure we check for platform req's and not just cordova reqs if(cordovaEngineIndex cordovaPlatformEngineIndex) uncheckedEngines.pop(cordovaEngineIndex); PS. Another minor potential issue seems to be in check above; cordovaEngineIndex cordovaPlatformEngineIndex will return false if one of indexes is zero (zero is valid/correct index in this context so it must be true). Good catch. The getEngines function could use a refactor. Are you ok if I create ticket for this specific bug (plugman + wp78) and fix it as per steps 1 and 2 above? I say go for it. -- Timothy Kim On 23 October 2013 12:51, Josh Soref jso...@blackberry.com wrote: On 10/23/13 2:23 PM, Carlos Santana csantan...@gmail.com wrote: Actually just try it out and see that using spawn with cmd [/c,cordova/build,... is better option than adding the .bat then it covers build.exe, build.bat, and build.cmd on windows if someone thinks this is bad route, please shime in this jira issue [1] I'm actually +1 on this approachŠ [Note: I've become the recognized Windows expert here in under a week] - 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. -- Timothy Kim
Re: build failure
Hey David, I just uploaded a patch that should hopefully things for ya. Let me know if there are any more problems. On 18 October 2013 18:51, Tim Kim timki...@gmail.com wrote: Hrmmm. Shoot. Funny how a '.0' can paint you into a corner. I'm not sure if there are any easy solutions to this one since the code always pulls the latest. I think what I'll do is add some logic such that the new version-compare in plugman can handle differing version strings. Unfortunately it's pretty much end of the day for me here, but I'll attempt for a fix this weekend. On 18 October 2013 18:27, David Kemp drk...@google.com wrote: Hi Tim, That has indeed fixed the master branch, but the 3.1 release branch still has the problem. I currently always build with the latest tool chain (plugman) so a non backward-compatible change to plugman will be an issue. That would require that the fix to mobilespec be back-patched to 3.1 as well. Not sure if that has any other side-effects. On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim timki...@gmail.com wrote: Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: build failure
Woo! On 21 October 2013 15:59, David Kemp drk...@google.com wrote: Looks like it fixed it! On Oct 21, 2013 4:40 PM, Tim Kim timki...@gmail.com wrote: Hey David, I just uploaded a patch that should hopefully things for ya. Let me know if there are any more problems. On 18 October 2013 18:51, Tim Kim timki...@gmail.com wrote: Hrmmm. Shoot. Funny how a '.0' can paint you into a corner. I'm not sure if there are any easy solutions to this one since the code always pulls the latest. I think what I'll do is add some logic such that the new version-compare in plugman can handle differing version strings. Unfortunately it's pretty much end of the day for me here, but I'll attempt for a fix this weekend. On 18 October 2013 18:27, David Kemp drk...@google.com wrote: Hi Tim, That has indeed fixed the master branch, but the 3.1 release branch still has the problem. I currently always build with the latest tool chain (plugman) so a non backward-compatible change to plugman will be an issue. That would require that the fix to mobilespec be back-patched to 3.1 as well. Not sure if that has any other side-effects. On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim timki...@gmail.com wrote: Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: build failure
Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim
Re: build failure
Hrmmm. Shoot. Funny how a '.0' can paint you into a corner. I'm not sure if there are any easy solutions to this one since the code always pulls the latest. I think what I'll do is add some logic such that the new version-compare in plugman can handle differing version strings. Unfortunately it's pretty much end of the day for me here, but I'll attempt for a fix this weekend. On 18 October 2013 18:27, David Kemp drk...@google.com wrote: Hi Tim, That has indeed fixed the master branch, but the 3.1 release branch still has the problem. I currently always build with the latest tool chain (plugman) so a non backward-compatible change to plugman will be an issue. That would require that the fix to mobilespec be back-patched to 3.1 as well. Not sure if that has any other side-effects. On Fri, Oct 18, 2013 at 8:59 PM, Tim Kim timki...@gmail.com wrote: Hey there David, I just committed a fix for mobile spec. I believe the problem was that the engine tag in cordova-mobile-spec/dependencies-plugin/plugin.xml needed to have a patch portion to the version. On 18 October 2013 17:48, David Kemp drk...@chromium.org wrote: Builds are failing due to an inability to add plugins. This started about 8:2pm with three plugman commits by Tim Kim error text: Fetching plugin from ../cordova-mobile-spec/dependencies-plugin... Starting installation of org.cordova.mobile-spec-dependencies for ios[Error: Different version string format detected. Unable to compare to versions. Please check the output from your version script and the engine tag in your plugin.xml. -- Timothy Kim -- Timothy Kim
Re: Plugins Release blog post
Can we serve the html doc somewhere? I'd rather not read a diff on html. On 26 September 2013 18:08, Steven Gill stevengil...@gmail.com wrote: Looks like I forgot to click publish on the review page. I also found a bunch of spelling mistakes I made in my rush to create this. I just fixed them and uploaded a new diff. The review site should be available for all now to leave feedback. On Thu, Sep 26, 2013 at 5:42 PM, Steven Gill stevengil...@gmail.com wrote: Today we are doing a big plugin release in preperation for Apache Cordova 3.1.0 which is scheduled to come out next week. The main change for this release is removing core from all of the plugin ID fields. This was done to make installing plugins easier in 3.1.0. We are switching over to using plugin IDs and ourplugin registery http://plugins.cordova.io/ for plugin installation instead of directly installing from the plugin git urls. These plugins are compatitable with Cordova 3.0.0. Feel free to upgrade your current plugins if you can’t wait for 3.1.0 next week. Keep in mind that after you install these update plugins, if you decide to remove these plugins from your project, you will have to reference the new IDs instead of the old ones that our docs show. Ex: ‘cordova rm org.apache.cordova.camera’ instead of ‘org.apache.cordova.core.camera’. *Other Notable Changes:* - Firefox OS support for Vibration and Device Plugin - Windows 8 support for multiple plugins - Fixed warnings that arose with XCode 5 - CB-4847 iOS 7 microphone access requires user permission (media plugin) - CB-4799 Fix incorrect JS references within native code for iOS Andrid (media plugin) - CB-4806 Update splashscreen image bounds for iOS 7 (splashscreen plugin) - CB-4593 Added vibration support for BB10 (vibration plugin) You can check out the individual release notes in each of the plugin repos for more details. On Thu, Sep 26, 2013 at 5:37 PM, Steven Gill stevengil...@gmail.com wrote: I have no idea how this review stuff works. I will post the blog here On Sep 26, 2013 4:59 PM, Tim Kim timki...@gmail.com wrote: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim -- Timothy Kim
Re: Plugins Release blog post
You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. Ya, same here On 26 September 2013 16:37, Shazron shaz...@gmail.com wrote: Does everyone have access to this? I get: You don't have access to this review request. This review request is private. You must be a requested reviewer, either directly or on a requested group, and have permission to access the repository in order to view this review request. On Thu, Sep 26, 2013 at 4:30 PM, Steven Gill stevengil...@gmail.com wrote: Can you guys review it at https://reviews.apache.org/r/14356/ I don't think post-review was working properly for me... -- Timothy Kim
Re: Moving on
Fil, I still remember the times we were up late at night hacking away on CMPT assignments. You turned out to be a hell of a coder! Enjoy Saucelabs! On 30 August 2013 13:17, David Kemp drk...@google.com wrote: Good Luck in your new endeavour! On Fri, Aug 30, 2013 at 2:31 PM, Filip Maj maj@gmail.com wrote: Hey everyone, Wanted to let the community know that I'm moving on from Adobe. Tuesday I'll be starting at Saucelabs, working on mobile automation on the RD team. My focus is going to shift away from cordova a little bit, but not entirely. My plan is to be involved a lot more in cordova-medic moving forward, but stepping away from the tooling (plugman + cli), JS, spec and platform work. As such, I'll be removing myself as lead in JIRA on the cordovaJS, mobile-spec, cli and plugman components. If any committers want to step up and take on a more involved role on those components, I'd recommend assigning yourself as lead in JIRA to those, that's always an easy way to be intimately familiar with issues coming down the pipeline :) Looking forward to working more on medic with you all! Cheers, Fil -- Timothy Kim
Getting the Plugin Registry Set up Locally
Hey gang,
I believe the good people at google were wanting to hack on plugin registry
but were unsure how to set it up. Here are some instructions to get this
ole bucket of bolts going:
How to get plugin registry going locally
1) Install couchdb:
http://wiki.apache.org/couchdb/Installation
Follow instructions in the link above for your platform.
1.b) Start up couchdb:
sudo couchdb
Should launch on http://127.0.0.1:5984/ by default
1.c) Set up admin on couchdb:
http://guide.couchdb.org/draft/security.html
1.d) Check out Futon panel for couchdb:
Go to http://127.0.0.1:5984/_utils/
1.e) Sign in as admin:
Click on the 'Login' link in the bottom right (kinda hard to find) and
use credentials set in step 1.c
1.f) Turn secure_rewrites to false:
Go to Tools/Configuration
Search for secure_rewrites under the section httpd
Make sure secure_rewrites is set to false
2) install couchapp
sudo npm install couchapp -g
3) Clone npmjs.org:
https://github.com/imhotep/npmjs.org
Follow the Installing part of the readme, but don't synch from the npm
registry.
3.b) Replicate from cordova registry
Haven't actually gotten this step to work atm - getting weird error:
curl -X POST -H Content-Type:application/json \
http://127.0.0.1:5984/_replicate -d \
'{source:http://registry.cordova.io/;, target:registry}'
Or use Futon panel:
Click on Tools/Replicator and use UI
3.c) Launch the registry locally:
cd npmjs.org
couchapp serve registry/app.js http://127.0.0.1:5984/registry -d
www/attachments/
4) Use plugin-registry to interact with registry locally:
https://github.com/imhotep/plugman-registry
See https://github.com/imhotep/plugman-registry/blob/master/index.jsvariable
local_registry to make sure it's pointing in the right place
I haven't gotten the replication step from registry.cordova.io to work just
yet, but I figured I'd put up what I have so far so at least people can
choose to get started. I'll post an update when I figured out what's going
on (it might be just me who's erroring out).
Anywho, I hope that helps!
--
Timothy Kim
Re: Getting the Plugin Registry Set up Locally
Eh, it's in the wiki now. The problem with the readme is which project
should get it. And since the instructions involve piecing multiple
repos/tech together, I think the wiki doc makes more sense.
On 19 August 2013 15:27, Brian LeRoux b...@brian.io wrote:
readme.md
On Mon, Aug 19, 2013 at 3:07 PM, Filip Maj f...@adobe.com wrote:
Wiki page!
On 8/19/13 2:55 PM, Tim Kim timki...@gmail.com wrote:
Hey gang,
I believe the good people at google were wanting to hack on plugin
registry
but were unsure how to set it up. Here are some instructions to get this
ole bucket of bolts going:
How to get plugin registry going locally
1) Install couchdb:
http://wiki.apache.org/couchdb/Installation
Follow instructions in the link above for your platform.
1.b) Start up couchdb:
sudo couchdb
Should launch on http://127.0.0.1:5984/ by default
1.c) Set up admin on couchdb:
http://guide.couchdb.org/draft/security.html
1.d) Check out Futon panel for couchdb:
Go to http://127.0.0.1:5984/_utils/
1.e) Sign in as admin:
Click on the 'Login' link in the bottom right (kinda hard to find) and
use credentials set in step 1.c
1.f) Turn secure_rewrites to false:
Go to Tools/Configuration
Search for secure_rewrites under the section httpd
Make sure secure_rewrites is set to false
2) install couchapp
sudo npm install couchapp -g
3) Clone npmjs.org:
https://github.com/imhotep/npmjs.org
Follow the Installing part of the readme, but don't synch from the npm
registry.
3.b) Replicate from cordova registry
Haven't actually gotten this step to work atm - getting weird error:
curl -X POST -H Content-Type:application/json \
http://127.0.0.1:5984/_replicate -d \
'{source:http://registry.cordova.io/;, target:registry}'
Or use Futon panel:
Click on Tools/Replicator and use UI
3.c) Launch the registry locally:
cd npmjs.org
couchapp serve registry/app.js http://127.0.0.1:5984/registry -d
www/attachments/
4) Use plugin-registry to interact with registry locally:
https://github.com/imhotep/plugman-registry
See
https://github.com/imhotep/plugman-registry/blob/master/index.jsvariable
local_registry to make sure it's pointing in the right place
I haven't gotten the replication step from registry.cordova.io to work
just
yet, but I figured I'd put up what I have so far so at least people can
choose to get started. I'll post an update when I figured out what's
going
on (it might be just me who's erroring out).
Anywho, I hope that helps!
--
Timothy Kim
--
Timothy Kim
Re: Getting the Plugin Registry Set up Locally
And the wiki link: https://wiki.apache.org/cordova/PluginDiscovery
On 19 August 2013 16:13, Tim Kim timki...@gmail.com wrote:
Eh, it's in the wiki now. The problem with the readme is which project
should get it. And since the instructions involve piecing multiple
repos/tech together, I think the wiki doc makes more sense.
On 19 August 2013 15:27, Brian LeRoux b...@brian.io wrote:
readme.md
On Mon, Aug 19, 2013 at 3:07 PM, Filip Maj f...@adobe.com wrote:
Wiki page!
On 8/19/13 2:55 PM, Tim Kim timki...@gmail.com wrote:
Hey gang,
I believe the good people at google were wanting to hack on plugin
registry
but were unsure how to set it up. Here are some instructions to get
this
ole bucket of bolts going:
How to get plugin registry going locally
1) Install couchdb:
http://wiki.apache.org/couchdb/Installation
Follow instructions in the link above for your platform.
1.b) Start up couchdb:
sudo couchdb
Should launch on http://127.0.0.1:5984/ by default
1.c) Set up admin on couchdb:
http://guide.couchdb.org/draft/security.html
1.d) Check out Futon panel for couchdb:
Go to http://127.0.0.1:5984/_utils/
1.e) Sign in as admin:
Click on the 'Login' link in the bottom right (kinda hard to find) and
use credentials set in step 1.c
1.f) Turn secure_rewrites to false:
Go to Tools/Configuration
Search for secure_rewrites under the section httpd
Make sure secure_rewrites is set to false
2) install couchapp
sudo npm install couchapp -g
3) Clone npmjs.org:
https://github.com/imhotep/npmjs.org
Follow the Installing part of the readme, but don't synch from the
npm
registry.
3.b) Replicate from cordova registry
Haven't actually gotten this step to work atm - getting weird error:
curl -X POST -H Content-Type:application/json \
http://127.0.0.1:5984/_replicate -d \
'{source:http://registry.cordova.io/;, target:registry}'
Or use Futon panel:
Click on Tools/Replicator and use UI
3.c) Launch the registry locally:
cd npmjs.org
couchapp serve registry/app.js http://127.0.0.1:5984/registry -d
www/attachments/
4) Use plugin-registry to interact with registry locally:
https://github.com/imhotep/plugman-registry
See
https://github.com/imhotep/plugman-registry/blob/master/index.jsvariable
local_registry to make sure it's pointing in the right place
I haven't gotten the replication step from registry.cordova.io to work
just
yet, but I figured I'd put up what I have so far so at least people can
choose to get started. I'll post an update when I figured out what's
going
on (it might be just me who's erroring out).
Anywho, I hope that helps!
--
Timothy Kim
--
Timothy Kim
--
Timothy Kim
Re: Storing Version Numbers
+1
On 14 August 2013 12:44, Filip Maj f...@adobe.com wrote:
Looks good to me!
On 8/14/13 11:49 AM, Andrew Grieve agri...@chromium.org wrote:
Ian's put together a wiki page on how to store version numbers in our
repos:
https://wiki.apache.org/cordova/PlatformVersionScripts
I'd like to add info to it for non-platform repos as well, but want to
draw
everyone's attention to it on the ML so that we can have easier comments
about it:
= All Repositories =
'''Proposal'''
VERSION files go away. None of the below schemes use them, so they should
be added only when building Apache release .zips.
= Cordova platforms =
Cordova platforms should have a simple, reliable method to report their
version number, for use by automated tools such as CLI and plugman.
The current method for doing this (supported by Android; support coming
for
other platforms) is to have a script in the platform package, under
`bin/templates/cordova/version`, which can be called to report the version
number.
Previously, this file would, on some platforms, go through some rather
complicated process to infer the correct version number (such as checking
the git hash of the included cordova.js file). It will be simpler and
easier to maintain to have this file simply echo a string constant.
The version number should correspond closely to the git branch. When a
release branch is made, both the branch and the master branch should be
updated. The master branch should *always* have a version number ending in
-dev, which indicates the version currently being developed. A fresh
release branch should change the version to an -rc1 version, and then
change to the unqualified version number when it is released.
(This constant version number can be updated manually, but *should*
eventually be updated via coho as release branches are made.)
This should give a rough idea how the version number should advance:
{{{
3.3.0-dev
3.2.0-dev|
| |
--A---B---C---D (master)
\
\--E---F---G---H (3.2.x)
| | |
3.2.0-rc1| 3.2.1-rc1
3.2.0
}}}
* A: This is on the master branch, after 3.1.x has been branched, as 3.2
is being developed.
* B: This is the branch point for 3.2.x
* C: The first commit after 3.2.x is branched should identify the master
branch as 3.3 is being developed on master now.
* E: The first commit on the 3.2.x branch should identify the branch as
3.2.0-rc1
* G: At some point, 3.2.0 is released, and should be identified as such
* H: After 3.2.0 is released, any further development can be called
3.2.1-rc1
Current support:
||'''Platform'''||'''Support'''||
||Android || {*} ||
||BB10 || {o} ||
||iOS || {o} ||
||OSX || {o} ||
||QT|| {o} ||
||Tizen || {o} ||
||WebOS || {o} ||
||Win || {o} ||
||WP7 || {o} ||
||WP8 || {o} ||
||www || {o} ||
= Cordova JS =
The version of the JS is stamped at the top of the built .js file by
grunt.
Currently, the version is derived using `git describe` and so is based off
of the closest git tag in the history. This works well for releases, but
isn't great for dev builds since there are no tags made on master.
'''Proposal:'''
1. Follow platform versioning scheme and store it in a constant within
Gruntfile.js.
1. When in built in the context of a git repo, and not at a tagged
commit,
append the git hash.
1. When not in a git repo or at a tagged commit, don't try and append a
hash.
= Core Plugins =
Current state is that we have master dev branches. This is because
plugman pulls from master by default, so it must remain stable.
Once plugman-registry is launched, it should be used instead
'''Proposal:'''
1. Stick with dev / master branches
1. Releases involve:
a. Update plugin.xml's version to 3.1.0
a. Merge dev - master
a. Update plugin.xml's version again to say 3.2.0-dev
= Plugman CLI =
These tools are built as npm modules, and so use package.json semver
versioning.
--
Timothy Kim
Re: Plugin versioning
Ya, it does an engine/version check but only for cordova js - it currently does nothing about the os/sdk versions of the platform you're deving for. I was thinking about handling the check for os/sdk within the engine tag or the platform tag in plugin.xml, but I think that the platform tag is the better choice. If we add it to the engine tag, it'd probably would end up looking something like this: engines engine name=cordova version=x.x.x.x platform name=ios min-sdk-version=x.x.x.x min-os-version=x.x.x.x / platform name=android min-sdk-version= min-os-version= /engines ... platform name=android ... /platform platform name=ios ... /platform So it seems to me that the above is a little redundant in that you could just put the min-sdk-version/min-os-version in the platform tag in first place instead of being a child of the engine tag. Here are the relevant jira issues: https://issues.apache.org/jira/browse/CB-3646 https://issues.apache.org/jira/browse/CB-4036 On 24 July 2013 14:39, Shazron shaz...@gmail.com wrote: So when cordova adding plugins it does an engine check, yes? I've got this situation where I want to add a new method to CDVCommandDelegate (see my last comment in the issue below): https://issues.apache.org/jira/browse/CB-4355 Basically I want to do this with minimal hassle to devs... (I suppose I could do a respondsToSelector, but that's just ugly) -- Timothy Kim
Re: Any problem with making DirectoryManager.getTempDirectoryPath public
Hey gang, I also need to make some function in DirectoryManager public for the file api. We cool with that too? The ones in question: testFileExists getFreeDiskSpace testSaveLocationExists Looking like we should definitely make DirectoryManager as a public api now. On 11 June 2013 12:51, Joe Bowser bows...@gmail.com wrote: It's a part of plugin breakout. The main question is whether DirectoryManager should be a public API by documenting it, since a plugin needs it to function, not should we make it public. But yeah, make it public Steve! On Tue, Jun 11, 2013 at 12:48 PM, Simon MacDonald simon.macdon...@gmail.com wrote: Huh, you shouldn't need to do that as the DirectoryManager and CameraLauncher are in the same package. I guess you are moving CameraLauncher into it's own package, in which case go for it. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Jun 11, 2013 at 3:43 PM, Steven Gill stevengil...@gmail.com wrote: For Android. I need to make DirectoryManager.getTempDirectoryPath public so it can work with the camera plugin. -Steve -- Timothy Kim
Android Network Plugin Breakout
Hey gang, So I'm trying to rip out the android network plugin, but it appears the android exec relies on the network plugin for online/offline events. https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blob;f=lib/android/exec.js;h=206c09acb6d939b91e28b8813fa7fe318c2a4483;hb=0a5fa1fa255e12625969cef1aaeecd1582e5b389#l117 I'm not too sure how to cleanly rip out the network plugin stuff from cordova js without potentially breaking the online/offline events, so I figured I'd ask for some help. I'm thinking that we move network stuff to be a core part of android or perhaps not have to rely on the network plugin somehow. Related jira issue : https://issues.apache.org/jira/browse/CB-3509#comment-13677532 -- Timothy Kim
Re: Android Network Plugin Breakout
How is this not a problem for the rest of the platforms? That's the first thing that I'm wondering right now. I think ios' deviceready event also doesn't fire, but I'm not sure if it's for the same reasons - haven't gone down that rabbit hole yet. As for bb10, I'm not sure anymore since it has changed with the new bb10 repo. It used to rely on some webworks stuff. Actually, online/offline has to be core, because it's part of the bridge. We can't rip that out because some platform may need the Online/Offline event bridge. That's a pretty serious gotcha. It's also why it's a problem on Android and not on other platforms. Hrm, if it's the case where we have it as core in Android, should we also have in core for the other platforms? -- Timothy Kim
Re: Meeting Recorder for #cordova on irc.freenode.net?
+1 It'd be nice to look up a particular discussion if you weren't in one. On 1 June 2013 17:56, Filip Maj f...@adobe.com wrote: The Infra guys posted about some new features they've worked on (the git-JIRA commenting is one that Shaz already got working for us), and there's one where we can get the ASFBot to idle in #cordova on irc, and we can use it to start/stop recording of meetings that we may have in IRC. I know Braden, Anis, Tim, Steve, and I chat rather frequently on IRC for quick little things, and sometimes we can get into discussions that are worth noting and sharing with the list. Anyone have any objections to this? -- Timothy Kim
Re: Baby Grieve
Congratulations, Grieve family! On 31 May 2013 07:05, Bryan Higgins br...@bryanhiggins.net wrote: Congrats!!! On Fri, May 31, 2013 at 10:03 AM, Steven Gill stevengil...@gmail.com wrote: Congrats Andrew!!! On Fri, May 31, 2013 at 7:00 AM, Andrew Grieve agri...@chromium.org wrote: Coming 1 month early Everett Arend Grieve born Thursday May 30 at 9:45 am. 5 lbs 15 oz. 18.5 inches long. Mom is currently in the ACOU and Everett in the ICU. They are on track to meet today! We will be a few days in the hospital, but everything's looking good! Not sure how much I'll be checking email in the next little while. Good luck with the release! Andrew -- Timothy Kim
Standardising How to Get Cordova Version in a Project
Hey gang, So I'm working on the engine tag for plugman and I've come across a bit of a problem. For those who don't know, the engine tag is for checking whether a plugin needs a certain version of Cordova to work. It's one of the last outstanding features for the plugman spec that has yet to be implemented. Anyhow, the problem is figuring out what version of Cordova a particular project is using. Each platform is different in how they 'determine' which current version is being used. eg, VERSION files, a jar file that has the version string in it, cordova js file with version in the file name or first line, etc. Moving forward, I was hoping that we could include an additional config xml element to specify which version of Cordova is being used. So something like that could be added in during the create scripts. That way I can just reference the config xml file and get all the info I need. However, the problem with that approach is if a particular user decides to just upgrade their project but copying and pasting new files or changed version somehow, they will also have to remember to upgrade their version string in config xml. It's not so bad, but kinda annoying. If no change is made, I've done some work to solve this problem but it's pretty brittle. You supply a possible path(s) of where you think the version string might be and it'll try and figure it out for you. So it should work with the recent change of moving the version number to the top of the cordova.js file: https://github.com/timkim/plugman/tree/search_cordova -- Timothy Kim
Re: Standardising How to Get Cordova Version in a Project
Oooh - I like Shaz's idea. +1 to that! On 2 May 2013 15:22, Brian LeRoux b...@brian.io wrote: thats a great idea On Thu, May 2, 2013 at 2:46 PM, Erik Johnson erjohn...@blackberry.com wrote: +1 on this idea. -Erik From: Shazron Sent: Thursday, May 2, 2013 5:28 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Standardising How to Get Cordova Version in a Project Why don't we defer to each platform how to read the version - return it in a script? kinda like bin/check_reqs On Thu, May 2, 2013 at 2:18 PM, Tim Kim timki...@gmail.com wrote: Hey gang, So I'm working on the engine tag for plugman and I've come across a bit of a problem. For those who don't know, the engine tag is for checking whether a plugin needs a certain version of Cordova to work. It's one of the last outstanding features for the plugman spec that has yet to be implemented. Anyhow, the problem is figuring out what version of Cordova a particular project is using. Each platform is different in how they 'determine' which current version is being used. eg, VERSION files, a jar file that has the version string in it, cordova js file with version in the file name or first line, etc. Moving forward, I was hoping that we could include an additional config xml element to specify which version of Cordova is being used. So something like that could be added in during the create scripts. That way I can just reference the config xml file and get all the info I need. However, the problem with that approach is if a particular user decides to just upgrade their project but copying and pasting new files or changed version somehow, they will also have to remember to upgrade their version string in config xml. It's not so bad, but kinda annoying. If no change is made, I've done some work to solve this problem but it's pretty brittle. You supply a possible path(s) of where you think the version string might be and it'll try and figure it out for you. So it should work with the recent change of moving the version number to the top of the cordova.js file: https://github.com/timkim/plugman/tree/search_cordova -- Timothy Kim - 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. -- Timothy Kim
Re: Re-tag Cordova Js?
Done and done. On 19 April 2013 14:21, Filip Maj f...@adobe.com wrote: Probably a retag since we use the contents of VERSION to interpolate the framework version string into the JS-only platforms' JS. On 4/19/13 2:16 PM, Tim Kim timki...@gmail.com wrote: Hey gang, I noticed that the 2.7.0rc1 tag commit for Cordova JS sets the version to just 2.7.0: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=d0ffb8 52378ff018bac2f3b12c38098a19b8ce00 Small thing really - should we just force a retag or do something else? -- Timothy Kim -- Timothy Kim
Re: Re-tag Cordova Js?
Ya I couldn't find them either. My guess is that the Set VERSION to 2.7.0 commit was in a detached head state when pushed to the repo. I wasn't too sure what was going on, so I decided to go with the flow. On 19 April 2013 16:46, Shazron shaz...@gmail.com wrote: Looking at cordova-js: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=summary The 2.7.0rc1 tag, the last two commits: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=log;h=refs/tags/2.7.0rc1 1. Fixed version number 2. Set VERSION to 2.7.0 I can't seem to find these commits in any branch, not 2.7.x, nor master. Am I going crazy or is there something else going on? :/ On Fri, Apr 19, 2013 at 2:34 PM, Tim Kim timki...@gmail.com wrote: Done and done. On 19 April 2013 14:21, Filip Maj f...@adobe.com wrote: Probably a retag since we use the contents of VERSION to interpolate the framework version string into the JS-only platforms' JS. On 4/19/13 2:16 PM, Tim Kim timki...@gmail.com wrote: Hey gang, I noticed that the 2.7.0rc1 tag commit for Cordova JS sets the version to just 2.7.0: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=d0ffb8 52378ff018bac2f3b12c38098a19b8ce00 Small thing really - should we just force a retag or do something else? -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: Re-tag Cordova Js?
NOOO On 19 April 2013 17:15, Shazron shaz...@gmail.com wrote: You checked in merge conflicts. e.g. + HEAD 2.5.0 +=== +2.7.0rc1 + On Fri, Apr 19, 2013 at 5:14 PM, Tim Kim timki...@gmail.com wrote: Ok, it should be good to go now. On 19 April 2013 16:59, Shazron shaz...@gmail.com wrote: Can you commit them to the two branches from your local? If not when we generate the js off the branches it's not correct On Fri, Apr 19, 2013 at 4:57 PM, Tim Kim timki...@gmail.com wrote: Ya I couldn't find them either. My guess is that the Set VERSION to 2.7.0 commit was in a detached head state when pushed to the repo. I wasn't too sure what was going on, so I decided to go with the flow. On 19 April 2013 16:46, Shazron shaz...@gmail.com wrote: Looking at cordova-js: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=summary The 2.7.0rc1 tag, the last two commits: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=log;h=refs/tags/2.7.0rc1 1. Fixed version number 2. Set VERSION to 2.7.0 I can't seem to find these commits in any branch, not 2.7.x, nor master. Am I going crazy or is there something else going on? :/ On Fri, Apr 19, 2013 at 2:34 PM, Tim Kim timki...@gmail.com wrote: Done and done. On 19 April 2013 14:21, Filip Maj f...@adobe.com wrote: Probably a retag since we use the contents of VERSION to interpolate the framework version string into the JS-only platforms' JS. On 4/19/13 2:16 PM, Tim Kim timki...@gmail.com wrote: Hey gang, I noticed that the 2.7.0rc1 tag commit for Cordova JS sets the version to just 2.7.0: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=d0ffb8 52378ff018bac2f3b12c38098a19b8ce00 Small thing really - should we just force a retag or do something else? -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: Re-tag Cordova Js?
Ya...I just realised. Arg. On 19 April 2013 17:35, Jesse purplecabb...@gmail.com wrote: rc1 tag is on master but not the 2.7.x branch @purplecabbage risingj.com On Fri, Apr 19, 2013 at 5:27 PM, Shazron shaz...@gmail.com wrote: Hey it's no so bad, just find the chevrons and pick the right section. If you gtg I can take care of it On Fri, Apr 19, 2013 at 5:24 PM, Jesse purplecabb...@gmail.com wrote: Hurry! It's Friday. @purplecabbage risingj.com On Fri, Apr 19, 2013 at 5:19 PM, Tim Kim timki...@gmail.com wrote: NOOO On 19 April 2013 17:15, Shazron shaz...@gmail.com wrote: You checked in merge conflicts. e.g. + HEAD 2.5.0 +=== +2.7.0rc1 + On Fri, Apr 19, 2013 at 5:14 PM, Tim Kim timki...@gmail.com wrote: Ok, it should be good to go now. On 19 April 2013 16:59, Shazron shaz...@gmail.com wrote: Can you commit them to the two branches from your local? If not when we generate the js off the branches it's not correct On Fri, Apr 19, 2013 at 4:57 PM, Tim Kim timki...@gmail.com wrote: Ya I couldn't find them either. My guess is that the Set VERSION to 2.7.0 commit was in a detached head state when pushed to the repo. I wasn't too sure what was going on, so I decided to go with the flow. On 19 April 2013 16:46, Shazron shaz...@gmail.com wrote: Looking at cordova-js: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=summary The 2.7.0rc1 tag, the last two commits: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=log;h=refs/tags/2.7.0rc1 1. Fixed version number 2. Set VERSION to 2.7.0 I can't seem to find these commits in any branch, not 2.7.x, nor master. Am I going crazy or is there something else going on? :/ On Fri, Apr 19, 2013 at 2:34 PM, Tim Kim timki...@gmail.com wrote: Done and done. On 19 April 2013 14:21, Filip Maj f...@adobe.com wrote: Probably a retag since we use the contents of VERSION to interpolate the framework version string into the JS-only platforms' JS. On 4/19/13 2:16 PM, Tim Kim timki...@gmail.com wrote: Hey gang, I noticed that the 2.7.0rc1 tag commit for Cordova JS sets the version to just 2.7.0: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=d0ffb8 52378ff018bac2f3b12c38098a19b8ce00 Small thing really - should we just force a retag or do something else? -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim -- Timothy Kim
Re: New directory structure in cordova-cli's future branch
Braden I have merged master and the future branch: https://github.com/timkim/plugman/tree/future_master_merge I think it's about ready to merge back in to future. I've gotten the android-one-install and the ios-config-xml-install (minus one weird test I don't understand) working. On 10 April 2013 14:42, Anis KADRI anis.ka...@gmail.com wrote: As far as I am concerned I don't really have a strong opinion on this topic. As I said in the previous thread, I do like this new directory structure and if you have it there and tested then fine. We break shit all the time it's not like this change is one too many. What matters is to communicate it to our users and give them an upgrade path to this new app structure (the Cordova docs are a good place for that). However, I agree with Brian that there are more important things to tackle right now. Now sure what you had on your list but since js only modules are in Plugman right now (untested) The next big thing that is going to be non-trivial is: plugin dependencies (which will in some ways involve discovery I think). We should have a discussion about that (hangout, IRC, connect...whatever). I have a couple of ideas about that. Tim is working on fixing/adding/updating plugman tests and it looks like he's making good progress on it. -a On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf michael.w...@cynergy.com wrote: +1 I get the intention, however anything we can do to reduce this type of breaking change should be done. These type of changes should be considered for major releases only so users can plan for them. mw On 4/9/13 5:05 PM, Jesse purplecabb...@gmail.com wrote: +1 to the sanity plea of devgeek Tommy Also, if it didn't happen on this list, 'Consensus' should always be tracked back to a thread here, regardless of meetings, hangouts, irc, bbs, ... @purplecabbage risingj.com On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos Williams to...@devgeeks.orgwrote: Sorry, but as someone that helps users everyday, the almost it's alpha, they shoulda seen it coming tone of this is a bit upsetting. It reminds me of before the deprecation policy, etc when PhoneGap would completely break everything whenever a new version came out. I feel like we have come a long way since then (with a ways still to go, no question about it). I would hate to be the one in IRC and on the Google Group list having to explain this to everyone using the cli. I was under the impression that the cli was shipping now, not just a little side thing. I know that quite a few people are using it for real apps (myself included). If that is true, then we have a duty to at least think very carefully before breaking something and come up with a good plan for easing that transition. - tommy On 10/04/2013, at 1:40, Braden Shepherdson bra...@chromium.org wrote: This mailing list post is, or will shortly be, indexed by Google and others. Any newcomers will see the new docs and create new projects. As I mentioned on IRC, existing users are either accepting or ignoring the alpha warnings that this software is new and under heavy development, and if they want to jump on it early they're going to have to expect some pain. That said, I don't really know of any better way to socialize it. Is there anywhere where a brief blog post on this would make sense? I don't know how many people are using these tools and not on the mailing list, though certainly some turn up on IRC occasionally. Braden On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj f...@adobe.com wrote: How will we communicate this change to our existing users? On 4/9/13 5:22 PM, Braden Shepherdson bra...@chromium.org wrote: I've just pushed a change to the future branch that changes the directory structure to: app/ merges/ android/ ios/ www/ config.xml As was discussed at our video conference meeting a couple of weeks ago, this has a number of advantages: - config.xml is no longer in the www/ directory - One can easily version control the whole app/ directory, and get their web assets, merges and so on into the repo. - That repo can contain additional information: a README.md, supplementary documentation, tests, whatever. The CLI will ignore anything outside of the merges and www directories. The downside is that this is a breaking change: running the new version of the tools on an old project will fail (but I think in a harmless way) until you rearrange the directories. You can do that with the following commands: $ mkdir app $ mv www/config.xml app $ mv www app $ mv merges app All docs and tests are updated as well. Any problems should be
Re: BlackBerry BB10 Repos on GitHub
Awesome! On 6 April 2013 08:16, Ken Wallis kwal...@blackberry.com wrote: So awesome to see this go live, thanks Bryan. Looking forward to seeing progress towards this being merged into the Apache repos! Sent from my BlackBerry Z10 smartphone. From: Bryan Higgins Sent: Saturday, April 6, 2013 6:42 AM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: BlackBerry BB10 Repos on GitHub Over the last few weeks, we at BlackBerry WebWorks have been working on a prototype for a new version of our SDK based on Cordova. I'm happy to say that we're now able to share our repos publicly! To understand what we've done, you will first need to understand that WebWorks for BB10 is really 3 things: 1. Packager (bbwp) – a set of node scripts to assemble apps from source 2. Framework – handles bootstrap, extension loading, exec calls, events 3. Extensions – all of the APIs. Similar to cordova plugins, but included in the SDK rather than directly in the project. All of this is built on top of the web platform - a layer on top of WebKit which exposes device APIs. We plan to document this layer and provide instructions on how to build a web platform app using only the NDK. For those wanting a rich set of APIs, we will provide a Cordova build along with a set of custom plugins for platform features. To get to that world, we need to move some logic from the packager and framework into Cordova. This will really simplify the exec chain and ease plugin development. Old world: Plugin script cordova.exec WebWorks extension webworks.exec web platform / native New world: Plugin script cordova.exec web platform / native All of our repos are up at github.com/blackberry. Here's a quick summary of what we have done so far. https://github.com/blackberry/cordova-blackberry * split out BB10 from BBOS/PlayBook * Re-implemented cordova create, build and run in node, using libs from our packager * Introduced target script for managing device and simulator configuration * Started the process of converting core plugins from wrappers to calling web platform directly https://github.com/blackberry/cordova-js * Created blackberry10 as a top level platform * Added some bootstrap, exec and event logic from our Framework * Started the process of removing the wrappers (at which point cordova.exec and webworks.exec are merged and webworks events will go away) https://github.com/blackberry/cordova-plugman * Copy controller code (index.js) and native .so files into the project * Implemented our prototype of script injection (wrapping js-modules in cordova.define and generating plugins.json). https://github.com/blackberry/cordova-cli * Minor changes to support splitting out BB10 from BBOS https://github.com/blackberry/cordova-blackberry-plugins (not yet public,) * Plugins for BB10 platform features I know this is a lot of dump on the list at once, but Jeff and I are here to answer any questions or concerns. Now that the repos are live we'd like to start a discussion on getting the code into Apache. We've got a small team here working on this (intros to come) and everyone is excited to start working with the community. Cheers, Bryan - 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. -- Timothy Kim
Plugman Future Qs
Hey Braden, I'm working on getting the plugman future branch tests running and I noticed a couple of things: 1) Removal of moving the assets to the www/: https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=commit;h=eeb5f0104f449ae5cac6045786874559fe1edf50 Are we not doing this anymore? 2) Unable to fetch a plugin by name. ie, plugman --fetch --plugin ChildBrowser --plugins_dir Foo I've got a fix for this to work in a branch here: https://github.com/timkim/plugman/commit/919f67fc386f4bd080ca67088e767a3190a36461 But I am hesitant to merge it back since it kinda changes the flow of how fetch works and maybe you had something different in mind. Let me know what you think. -- Timothy Kim
Re: InAppBrowser support on BlackBerry Windows Phone
Hrm, not sure. I'll have to check on monday on device. On 23 March 2013 11:11, Andrew Grieve agri...@google.com wrote: bump On Wed, Mar 20, 2013 at 4:16 PM, Andrew Grieve agri...@google.com wrote: The docs: http://cordova.apache.org/docs/en/edge/cordova_inappbrowser_inappbrowser.md.html#InAppBrowser 1. Say that Blackberry does not support events, nor the close() function 2. Say that windowsphone 7 8 support IAB. Are both of these statements correct? I don't see IAB in the WP JS... -- Timothy Kim
Re: [Plugins] Changes to plugman
Speaking of logos, I was planning on making another 8 bit sticker for the next PhoneGap day. The PlugMan character is still in the works :D [image: Inline images 1] +1 for the future md as well. It looks great. I'm also working on a branch of cordova cli trying to get it integrating with plugman that fetches plugins from a git repo. I hope to have a working prototype by the end of the week. On 20 March 2013 11:33, Filip Maj f...@adobe.com wrote: Plugman operates on its own. The CLI consumes it as the tool to handle plugins. Plugman has a full, detailed API of its own. Check out the read me. It handles install and uninstall of plugins based on the plugins.xml spec (which is also in the plugman read me). Cordova-cli offers a basic abstraction above plugman. Since the CLI helps you manage cross-platform apps, it is more aware of which platforms it should attempt to install a plugin into. As for specific usage, cordova-cli would shell out to plugman after you would call: $ cordova plugin add url or path-to-plugin Assuming your cordova-cli-generated project had Android and iOS as its added platforms, the above call would translate into: $ plugman install --project platforms/android --platform android url or path $ plugman install --project platforms/ios --platform ios url or path Hope that makes sense. On 3/20/13 10:23 AM, Lorin Beer lorin.beer@gmail.com wrote: Great, thanks Braden! So plugman operates more as a backend to the CLI? If I wanted a plugin included, I'd throw it in the CLI plugins/ dir and the CLI through Plugman woud take it from there? I imagined an NA grounded I imagined a NA grounded plug https://www.google.com/url?sa=irct=jq=esrc=ssource=imagescd=cad =rjadocid=LZzHSJgdGBpr0Mtbnid=O299eBU1KAZ6JM:ved=0CAUQjRwurl=http%3A%2 F%2Fwww.wisegeek.org %2Fwhat-are-the-electrical-voltage-differences-between -the-us-and-europe.htmei=l-9JUbvpKe7jigLA8YCIAgbvm=bv.44158598,d.cGEpsi g=AFQjCNGE0d1I2yGzCHTxPgvdYHQqjCBFZgust=1363886348082647 But Anis did grow up in France http://www.google.com/url?sa=isource=imagescd=cad=rjadocid=TeI7 sFRh2DL7AMtbnid=HoArjxZRAIAi3M:ved=0CAgQjRwwAAurl=http%3A%2F%2Fwww.123r f.com %2Fphoto_4151089_black-plug-european-style.htmlei=yu9JUeOTLaOWiAL0lo GABwpsig=AFQjCNEaRNYCxpENPL7m6ConosBhTOIMzAust=1363886410772823 Then again... https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTQfboXDim8_ w9v50LL9pl-geYFPhEL1A_nhEMIjdrS1-gtDqrH On Wed, Mar 20, 2013 at 9:32 AM, Shazron shaz...@gmail.com wrote: That logo definitely needs to happen. But... what type of plug ;) On Wed, Mar 20, 2013 at 8:45 AM, Braden Shepherdson bra...@chromium.org wrote: That logo needs to happen. plugman is the tool for downloading plugins, for inserting their config file changes, installing their native code, and arranging for their JS modules to be loaded at runtime. cordova-cli is the tool for managing multiple platforms with one www directory to rule them all. It uses plugman to do most of the heavy lifting, pointing plugman at its plugins/ directory and each of its platforms/foo directories in turn. Note that I'm speaking normatively here; the current situation is a bit more of a mess. FUTURE.md is intended to show the route out of the mess. Braden On Wed, Mar 20, 2013 at 11:04 AM, Lorin Beer lorin.beer@gmail.com wrote: cool stuff, guys, +1. Read through FUTURE.md, sounds great! quick question: this is a general plugin manager, for third party plugins as well as core plugins? HA! Plugman, with 'man' for 'manager', I just now got that. And here I was envisioning Anis dressed up as a superhero with a giant 3-prong AC plug for a helmet. On Wed, Mar 20, 2013 at 7:39 AM, Jeffrey Heifetz jheif...@blackberry.com wrote: +11 I really like the plan On 13-03-20 10:23 AM, Andrew Grieve agri...@chromium.org wrote: Read through FUTURE.md. Like it! Sounds amazing! Great work guys! On Tue, Mar 19, 2013 at 5:02 PM, Filip Maj f...@adobe.com wrote: For those unaware, cordova-plugman [1] is a tool under active development that will be responsible for all the plugin things. Braden, Anis and I are actively working on getting this tool to a working state, after which we will more completely integrate with cordova-cli. Braden is currently tackling JavaScript installation into a platform's www folder. This uses cordova.js' baked-in clobbers/merges functionality to attach JS modules to specific global namespaces. Some of the bigger changes include: - splitting out plugman install functionality into two separate steps, one for handling JS and the other for handling native installs. - plugins (at the minimum, the plugin manifest) will be stored
Re: [Plugins] Plugin versioning
+1
However, I think we may need a better property/value pair name than
just cordova_version:
plugin_versions. This is because I feel like there is a implicit idea that
this particular plugin will work on a specific version of Cordova, but for
all platforms. Whereas in reality, most of the plugins out there are just
for iOS and Android. So maybe if the mapping was more like:
{
cordova_version: {
android: android_plugin_version,
blackberry: blackberry_plugin_version,
ios: ios_plugin_version
}
}
I think this also takes care of if a plugin adds in another platform but in
a later version.
On 19 March 2013 07:59, Anis KADRI anis.ka...@gmail.com wrote:
Hey all,
Plugins need to be versioned to be backward compatible with previous
versions of Cordova. I had a discussion with the PhoneGap:Build team
yesterday and they need to be backward compatible. Ally Ogilvie also
mentioned in separate thread that game developers would also need something
like this.
We have already broken the plugin interface a number of times and we know
that a plugin implementation won't work across all versions of Cordova.
The plugin spec already supports an engine tag to specify which versions
of cordova it supports. However, It's expensive to clone down the
repository just to check if the plugin works or not.
I believe we should store some sort of mapping on our discovery server.
Such as:
{
cordova_version: plugin_versions
}
That way when plugman tries to install a plugin it knows ahead of time
(before cloning the repository) if there is a version of the plugin that
works with the user's version of cordova.
This will probably be less needed after 3.0 when the plugin interface is
stable enough.
Thoughts ?
-a
--
Timothy Kim
Re: Platform-level command line scripts
I agree with the BlackBerry scripts must do. Most of the BlackBerry stuff should be pretty simple. If you took all the existing ant commands and what's in the cordova scripts already, you're most of the way there. However, I'm not sure what log would look like. I think there's a way to ssh your way into the BB10 and get access to the device log which could be pretty useful. However, I haven't been able to do it on my dev alpha (was locked out via file permissions), but maybe the z10 is able to??? On 19 March 2013 17:25, Benn Mapes benn.ma...@gmail.com wrote: Ok just to get this straight, we would like to see these scripts in the cordova directory of a Cordova project. *build* - compiles the project so that it can be deployed (possible flags are debug and release?) *clean* - removes all generated files (are these just the project specific files or the ones generated for the platform as well, i.e CordovaDeploy.exe for windows) *log *- logs device output (not supported yet for windows) *release* - Is this just the equivalent of `build` but in release mode? maybe you can just make this a flag in the build script? *run *- This would handle deploying the already built application to a device or emulator of the users choosing (do we want to prompt for this or use flags to decide?) *emulate* - I like jesse's suggestion that this should be used for *ripple only* * * Cheers, ~Benn On Tue, Mar 19, 2013 at 4:48 PM, Jesse purplecabb...@gmail.com wrote: I agree with Anis, and your easy wins Fil! emulate is confusing, unless emulate is 'ripple only!' I think run should take a parameter which specifies where it should run, defaulting to an attached device perhaps. The cordova-deploy tool for Windows Phone 8 and Windows Phone 7 ( same API, different implementations/requirements/libraries ) has a simple interface where you can call it with -devices and it will simply list targets [1] In this case, the deploy tool is not going to build anything, as it is specifically *just* a deploy tool, but ultimately on WP7+8 this is what the cl tools will use anyway. An approach like this allows you to target multiple emulators ( WP8 has 7 different emulators ) [1] https://github.com/purplecabbage/cordova-wp8/blob/master/tooling/CordovaDeploy/CordovaDeploy/Program.cs#L45 @purplecabbage risingj.com On Tue, Mar 19, 2013 at 4:32 PM, Anis KADRI anis.ka...@gmail.com wrote: I agree with your easy wins. As for the 'emulate' command I don't think it should exist and should be replaced with 'run'. I thought we agreed on it in a previous thread. I believe the way Android does it is the way to go. The issue is to get it to work on iOS with Fruitstrap. Obviously we can't ship FruitStrap with Cordova but we can script it to download it when we use the run command. Don't know anything about BlackBerry but I want to say that there should be a way to detected connected devices without prompting the user, yes ? -a On Tue, Mar 19, 2013 at 3:42 PM, Filip Maj f...@adobe.com wrote: Bringing this up once more, hopefully the last time :) TL;DR: the behavior and naming of the platform-level scripts are still not 100% lined up. I'd like to fix this and agree with you all on some of the finer points surrounding this issue. Benn Mapes, an intern at Adobe, has been working on adding Windows Phone support to cordova-cli. It's been a bit of work, but the first step is to land command line scripts at the Windows Phone project level, which he is actively working on. With this happening, I want to make sure we have our base project-level CLI scripts sorted properly. Additionally, I've been seeing issues filed against the CLI with essentially users being confused as to why the behavior of cordova build vs cordova emulate on different platforms is different [1] [2]. The answer to all of this is that the project-level scripts have slightly different behavior. I've looked into what each of Android, iOS and BlackBerry (10) do and I've got a basic table sorted out (below). I would like to get to an agreement on naming and behavior for each, and ideally file issues to get as many of our platform implementations as possible to implement/tweak behavior so that we are consistent on this front. Scripts --- - build - Android: equivalent of running `ant debug`, which simply compiles your app in debug mode - BB10: packages your app into a zip, runs `bbwp` on it, and code-signs it - iOS: runs a compilation with xcodebuild with configuration set to Debug - clean - Android: equivalent of running `ant clean`, which removes any build artifacts - BB10: does not exist - iOS: does not exist - log - Android: `adb
Re: Testing MobileSpecTest
Ya I do pretty much that same thing that Fil does but for BlackBerry. I'm not sure where the speed up would be for the BlackBerry side. On 26 February 2013 13:18, Filip Maj f...@adobe.com wrote: I copy over the built cordova.xxx.js file to my project www/ folder as cordova.js and overwrite the loader script that is in mobile-spec currently under cordova.js. Doesn't that solve this problem? I.e. $ cd cordova-android $ ./bin/create ../tmp $ cd ../cordova-js $ jake $ cp pkg/cordova.xxx.js ../tmp/assets/www/cordova.js $ cd ../tmp ./cordova/debug On 2/26/13 11:53 AM, Michal Mocny mmo...@chromium.org wrote: Thanks for heads up. -Michal On Tue, Feb 26, 2013 at 2:40 PM, Michael Brooks mich...@michaelbrooks.cawrote: Perhaps wait for someone to verify that this works on their system. A good number of us are at ApacheCon today and running at half speed. Michael On Tue, Feb 26, 2013 at 11:26 AM, Michal Mocny mmo...@chromium.org wrote: Bump. Is there any opposition to me landing this? It should simplify testingmaking changes to mobile-spec tests on dev work in a way that doesn't hurt normal git workflow. -Michal On Mon, Feb 25, 2013 at 4:00 PM, Michal Mocny mmo...@chromium.org wrote: Actually, got this working, pushed a remote branch for feedback: Commit: http://git-wip-us.apache.org/repos/asf/cordova-mobile-spec/commit/9ec39e9 3 We can add the other platforms, of course, and on windows you can hard link the file, I think? -Michal On Mon, Feb 25, 2013 at 2:59 PM, Michal Mocny mmo...@chromium.org wrote: Yeah I'm trying to prototype what I proposed and I cannot find a way to test for file existence in a sync way, and the mobile spec tests don't deal well with having cordova.js injected after page load. This is solvable but I'll shelve it until I get more feedback/interest expressed. -Michal On Mon, Feb 25, 2013 at 2:43 PM, Jesse MacFadyen purplecabb...@gmail.com wrote: For every version, I do the following for WP7 and WP8 : - create a new project from the latest template - remove the dll and link to the repo project directly - copy over mobile-spec - modify cordova.js to include cordova.windowsphone.js - add visual studio link to cordova-js output pkg version Run tests, debug, fix, rebuild, retest... With this setup, I can modify cordova-js, rebuild and retest, as well as do the same on the native side. Fwiw, I don't think there is a generic solution. Any sim link idea you have is likely gonna fail in windows, and this will ultimately make things more difficult for someone. I could be wrong. Cheers, Jesse Sent from my iPhone5 On 2013-02-25, at 11:15 AM, Michal Mocny mmo...@google.com wrote: How do other devs test mobile spec locally? Specifically, how do you set up your repo to test with your working cordova.js version, in a way that you can make changes to mobile-spec tests, push local changes merge changes coming from remote. I'm always overriding/clearing/overriding the default cordova.js file in order to test/merge/push etc. Proposal: I change the current cordova.js file to: If a local cordova.PLATFORM.js file exists, load that. Otherwise, load cordova-VERSION.js the way we do now. Then, all you have to do is create a local symlink to your cordova.js and never add that file to your git commits. Or, do others already have a good solution? -Michal -- Timothy Kim
Re: Tag 2.5.0rc1?
I've tagged BlackBerry but the media tests still crash the mobile spec auto test. Not much we can do about this right now since we're still waiting on BlackBerry to get back to us on this issue: https://github.com/blackberry/BB10-WebWorks-Framework/issues/606 It also might be the case that this issue is only on the dev alpha devices - I think they have a slightly different OS build if compared to the actual BB10 device (ie, Z10/Q10). However, if you comment out the last three media tests (ie, should return MediaError for bad filename, position should be set properly, and duration should be set properly) it should work properly. On 20 February 2013 14:22, Jesse purplecabb...@gmail.com wrote: CurrentStatus: Resolved my cordova-js issues for WP7, (pulled too many changes in) WP7 it has been tagged. Moving on to WP8. On Wed, Feb 20, 2013 at 1:46 PM, Shazron shaz...@gmail.com wrote: Alright, the two iOS errors (compass error, FileTransfer body error) are deemed harmless, so I will check in the cordova-js for iOS for 2.5.0rc1, and tag iOS 2.5.0rc1. On Wed, Feb 20, 2013 at 1:27 PM, Jesse purplecabb...@gmail.com wrote: CompassHeading is not an exposed API, and I had planned to remove the tests for it. However, there are numerous places where it is used ( throughout cordova-js, I don't believe any native code depends on it's existence ) https://issues.apache.org/jira/browse/CB-1583 ideally duck typing of the value received from compass results is all we need, but numerous implementations are dependent on the parameters in the constructor, so I left it. On Wed, Feb 20, 2013 at 1:22 PM, Filip Maj f...@adobe.com wrote: The compass error is introduced from Gord's latest change. The test that is failing is: if you create a new CompassHeading object with no parameters, it should have defined properties. This commit: https://github.com/apache/cordova-js/commit/6133a7e05bcd2ddc4a15591cf79cda9 65cbaf1ab Breaks that (no parameters are defined leads to properties == undefined) Not a big deal as in practice this won't break anything. We should either remove the test or add more fine-grained checking into compassHeading. On 2/20/13 12:44 PM, Shazron shaz...@gmail.com wrote: The FileTransfer errors should go away once I check in the updated js, which leaves the compass stuff. I'll investigate the compass stuff before committing the updated js. On Wed, Feb 20, 2013 at 12:40 PM, Filip Maj f...@adobe.com wrote: The FileTransferError body property is not implemented yet so that error is fine. The bugs blocking RC are: - The compass ones are new, we should investigate - The FileTransfer is not defined, which was a symbol mapping issue in the JS (which is why all platforms need to grab the new JS test). On 2/20/13 12:37 PM, Shazron shaz...@gmail.com wrote: Don't think these failures should block rc1, but on iOS, I'm getting that plus: Compass (navigator.compass) Compass Heading model (CompassHeading) should be able to create a new CompassHeading instance with no parameters.file:///var/mobile/Applications/DC5AC5B0-AD05-4B67-884F-6D9A 7F CE1D6D/250rc1.app/www/autotest/pages/all.html?spec=Compass%20( navigator.co mpass)%20Compass%20Heading%20model%20(CompassHeading)%20should%20be%20ab le %20to%20create%20a%20new%20CompassHeading%20instance%20with%20no%20param et ers. Expected undefined to be defined. Expected undefined to be defined. Expected undefined to be defined. FileTransfer download method should get response body on failure.file:///var/mobile/Applications/DC5AC5B0-AD05-4B67-884F-6D9A7FC E1 D6D/250rc1.app/www/autotest/pages/all.html?spec=FileTransfer%20download% 20 method%20should%20get%20response%20body%20on%20failure. Expected null to equal 'You requested a 404'. --- Will investigate On Wed, Feb 20, 2013 at 12:33 PM, Becky Gibson gibson.be...@gmail.comwrote: On iOS I'm failing one of the compass tests: CompassHeading should be able to create a new CompassHeading with no parameters. On Wed, Feb 20, 2013 at 3:07 PM, Filip Maj f...@adobe.com wrote: K I've updated the JS tag. Platforms should grab the latest 2.5.0rc1 tag from cordova-js and retag + retest. On 2/20/13 12:02 PM, Shazron shaz...@gmail.com wrote: Not clear (?) but I think so. I suppose all platforms get the new js and re-test, and re-tag. On Wed, Feb 20, 2013 at 11:53 AM, Filip Maj
Re: Proposition to split cordova-blackberry into two separate plugins
I don't mind either way, but I think we should have at least an idea what the cordova-blackberry10 repo should look like before we create it. To separate them right now would mean creating two very similar cordova-blackberry repos (everything the same except some build scripts). And then later on, reconfiguring the cordova-blackberry10 repo to be whatever. So I'm basically for less work now :) Also, on the topic of plugins for BlackBerry 10, I've done some work recently on this that you can check out: Here's my simple plugin that shows the structure for a BB10 plugin with native code: https://github.com/timkim/cordova.echo A tool to build the C++ code from command line: https://github.com/timkim/Renton And plugman now has bb10 support so it should be able to install the cordova.echo plugin: https://github.com/imhotep/plugman On 19 February 2013 14:55, Brian LeRoux b...@brian.io wrote: I'm a little uncertain about the reasoning here. What happens when BB11 ships? New repo? Generally we try to keep things in a vendor directory with the pertinent SDK's within. What is wrong w/ the current structure for contribution? On Tue, Feb 19, 2013 at 2:45 PM, Shazron shaz...@gmail.com wrote: +1 Also, any news when BB10 comes to Playbook, ballpark? -- once BB10 is ported to playbook On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj f...@adobe.com wrote: Sounds fine to me. As for process, assuming there are no objections (would wait a couple days), file a JIRA issue on the INFRA project (issues.apache.org/jira/browser/INFRA) On 2/19/13 1:15 PM, Jeffrey Heifetz jheif...@rim.com wrote: With all this talk of re-organizing cordova plugins we here at BlackBerry (RIM no more) have been discussing better alleging ourselves with the approach by splitting our existing cordova-blackberry platform into two separate platforms. (I saw a similar call here as well http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh pidbnxg5ps7zr+state:results) We propose adding a new platform, blackberry10 with the longterm understanding that once BB10 is ported to playbook the original repo would only be for BBOS. Ideally the end result of this is that we would have an up to date cordova-blackberry10 platform following all of the best practices (plugins moved into their own repos, etc) and we can better contribute resources to Cordova in general. Hopefully no one has any objections to this as structurally they are really separate platforms. Additionally it'll make the flow within CLI a lot cleaner. If everyone agrees, what is the process for getting a new apache repo for it? - 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. -- Timothy Kim
Re: BlackBerry 2.4.0 Release
All right, it looks like everything is re-packaged and working. On 12 February 2013 13:43, Steven Gill stevengil...@gmail.com wrote: +1. On Tue, Feb 12, 2013 at 9:43 AM, Jesse MacFadyen purplecabb...@gmail.com wrote: +1 to repack. Cheers, Jesse Sent from my iPhone5 On 2013-02-12, at 9:36 AM, Brian LeRoux b...@brian.io wrote: Ah crap. Well, my thinking is just repackage it anyhow. (Not a world ending bug tracking nightmare.) On Mon, Feb 11, 2013 at 11:40 PM, Tim Kim timki...@gmail.com wrote: Someone had brought it up through the google groups: https://groups.google.com/forum/#!topic/phonegap/wnICEdCs-Qk/discussion On 11 February 2013 15:24, Brian LeRoux b...@brian.io wrote: Tim, has anyone reported this or are you the only one who has noticed? (if the latter, I say we re-package, if the former we should probably do a retag =( On Mon, Feb 11, 2013 at 10:16 PM, Shazron shaz...@gmail.com wrote: Since it's a low risk change (version number only), I say re-tag, and re-package - who is in charge of the robson tool? File a bug against it Or is the version number not worth it? On Mon, Feb 11, 2013 at 1:16 PM, Tim Kim timki...@gmail.com wrote: Hey gang, So it appears I forgot to push out a commit to update the version number in the BlackBerry repo, but accidently tagged 2.4.0 anyways. Should I force re-tag the repo? Also, the download on phonegap.com for the BlackBerry repo was kinda messed up anyways. In that the robson tool didn't copy over the www/ folder and just the bin/ folder (changed from using ant dist to ./bin/create). Sorry for the mix ups! I was at a conference and was kinda jet lagged when I was attempting to update the repo. -- Timothy Kim -- Timothy Kim -- Timothy Kim
BlackBerry 2.4.0 Release
Hey gang, So it appears I forgot to push out a commit to update the version number in the BlackBerry repo, but accidently tagged 2.4.0 anyways. Should I force re-tag the repo? Also, the download on phonegap.com for the BlackBerry repo was kinda messed up anyways. In that the robson tool didn't copy over the www/ folder and just the bin/ folder (changed from using ant dist to ./bin/create). Sorry for the mix ups! I was at a conference and was kinda jet lagged when I was attempting to update the repo. -- Timothy Kim
[jira] [Commented] (CB-2355) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-2355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571072#comment-13571072 ] Tim Kim commented on CB-2355: - https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=39456ad37f25cc12cc2a2d2b3e35a01e5ca1c582 Update JavaScript for BlackBerry Key: CB-2355 URL: https://issues.apache.org/jira/browse/CB-2355 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.4.0 Update the cordova.js after CordovaJS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2300) ./bin/create script for BlackBerry should employ parameters consistent with other platforms
[
https://issues.apache.org/jira/browse/CB-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569031#comment-13569031
]
Tim Kim commented on CB-2300:
-
Fixed here:
https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=2b68338db80b591430bf4f0ee6424ac68e08f60f
Now need to update docs.
./bin/create script for BlackBerry should employ parameters consistent with
other platforms
---
Key: CB-2300
URL: https://issues.apache.org/jira/browse/CB-2300
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry
Affects Versions: 2.3.0
Environment: mac os
Reporter: Filip Maj
Assignee: Tim Kim
Fix For: 2.4.0
The parameters for ./bin/create on BB are currently:
./bin/create path appname
All other platforms have:
./bin/create path package appname
Additionally, [judging by the config.xml
template|https://github.com/apache/cordova-blackberry/blob/master/bin/templates/project/www/config.xml#L27-L29],
it looks like the APPNAME is used for both the {{widget}} element's {{id}}
parameter as well as the contents of the {{name}} element. This is wrong.
Per the [BlackBerry config.xml
documentation|https://developer.blackberry.com/html5/documentation/widget_element_834671_11.html],
the id is recommended to have a reverse-domain style identifier (just like
iOS and Android), whereas the {{name}} element should have a human-readable
application name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2300) ./bin/create script for BlackBerry should employ parameters consistent with other platforms
[
https://issues.apache.org/jira/browse/CB-2300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Kim resolved CB-2300.
-
Resolution: Fixed
./bin/create script for BlackBerry should employ parameters consistent with
other platforms
---
Key: CB-2300
URL: https://issues.apache.org/jira/browse/CB-2300
Project: Apache Cordova
Issue Type: Bug
Components: BlackBerry
Affects Versions: 2.3.0
Environment: mac os
Reporter: Filip Maj
Assignee: Tim Kim
Fix For: 2.4.0
The parameters for ./bin/create on BB are currently:
./bin/create path appname
All other platforms have:
./bin/create path package appname
Additionally, [judging by the config.xml
template|https://github.com/apache/cordova-blackberry/blob/master/bin/templates/project/www/config.xml#L27-L29],
it looks like the APPNAME is used for both the {{widget}} element's {{id}}
parameter as well as the contents of the {{name}} element. This is wrong.
Per the [BlackBerry config.xml
documentation|https://developer.blackberry.com/html5/documentation/widget_element_834671_11.html],
the id is recommended to have a reverse-domain style identifier (just like
iOS and Android), whereas the {{name}} element should have a human-readable
application name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569116#comment-13569116 ] Tim Kim commented on CB-2287: - I made some updates to the JS. This fixes some but not all of the errors - if you comment out the last three tests in media, it should run okay. https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=d1b4a2002c48cd40aee55fc2ea6335fa5255b905 Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13569132#comment-13569132 ] Tim Kim commented on CB-2287: - Ok, it's in there now. https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=5c3226f32fc8806d058bd05117f3f6b685032186 Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CB-2205) adding Blackberry platform throws an error -- running cordova-client in windows The provided path is not a Cordova BlackBerry WebWorks project
[ https://issues.apache.org/jira/browse/CB-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim reassigned CB-2205: --- Assignee: Filip Maj (was: Tim Kim) adding Blackberry platform throws an error -- running cordova-client in windows The provided path is not a Cordova BlackBerry WebWorks project Key: CB-2205 URL: https://issues.apache.org/jira/browse/CB-2205 Project: Apache Cordova Issue Type: Bug Components: BlackBerry, CLI Affects Versions: 2.2.0 Environment: blackberry, cordova-client Reporter: manu devarunda Assignee: Filip Maj running cordova-client in windows succesfully created cordova project. try to add blackberry platform cordova platform add blackberry getting below error : The provided path is not a Cordova BlackBerry WebWorks project. please let me know what setting I need to change? BR, Manu -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13566919#comment-13566919 ] Tim Kim commented on CB-2287: - I got Gord to help raise an issue on github/irc: https://github.com/blackberry/BB10-WebWorks-Framework/issues/606 I guess we'll just have to wait till someone gets around to it. I'll be merging in my fixes soon. Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13565954#comment-13565954 ] Tim Kim commented on CB-2287: - Ok, I managed to get about all but three tests passing the in Media section without it crashing. The work I've done on that is on the bb_media_fix branch on cordova-js: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=shortlog;h=refs/heads/bb_media_fix As for the last tests, there doesn't seem like anything I can do about them from my side. I've tried a multitude of ways to see if I can get around the double Media/Audio object crash (see my previous message) but to no avail. I have therefore created an issue on the BB issue tracker here: https://www.blackberry.com/jira/browse/BBTEN-772 I'm not certain what we should do in the meantime - in order to get the tests passing and actually not crashing, we may have to take out the media api for bb10 for now. Not the greatest solution, but I can't see how we can mobile spec to even run with this bug. Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13564654#comment-13564654 ] Tim Kim commented on CB-2287: - Ok, so it looks like the problem has to do with a few really strange quirks with bb10 and the media tests. First off, the errors do not happen when the remote web inspector is turned on which made this bug particularly troublesome to figure out. In addition, the tests can actually pass every so often. After a lot of key smashing, I figured out that the reason for the crashes are due to a few things. 1) Creating a new Media object: var media1 = new Media(); ends up creating an Audio object which is where the real problem lies. Every time a new Media object is made, the parameters for the src for the Audio object will default to undefined unless specified in the Media() constructor. 2) Creating one Media object (with or without a src) seems to work, but as soon as you create another is where the trouble starts to happen. This is the real head scratcher for me because it seems like something weird is going on with with the way webworks is communicating to the native side. If you create one, it works just fine. But as soon as you create another, then it crashes. However, if you use web inspector and make two Media/Audio objects, that works just fine as well. I'm going to try and see if I make sure the src paramater for the Media object is defined and see where that gets me. Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560176#comment-13560176 ] Tim Kim commented on CB-2287: - I think it's due to the Media section. I just tried running each test of the auto test individually and Media was the one that blacked out and failed. Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2287) Mobile-spec freezes on BlackBerry 10 around test #200
[ https://issues.apache.org/jira/browse/CB-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13560194#comment-13560194 ] Tim Kim commented on CB-2287: - Hrm, I was playing around in web inspector and did g = new Media(); at the index.html of the mobile spec page. Then went to the auto-test media section and it worked. Maybe the way jasmine is calling the Media object is overloading the internals of bb10? Mobile-spec freezes on BlackBerry 10 around test #200 - Key: CB-2287 URL: https://issues.apache.org/jira/browse/CB-2287 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.4.0 Environment: 2.4.0rc1 Reporter: Filip Maj Assignee: Tim Kim Priority: Blocker Fix For: 2.4.0 Around test #200 (once on test 195, once on test 194) mobile-spec stops running. I can still scroll up and down, but the rendering is incomplete and the tests stop advancing. This is a blocker bug as we have no confidence whether we are regressing or not until mobile-spec can run. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: mobile spec pass rate sizable drop on android
The relevant bug for it is here: https://issues.apache.org/jira/browse/CB-2167 There are sub-bugs for BB and WP. Not sure if anyone has the intention of addressing this for this release? I've been busy working on some plugman stuff so I won't be able to get to the BB one for this release.
[jira] [Resolved] (CB-2247) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-2247. - Resolution: Fixed Update JavaScript for BlackBerry Key: CB-2247 URL: https://issues.apache.org/jira/browse/CB-2247 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.4.0 Update the cordova.js after CordovaJS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2247) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559264#comment-13559264 ] Tim Kim commented on CB-2247: - Fixed here: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=969ad9645022cf6e829a537305b0c4b9c7327309 Update JavaScript for BlackBerry Key: CB-2247 URL: https://issues.apache.org/jira/browse/CB-2247 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.4.0 Update the cordova.js after CordovaJS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2257) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13559267#comment-13559267 ] Tim Kim commented on CB-2257: - Fixed here: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=415d116ea7f29c6aef598213467d5fe3a3f90ea2 Tag BlackBerry -- Key: CB-2257 URL: https://issues.apache.org/jira/browse/CB-2257 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.4.0 After updating the JavaScript and sample application, the release can be tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2257) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-2257. - Resolution: Fixed Tag BlackBerry -- Key: CB-2257 URL: https://issues.apache.org/jira/browse/CB-2257 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.4.0 After updating the JavaScript and sample application, the release can be tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1868) bb min reqs
[ https://issues.apache.org/jira/browse/CB-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547354#comment-13547354 ] Tim Kim commented on CB-1868: - Apparently this was done quite some time ago in this commit: https://git-wip-us.apache.org/repos/asf?p=cordova-docs.git;a=blob;f=docs/en/1.6.0/guide/getting-started/blackberry/index.md;h=cf4d131ec9d4fb114edf4339e12ab6a499cf9a6d;hb=72364fb9989a35f16fe7b1c43ad7d7762df142f0 bb min reqs --- Key: CB-1868 URL: https://issues.apache.org/jira/browse/CB-1868 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry, Docs Affects Versions: 2.3.0 Reporter: Brian LeRoux Assignee: Tim Kim Fix For: 2.3.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1868) bb min reqs
[ https://issues.apache.org/jira/browse/CB-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1868. - Resolution: Fixed bb min reqs --- Key: CB-1868 URL: https://issues.apache.org/jira/browse/CB-1868 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry, Docs Affects Versions: 2.3.0 Reporter: Brian LeRoux Assignee: Tim Kim Fix For: 2.3.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1283) Investigate Webwork's Implementation of File System on Playbook
[ https://issues.apache.org/jira/browse/CB-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547406#comment-13547406 ] Tim Kim commented on CB-1283: - Doing some gardening here and setting this to closed until Playbook implements a full featured HTML5 file api. Investigate Webwork's Implementation of File System on Playbook --- Key: CB-1283 URL: https://issues.apache.org/jira/browse/CB-1283 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.1.0 Environment: It appears that the webworks api now provides full support for html 5 file operations: https://developer.blackberry.com/html5/apis/file.html It might be more worthwhile to switch to this implementation rather than our own solution. Reporter: Tim Kim Assignee: Tim Kim Priority: Minor -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1251) Create Contacts Api for Playbook
[ https://issues.apache.org/jira/browse/CB-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13547416#comment-13547416 ] Tim Kim commented on CB-1251: - The api needed to get contacts still hasn't been exposed. Setting this one to closed until it finally lands. Create Contacts Api for Playbook Key: CB-1251 URL: https://issues.apache.org/jira/browse/CB-1251 Project: Apache Cordova Issue Type: Improvement Components: BlackBerry Affects Versions: 2.0.0 Environment: Playbook Reporter: Tim Kim Assignee: Tim Kim It appears that the Contacts api can be mapped to the blackberry invoke function: https://developer.blackberry.com/html5/apis/blackberry.invoke.addressbookarguments.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1251) Create Contacts Api for Playbook
[ https://issues.apache.org/jira/browse/CB-1251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1251. - Resolution: Unresolved Create Contacts Api for Playbook Key: CB-1251 URL: https://issues.apache.org/jira/browse/CB-1251 Project: Apache Cordova Issue Type: Improvement Components: BlackBerry Affects Versions: 2.0.0 Environment: Playbook Reporter: Tim Kim Assignee: Tim Kim It appears that the Contacts api can be mapped to the blackberry invoke function: https://developer.blackberry.com/html5/apis/blackberry.invoke.addressbookarguments.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: test of BB on 2.3.0?
I ran it. I think I forgot to to post to that 2.3.0 thread that I did. On 4 January 2013 07:13, Marcel Kinard cmarc...@gmail.com wrote: Just curious, did someone run mobile-spec on BB for 2.3.0? Drew wasn't able to get to that task. -- Marcel Kinard -- Timothy Kim
[jira] [Resolved] (CB-2120) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-2120. - Resolution: Fixed Update JavaScript for BlackBerry Key: CB-2120 URL: https://issues.apache.org/jira/browse/CB-2120 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.3.0 Update the cordova.js after CordovaJS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2142) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-2142. - Resolution: Fixed Tag BlackBerry -- Key: CB-2142 URL: https://issues.apache.org/jira/browse/CB-2142 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.3.0 After updating the JavaScript and sample application, the release can be tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2142) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-2142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13543348#comment-13543348 ] Tim Kim commented on CB-2142: - Fixed here: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=1420a0cf04972d79be0b970115a1cb1e5ee61eae Tag BlackBerry -- Key: CB-2142 URL: https://issues.apache.org/jira/browse/CB-2142 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Filip Maj Assignee: Tim Kim Fix For: 2.3.0 After updating the JavaScript and sample application, the release can be tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CB-2105) Mis-linked getting started guide for BlackBerry
Tim Kim created CB-2105: --- Summary: Mis-linked getting started guide for BlackBerry Key: CB-2105 URL: https://issues.apache.org/jira/browse/CB-2105 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.3.0 Reporter: Tim Kim Assignee: Michael Brooks Priority: Trivial -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2105) Mis-linked getting started guide for BlackBerry
[ https://issues.apache.org/jira/browse/CB-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542322#comment-13542322 ] Tim Kim commented on CB-2105: - A minor spelling change changed the link to the getting started guide for BlackBerry. Mis-linked getting started guide for BlackBerry --- Key: CB-2105 URL: https://issues.apache.org/jira/browse/CB-2105 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.3.0 Reporter: Tim Kim Assignee: Michael Brooks Priority: Trivial -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Correct spelling for Blackberry?
Thanks for the catch, Becky! Should be fixed now. On 2 January 2013 11:26, Ken Wallis kwal...@rim.com wrote: Confirmed, 'BlackBerry' -- Ken Wallis Product Manager – BlackBerry WebWorks Research In Motion (905) 629-4746 x14369 From: Filip Maj [f...@adobe.com] Sent: Wednesday, January 02, 2013 2:21 PM To: dev@cordova.apache.org Subject: Re: Correct spelling for Blackberry? I believe it is 'BlackBerry' ( ) On 1/2/13 11:17 AM, Becky Gibson gibson.be...@gmail.com wrote: Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803 c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky - 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. -- Timothy Kim
Re: Correct spelling for Blackberry?
Oh - I created one already and fixed it. Do we actually need to rename the directory? I thought we just needed the list of headers in this file docs/en/edge/guide/getting-started/index.md needed to match the new spelling change. On 2 January 2013 11:29, Becky Gibson gibson.be...@gmail.com wrote: Ok, thanks, I've created a ticket in for the docs: https://issues.apache.org/jira/browse/CB-2106 -becky On Wed, Jan 2, 2013 at 2:26 PM, Ken Wallis kwal...@rim.com wrote: Confirmed, 'BlackBerry' -- Ken Wallis Product Manager – BlackBerry WebWorks Research In Motion (905) 629-4746 x14369 From: Filip Maj [f...@adobe.com] Sent: Wednesday, January 02, 2013 2:21 PM To: dev@cordova.apache.org Subject: Re: Correct spelling for Blackberry? I believe it is 'BlackBerry' ( ) On 1/2/13 11:17 AM, Becky Gibson gibson.be...@gmail.com wrote: Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803 c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky - 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. -- Timothy Kim
Re: Correct spelling for Blackberry?
Ok cool :) On 2 January 2013 11:45, Becky Gibson gibson.be...@gmail.com wrote: Whatever works! I always forget how the docs magic works until I have to make a change. Thanks. On Wed, Jan 2, 2013 at 2:37 PM, Tim Kim timki...@gmail.com wrote: Oh - I created one already and fixed it. Do we actually need to rename the directory? I thought we just needed the list of headers in this file docs/en/edge/guide/getting-started/index.md needed to match the new spelling change. On 2 January 2013 11:29, Becky Gibson gibson.be...@gmail.com wrote: Ok, thanks, I've created a ticket in for the docs: https://issues.apache.org/jira/browse/CB-2106 -becky On Wed, Jan 2, 2013 at 2:26 PM, Ken Wallis kwal...@rim.com wrote: Confirmed, 'BlackBerry' -- Ken Wallis Product Manager – BlackBerry WebWorks Research In Motion (905) 629-4746 x14369 From: Filip Maj [f...@adobe.com] Sent: Wednesday, January 02, 2013 2:21 PM To: dev@cordova.apache.org Subject: Re: Correct spelling for Blackberry? I believe it is 'BlackBerry' ( ) On 1/2/13 11:17 AM, Becky Gibson gibson.be...@gmail.com wrote: Note that this commit, https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803 c3f161830656, to cordova-docs breaks the link to the blackberry file on the Getting Started page because it changes the case of the second b in BlackBerry. I didn't fix it because I'm not sure what the correct spelling is. -becky - 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. -- Timothy Kim -- Timothy Kim
Re: Expect some minor JIRA spam..
I couldn't resist. http://qkme.me/3sew80 On 2 January 2013 11:56, Filip Maj f...@adobe.com wrote: I am working out some kinks in a script I am putting together to create the JIRa issues for tagging a release (instead of spending ~20 mins every release manually doing that). Therefore, expect some issues to be created/deleted in JIRa over the next couple hours. Apologies in advance. Once it's in a usable state I'll toss it into cordova-labs under a jira branch. -- Timothy Kim
[jira] [Commented] (CB-2106) BlackBerry Getting Started link broken
[ https://issues.apache.org/jira/browse/CB-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542565#comment-13542565 ] Tim Kim commented on CB-2106: - This is a clone of this issue which has been resolved. https://issues.apache.org/jira/browse/CB-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13542323#comment-13542323 BlackBerry Getting Started link broken -- Key: CB-2106 URL: https://issues.apache.org/jira/browse/CB-2106 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Michael Brooks Fix For: 2.3.0 This recent commit breaks the link to the BlackBerry getting started guide on the Getting Started page: https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803c3f161830656. Will need to either back out the fix or rename the directories so that the case for BlackBerry is correct in order for all docs linking magic to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2106) BlackBerry Getting Started link broken
[ https://issues.apache.org/jira/browse/CB-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-2106. - Resolution: Duplicate BlackBerry Getting Started link broken -- Key: CB-2106 URL: https://issues.apache.org/jira/browse/CB-2106 Project: Apache Cordova Issue Type: Bug Components: Docs Affects Versions: 2.3.0 Reporter: Becky Gibson Assignee: Michael Brooks Fix For: 2.3.0 This recent commit breaks the link to the BlackBerry getting started guide on the Getting Started page: https://github.com/apache/cordova-docs/commit/7b1c42c4dd5aafb6e132830ed803c3f161830656. Will need to either back out the fix or rename the directories so that the case for BlackBerry is correct in order for all docs linking magic to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1987) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532708#comment-13532708 ] Tim Kim commented on CB-1987: - Fixed here: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=750cda981420238c0d923f4c83814f0f4aaf4cec Update JavaScript for BlackBerry Key: CB-1987 URL: https://issues.apache.org/jira/browse/CB-1987 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Tim Kim Fix For: 2.3.0 Update the cordova.js after Cordova-JS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1987) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1987. - Resolution: Fixed Update JavaScript for BlackBerry Key: CB-1987 URL: https://issues.apache.org/jira/browse/CB-1987 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Tim Kim Fix For: 2.3.0 Update the cordova.js after Cordova-JS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1996) Update www/ Application for BlackBerry
[
https://issues.apache.org/jira/browse/CB-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532711#comment-13532711
]
Tim Kim commented on CB-1996:
-
Fixed here:
https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=c7f84df7b16e1c0cbc0f672dc90606146d5a74b7
Update www/ Application for BlackBerry
--
Key: CB-1996
URL: https://issues.apache.org/jira/browse/CB-1996
Project: Apache Cordova
Issue Type: Sub-task
Components: BlackBerry
Affects Versions: 2.3.0
Reporter: Michael Brooks
Assignee: Tim Kim
Fix For: 2.3.0
Update the www/ sample application after App-Hello-World has been tagged.
*IMPORTANT*: Remove the irrelevant platforms from {{www/res/icon}} and
{{www/res/screen}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1996) Update www/ Application for BlackBerry
[
https://issues.apache.org/jira/browse/CB-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Kim resolved CB-1996.
-
Resolution: Fixed
Update www/ Application for BlackBerry
--
Key: CB-1996
URL: https://issues.apache.org/jira/browse/CB-1996
Project: Apache Cordova
Issue Type: Sub-task
Components: BlackBerry
Affects Versions: 2.3.0
Reporter: Michael Brooks
Assignee: Tim Kim
Fix For: 2.3.0
Update the www/ sample application after App-Hello-World has been tagged.
*IMPORTANT*: Remove the irrelevant platforms from {{www/res/icon}} and
{{www/res/screen}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-2005) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13532712#comment-13532712 ] Tim Kim commented on CB-2005: - Fixed here: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=d1a3abd9000b4378fa40ee7d0075ada65fd26a89 Tag BlackBerry -- Key: CB-2005 URL: https://issues.apache.org/jira/browse/CB-2005 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Tim Kim Fix For: 2.3.0 After updating the JavaScript and sample application, the release can be tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-2005) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-2005. - Resolution: Fixed Tag BlackBerry -- Key: CB-2005 URL: https://issues.apache.org/jira/browse/CB-2005 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Tim Kim Fix For: 2.3.0 After updating the JavaScript and sample application, the release can be tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Tagging 2.3.0rc2?
BB tagged. To note: I'm running into some problems with bb10 (problems with some of the apis not being loaded), but others haven't been able to reproduce so I'm still not sure if it's just me. On 14 December 2012 12:04, Shazron shaz...@gmail.com wrote: iOS is tagged 2.3.0rc2 (with 2 File API tests failing, as explained in another thread) On Thu, Dec 13, 2012 at 5:21 PM, Tim Kim timki...@gmail.com wrote: I'm also running into some errors with bb10 and discussing some webworks trouble shooting with RIM. On 13 December 2012 17:13, Shazron shaz...@gmail.com wrote: See thread mobile-spec failures on iOS 6.0.0 - iOS can't proceed unless we get some consensus. On Thu, Dec 13, 2012 at 4:59 PM, Leutwyler, Markus markus.leutwy...@hp.comwrote: When will we cut 2.3.0rc2? Herm: I have added functionality to support for the menubutton in cordova-js for webOS ... how can I get that into rc2? Markus -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Dienstag, 11. Dezember 2012 22:19 To: dev@cordova.apache.org Subject: Re: Tagging 2.3.0rc2? iOS is almost ready to tag pending testing. Unfortunately most of us are off-site Wednesday so I can only test this Thursday and tag. On Mon, Dec 10, 2012 at 2:25 PM, Anis KADRI anis.ka...@gmail.com wrote: Double the usual spam. Thanks Joe :-) ! On Mon, Dec 10, 2012 at 2:20 PM, Joe Bowser bows...@gmail.com wrote: OK, I'm deleting the duplicates so we don't get confused. Sorry about getting inpatient! On Mon, Dec 10, 2012 at 2:17 PM, Joe Bowser bows...@gmail.com wrote: OH crap, I created a duplicate in our tracker. :( On Mon, Dec 10, 2012 at 2:16 PM, Michael Brooks mich...@michaelbrooks.ca wrote: @Jesse I agree with you timeline. @Joe Yep, let's get the ball rolling. I've created JIRA issue CB-1982 to track our progress: https://issues.apache.org/jira/browse/CB-1982 Go Go Go! Michael On Mon, Dec 10, 2012 at 12:32 PM, Joe Bowser bows...@gmail.com wrote: So, are we getting this ball rolling? On Fri, Dec 7, 2012 at 4:48 PM, Jesse purplecabb...@gmail.com wrote: +me Also, 2.3.0 final will be the last release of the year with everyone hopefully enjoying some time off. Many of the Adobe+Cordova committers will be otherwise occupied much of next week, so it may be best to push the release of 2.3.0 to the middle of the following week, on like the 18th or 19th On Fri, Dec 7, 2012 at 4:37 PM, Anis KADRI anis.ka...@gmail.com wrote: I approve this message On Fri, Dec 7, 2012 at 3:28 PM, Brian LeRoux b...@brian.io wrote: agree On Fri, Dec 7, 2012 at 1:38 PM, Simon MacDonald simon.macdon...@gmail.com wrote: We doing that or going straight to 2.3.0 release? Personally I'd like to see a 2.3.0rc2 on Monday then if no fixes are checked in cut 2.3.0 the following week. Simon Mac Donald http://hi.im/simonmacdonald -- @purplecabbage risingj.com -- Timothy Kim -- Timothy Kim
[jira] [Commented] (CB-1954) Header support for PhoneGap's FileTransfer (Upload)
[ https://issues.apache.org/jira/browse/CB-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510644#comment-13510644 ] Tim Kim commented on CB-1954: - Hey Julien, The fix should be in the next rc release which I believe should be released next week Monday. Header support for PhoneGap's FileTransfer (Upload) Key: CB-1954 URL: https://issues.apache.org/jira/browse/CB-1954 Project: Apache Cordova Issue Type: Improvement Components: BlackBerry Affects Versions: 2.1.0 Reporter: Julien Fougère Assignee: Tim Kim Labels: blackberry, filetransfer On Blackberry, It is impossible to add custom headers(For example basic-auth Authorization header ) via the FileTransfer.upload API. The documentation cleary show a headers attribute in FileUploadOptions: http://docs.phonegap.com/en/2.1.0/cordova_file_file.md.html#FileUploadOptions But theses sources do not implement it: https://github.com/apache/cordova-blackberry-webworks/blob/master/framework/ext/src/org/apache/cordova/http/FileUploader.java https://github.com/apache/cordova-blackberry-webworks/blob/master/framework/ext/src/org/apache/cordova/http/FileTransfer.java This issue has already been fixed on 1.5.0 version for Android, 1.9.0 for iOS and an open issue is still unresolved for WP7. I am opening this one for blackberry platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: WARNING: Updated BlackBerry 10 SDK
On 3 December 2012 18:05, Nukul Bhasin m...@nukulb.com wrote: you will need the OS update, we broke compatibility :( but it was necessary Ah, no worries. That's what beta is for :) Works now! -- Timothy Kim
[jira] [Resolved] (CB-1853) Add device.model to the Device API
[ https://issues.apache.org/jira/browse/CB-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1853. - Resolution: Fixed Add device.model to the Device API -- Key: CB-1853 URL: https://issues.apache.org/jira/browse/CB-1853 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Reporter: Shazron Abdullah Assignee: Tim Kim Fix For: 2.3.0 Add device.model to the Device API. This would identify the exact model of the device, for example iPad2,5 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1954) Header support for PhoneGap's FileTransfer (Upload)
[ https://issues.apache.org/jira/browse/CB-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510212#comment-13510212 ] Tim Kim commented on CB-1954: - Hey there, Thanks for filing the ticket. I've a fix here: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=5598f528f27ca08e95b597a549e124050b718d09 Header support for PhoneGap's FileTransfer (Upload) Key: CB-1954 URL: https://issues.apache.org/jira/browse/CB-1954 Project: Apache Cordova Issue Type: Improvement Components: BlackBerry Affects Versions: 2.1.0 Reporter: Julien Fougère Assignee: Tim Kim Labels: blackberry, filetransfer On Blackberry, It is impossible to add custom headers(For example basic-auth Authorization header ) via the FileTransfer.upload API. The documentation cleary show a headers attribute in FileUploadOptions: http://docs.phonegap.com/en/2.1.0/cordova_file_file.md.html#FileUploadOptions But theses sources do not implement it: https://github.com/apache/cordova-blackberry-webworks/blob/master/framework/ext/src/org/apache/cordova/http/FileUploader.java https://github.com/apache/cordova-blackberry-webworks/blob/master/framework/ext/src/org/apache/cordova/http/FileTransfer.java This issue has already been fixed on 1.5.0 version for Android, 1.9.0 for iOS and an open issue is still unresolved for WP7. I am opening this one for blackberry platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1874) On my BlackBerry 9300, when i use API fileTransfer.Upload, headers are ingnored
[ https://issues.apache.org/jira/browse/CB-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13510213#comment-13510213 ] Tim Kim commented on CB-1874: - Hey there, That's because the set custom headers were not implemented. I've added a fix in this commit: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=5598f528f27ca08e95b597a549e124050b718d09 I should also note that this ticket is a duplicate of https://issues.apache.org/jira/browse/CB-1954#comment-13510212 (or perhaps the other way around). In any case, fixed! Let me know how it works. On my BlackBerry 9300, when i use API fileTransfer.Upload, headers are ingnored --- Key: CB-1874 URL: https://issues.apache.org/jira/browse/CB-1874 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.1.0 Environment: BlackBerry 9300 Cordova 2.1.0 Reporter: Alfredo Assignee: Tim Kim On my BlackBerry 9300, when i use API fileTransfer.Upload, headers are ingnored -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1954) Header support for PhoneGap's FileTransfer (Upload)
[ https://issues.apache.org/jira/browse/CB-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1954. - Resolution: Fixed Header support for PhoneGap's FileTransfer (Upload) Key: CB-1954 URL: https://issues.apache.org/jira/browse/CB-1954 Project: Apache Cordova Issue Type: Improvement Components: BlackBerry Affects Versions: 2.1.0 Reporter: Julien Fougère Assignee: Tim Kim Labels: blackberry, filetransfer On Blackberry, It is impossible to add custom headers(For example basic-auth Authorization header ) via the FileTransfer.upload API. The documentation cleary show a headers attribute in FileUploadOptions: http://docs.phonegap.com/en/2.1.0/cordova_file_file.md.html#FileUploadOptions But theses sources do not implement it: https://github.com/apache/cordova-blackberry-webworks/blob/master/framework/ext/src/org/apache/cordova/http/FileUploader.java https://github.com/apache/cordova-blackberry-webworks/blob/master/framework/ext/src/org/apache/cordova/http/FileTransfer.java This issue has already been fixed on 1.5.0 version for Android, 1.9.0 for iOS and an open issue is still unresolved for WP7. I am opening this one for blackberry platform. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1874) On my BlackBerry 9300, when i use API fileTransfer.Upload, headers are ingnored
[ https://issues.apache.org/jira/browse/CB-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1874. - Resolution: Fixed On my BlackBerry 9300, when i use API fileTransfer.Upload, headers are ingnored --- Key: CB-1874 URL: https://issues.apache.org/jira/browse/CB-1874 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.1.0 Environment: BlackBerry 9300 Cordova 2.1.0 Reporter: Alfredo Assignee: Tim Kim On my BlackBerry 9300, when i use API fileTransfer.Upload, headers are ingnored -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: WARNING: Updated BlackBerry 10 SDK
Oh sorry, I thought you were talking about something else. My mistake! On 3 December 2012 10:42, Josh Soref jso...@rim.com wrote: Tim Kim wrote: Is it? I keep seeing questions being popped up about people looking for webworks.js even if they developing for bb5-7/playbook. Usually they are trying it in ripple and errors out when it can't find it so it leads to some confusion. I wrote: | !-- Don't worry about js/webworks.js if you're aren't developing for bb10 -- Here the comment says js/webworks.js | -script type=text/javascript src=js/webworks.js/script Here the code used to say js/webworks.js, at which point the code and comment agreed. | +script type=text/javascript src=local:///chrome/webworks.js/script This change caused the comment to no longer be in sync with the code, as it now says local:///chrome/webworks.js. Anyone looking for js/webworks.js in the code won't find it. This is roughly a reminder to people please don't forget to update comments when you change nearby lines of code, this applies both to comments which are visible in diff -U3 and in comments which aren't visible in diff -U3, although from my perspective it should have been spotted by a reviewer since it was visible in this case - 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. -- Timothy Kim
Re: WARNING: Updated BlackBerry 10 SDK
Oh wait, realised it was an OS update as well. Let me update that and see if that works! On 3 December 2012 17:08, Tim Kim timki...@gmail.com wrote: Hey Gord, I'm getting some weird errors trying to launch an app on bb10 with the new sdk. The first time I make an app, it installs onto device but fails to launch. Then, when I try to install again, I get an error in the build. The icons for the app shows up on my screen (both on the first and second installs), but clicking em doesn't launch the app. *First time through:* Tims-MacBook-Air:sample timkim$ ./cordova/run qnx Do you have a BlackBerry device connected to your computer? (y/n) y Buildfile: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build.xml qnx: debug-device: generate-cod-name: [echo] Generated name: BLRRRGGH.bar clean: package-app: [mkdir] Created dir: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/widget [copy] Copying 22 files to /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/widget [zip] Building zip: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/BLRRRGGH.zip debug-device: [echo] [echo] If you fill in the qnx.device.pin value you can use debug tokens! [echo] This means you won't have to worry about having a unique version in config.xml every time. [echo] [exec] [INFO]Populating application source [exec] [INFO]Parsing config.xml [exec] [WARN]Failed to find feature with id: org.apache.cordova [exec] [WARN]Failed to find feature with id: blackberry.find [exec] [WARN]Failed to find feature with id: blackberry.identity.phone [exec] [WARN]Failed to find feature with id: blackberry.pim.Address [exec] [WARN]Failed to find feature with id: blackberry.pim.Contact [exec] [WARN]Failed to find feature with id: blackberry.io.file [exec] [WARN]Failed to find feature with id: blackberry.utils [exec] [WARN]Failed to find feature with id: blackberry.io.dir [exec] [WARN]Failed to find feature with id: blackberry.app.event [exec] [WARN]Failed to find feature with id: blackberry.system.event [exec] [WARN]Failed to find feature with id: blackberry.widgetcache [exec] [WARN]Failed to find feature with id: blackberry.media.camera [exec] [WARN]Failed to find feature with id: blackberry.media.microphone [exec] [INFO]Generating output files [exec] [INFO]Info: Package created: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/simulator/BLRRRGGH.bar [exec] [INFO]Info: Package created: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/device/BLRRRGGH.bar [exec] [INFO]Info: Bar signed. [exec] [INFO]BAR packaging complete [exec] Info: Sending request: Install and Launch [exec] Info: Action: Install and Launch [exec] Info: File size: 600415 [exec] Info: Installing BLRRRGGH.gYABgAZ7F9xSC66egvFdt_vTo5g... [exec] Info: Processing 600415 bytes [exec] Info: Progress 100%... [exec] Info: Progress 100%... [exec] actual_dname::BLRRRGGH.gYABgAZ7F9xSC66egvFdt_vTo5g [exec] actual_id::gYABgAZ7F9xSC66egvFdt_vTo5g [exec] actual_version::1.1.0.0 [exec] result::success [exec] Info: Launching BLRRRGGH.gYABgAZ7F9xSC66egvFdt_vTo5g... [exec] Info: done BUILD SUCCESSFUL Total time: 31 seconds *Second time through:* Tims-MacBook-Air:sample timkim$ ./cordova/run qnx Do you have a BlackBerry device connected to your computer? (y/n) y Buildfile: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build.xml qnx: debug-device: generate-cod-name: [echo] Generated name: BLRRRGGH.bar clean: [delete] Deleting directory /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build package-app: [mkdir] Created dir: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/widget [copy] Copying 22 files to /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/widget [zip] Building zip: /Users/timkim/repo/incubator-cordova-blackberry-webworks/dist/sample/build/BLRRRGGH.zip debug-device: [echo] [echo] If you fill in the qnx.device.pin value you can use debug tokens! [echo] This means you won't have to worry about having a unique version in config.xml every time. [echo] [exec] [INFO]Populating application source [exec] [INFO]Parsing config.xml [exec] [WARN]Failed to find feature with id: org.apache.cordova [exec] [WARN]Failed to find feature with id: blackberry.find [exec] [WARN]Failed
Re: WARNING: Updated BlackBerry 10 SDK
Thanks for the heads up, Gord! On 30 November 2012 07:40, Gord Tanner gtan...@gmail.com wrote: The BlackBerry 10 SDK and OS versions were updated this week, this broke compatibility the previous SDK. Until BlackBerry 10 is released we will have to keep on the bleeding edge to ensure device to SDK compatibility. I updated cordova-blackberry to use the new SDK (also use the provided path for webworks.js and took out the task of copying the webworks.js ourselves) https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commitdiff;h=c747a03f7037e85ee81af86530bf6cc126fed5e4 We should make sure that this is in the release notes for the 2.3 release. -- Timothy Kim
[jira] [Commented] (CB-1953) PlayBook's apis weren't being clobbered and thus unaccessible
[ https://issues.apache.org/jira/browse/CB-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13506135#comment-13506135 ] Tim Kim commented on CB-1953: - It appears that this change was the culprit: https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=blobdiff;f=lib/blackberry/platform.js;h=b508bc620a684396fa30684140ad5b90af06309e;hp=0ff9dfe2f4c5091882d62af09b52e3582e042613;hb=a018c4925ed24140febe3bae3b31711b33e61d1a;hpb=99fadd12f74703a58e729664394570956d6ccbe4 PlayBook's apis weren't being clobbered and thus unaccessible - Key: CB-1953 URL: https://issues.apache.org/jira/browse/CB-1953 Project: Apache Cordova Issue Type: Bug Components: BlackBerry Affects Versions: 2.3.0 Reporter: Tim Kim Assignee: Tim Kim Fix For: 2.3.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1909) Update www/ Application for BlackBerry
[
https://issues.apache.org/jira/browse/CB-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505016#comment-13505016
]
Tim Kim commented on CB-1909:
-
https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=6f8f6a76a033001a22f5423783b0165ebbbc7f29
Update www/ Application for BlackBerry
--
Key: CB-1909
URL: https://issues.apache.org/jira/browse/CB-1909
Project: Apache Cordova
Issue Type: Sub-task
Components: BlackBerry
Affects Versions: 2.3.0
Reporter: Michael Brooks
Assignee: Tim Kim
Fix For: 2.3.0
Update the www/ sample application after App-Hello-World has been tagged.
*IMPORTANT*: Remove the irrelevant platforms from {{www/res/icon}} and
{{www/res/screen}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1909) Update www/ Application for BlackBerry
[
https://issues.apache.org/jira/browse/CB-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Kim resolved CB-1909.
-
Resolution: Fixed
Update www/ Application for BlackBerry
--
Key: CB-1909
URL: https://issues.apache.org/jira/browse/CB-1909
Project: Apache Cordova
Issue Type: Sub-task
Components: BlackBerry
Affects Versions: 2.3.0
Reporter: Michael Brooks
Assignee: Tim Kim
Fix For: 2.3.0
Update the www/ sample application after App-Hello-World has been tagged.
*IMPORTANT*: Remove the irrelevant platforms from {{www/res/icon}} and
{{www/res/screen}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CB-1918) Tag BlackBerry
[ https://issues.apache.org/jira/browse/CB-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Kim resolved CB-1918. - Resolution: Fixed Tag BlackBerry -- Key: CB-1918 URL: https://issues.apache.org/jira/browse/CB-1918 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Tim Kim Fix For: 2.3.0 After updating the JavaScript and sample application, the release can be tagged as 2.2.0rc1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CB-1370) Investigate Geolocation failing on Playbook
[ https://issues.apache.org/jira/browse/CB-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505052#comment-13505052 ] Tim Kim commented on CB-1370: - I'm going to be closing this issue. The issues with geolocation seems more to be involved with how the playbook acquires the gps rather than anything that cordova is doing. Investigate Geolocation failing on Playbook --- Key: CB-1370 URL: https://issues.apache.org/jira/browse/CB-1370 Project: Apache Cordova Issue Type: Task Components: BlackBerry Affects Versions: 2.1.0 Environment: Playbook Reporter: Tim Kim Assignee: Tim Kim Fix For: 2.3.0 On google groups there have been reported instances of geolocation constantly timing out. [1][2] So far with my own personal testing, I haven't seen geolocation failing unless certain elements in the config.xml being set properly or some other javascript thing. However, it is possible the error is on our side so this ticket will track what comes out of this. [1]: https://groups.google.com/d/topic/phonegap/QVp379qhfbA/discussion [2]: https://groups.google.com/d/topic/phonegap/VsAFfltRn4Y/discussion -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: tag 2.3.0rc1 this week?
I am running into some issues with the js for bb playbook. I'm still trying to wrap my head around this, but it appears that the requestFileSystem object isn't being clobbered by the blackberry/plugin/air/requestFileSystem one. It instead loads the common one and tried to exec which causes it to die. On the plus side, bb7 seems to work okay. On 27 November 2012 15:57, Herm Wong kingoftheo...@hotmail.com wrote: webos has been tagged 2.3.0rc1. From: simon.macdon...@gmail.com Date: Tue, 27 Nov 2012 12:21:54 -0500 Subject: Re: tag 2.3.0rc1 this week? To: dev@cordova.apache.org I've checked in a fix for the back button problem. Simon Mac Donald http://hi.im/simonmacdonald On Mon, Nov 26, 2012 at 4:24 PM, Simon MacDonald simon.macdon...@gmail.comwrote: Android tagged 2.3.0rc1. Passes mobile-spec automated and manual tests. Except the back button over-ride. That appears to be a regression. Issue opened: https://issues.apache.org/jira/browse/CB-1938 Simon Mac Donald http://hi.im/simonmacdonald On Mon, Nov 26, 2012 at 3:42 PM, Shazron shaz...@gmail.com wrote: iOS tagged 2.3.0rc1. Passes all mobile-spec tests, and InAppBrowser manual tests. On Mon, Nov 26, 2012 at 12:05 PM, Shazron shaz...@gmail.com wrote: I'll get started for iOS/ On Mon, Nov 26, 2012 at 11:28 AM, Anis KADRI anis.ka...@gmail.com wrote: Just tagged JS. First time I do this. I hope I didn't mess anything up. On Mon, Nov 26, 2012 at 11:25 AM, Al Harding alharding...@gmail.com wrote: Perfect; Joe is off today and tomorrow. Thanks Simon! On Mon, Nov 26, 2012 at 11:24 AM, Simon MacDonald simon.macdon...@gmail.com wrote: Once someone does the JS I have volunteered to do Android. On Nov 26, 2012 2:14 PM, Steven Gill stevengil...@gmail.com wrote: Lets tag RC1 today! On Fri, Nov 23, 2012 at 6:17 AM, Brian LeRoux b...@brian.io wrote: :[ On Wed, Nov 21, 2012 at 7:47 PM, Simon MacDonald simon.macdon...@gmail.comwrote: I'll go out on a limb and give a Mark Messier level guarantee that the InAppBrowser for Android will before Monday. Hopefully that reference isn't too painful for any fans of the NJ Devils or whoever the Rangers went on to beat in the Stanley Cup that year. No one ever remembers the losers. Well, maybe their long suffering fans do. *Lights bridge on fire before heading down to the gym.* Simon Mac Donald http://hi.im/simonmacdonald On Wed, Nov 21, 2012 at 2:38 PM, Filip Maj f...@adobe.com wrote: Probably Monday with the states eating turkey from Thursday til Sunday On 11/21/12 11:34 AM, Simon MacDonald simon.macdon...@gmail.com wrote: I'm actively working on InAppBrowser for Android right now. I just pushed manual tests to Mobile Spec and I plan to be done with the code by end of day Thursday. Since everyone I work with will be off tomorrow I expect an interruption free day. When is the tagging day for 2.3.0rc1 Friday? Monday? Simon Mac Donald http://hi.im/simonmacdonald On Wed, Nov 21, 2012 at 2:27 PM, Filip Maj f...@adobe.com wrote: If we can land it for 2.3.0 proper, then I think we should move forward with the rc. On 11/21/12 11:23 AM, Andrew Grieve agri...@chromium.org wrote: I know we try not to hold releases up on features, but I think it will be strange to release 2.3 with InAppBrowser for iOS and not have it on any other platforms. What do you guys think of waiting for https://issues.apache.org/jira/browse/CB-1508 ? On Wed, Nov 21, 2012 at 11:45 AM, Simon MacDonald simon.macdon...@gmail.com wrote: Only a bunch of Canadians would want to tag a new release on American Thanksgiving but... +1 Simon Mac Donald http://hi.im/simonmacdonald On Tue, Nov 20, 2012 at 2:14 PM, Steven Gill stevengil...@gmail.com wrote: +1 On Tue, Nov 20, 2012 at 11:06 AM, Filip Maj f...@adobe.com wrote:
[jira] [Commented] (CB-1900) Update JavaScript for BlackBerry
[ https://issues.apache.org/jira/browse/CB-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13504214#comment-13504214 ] Tim Kim commented on CB-1900: - Updated javascript: https://git-wip-us.apache.org/repos/asf?p=cordova-blackberry.git;a=commit;h=67bc4cd173da1055cb6ea40c0d869d15ae4e97f1 Update JavaScript for BlackBerry Key: CB-1900 URL: https://issues.apache.org/jira/browse/CB-1900 Project: Apache Cordova Issue Type: Sub-task Components: BlackBerry Affects Versions: 2.3.0 Reporter: Michael Brooks Assignee: Tim Kim Fix For: 2.3.0 Update the cordova.js after Cordova-JS has been tagged. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
