Cordova.js now at 2.9.0rc1 for real
As both Jesse and Shaz pointed out, I ran coho to update cordova.js snapshots, but it resulted in them being set to 2.7.0 instead of 2.9.0. This is now fixed (new commits for 2.9.0rc1), and I've updated the coho script to not push by default (so that commits can be inspected). The root problem is that jake is existing without failure and without printing anything to the console. Can anyone else verify if this is happening for them? I debugged it as far as to see that removing the "complainwhitespace" dependency from the "hint" task fixed things, but I don't know why that is.
Re: ios commit: Update JS snapshot to version 2.9.0rc1
ha ha, nice catch. I'll look at this now.
On Tue, Jun 18, 2013 at 7:23 PM, Shazron wrote:
> The version in the js says 2.7.0rc1 :/
>
>
> On Tue, Jun 18, 2013 at 10:49 AM, wrote:
>
> > Updated Branches:
> > refs/heads/master ccf5d88a4 -> d9d77c4fa
> >
> >
> > Update JS snapshot to version 2.9.0rc1
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/cordova-ios/repo
> > Commit:
> http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/d9d77c4f
> > Tree: http://git-wip-us.apache.org/repos/asf/cordova-ios/tree/d9d77c4f
> > Diff: http://git-wip-us.apache.org/repos/asf/cordova-ios/diff/d9d77c4f
> >
> > Branch: refs/heads/master
> > Commit: d9d77c4fa6db02638fa399304d76aab70c66066e
> > Parents: ccf5d88
> > Author: Andrew Grieve
> > Authored: Tue Jun 18 13:49:32 2013 -0400
> > Committer: Andrew Grieve
> > Committed: Tue Jun 18 13:49:32 2013 -0400
> >
> > --
> > CordovaLib/cordova.js | 10 +++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
> > --
> >
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/cordova-ios/blob/d9d77c4f/CordovaLib/cordova.js
> > --
> > diff --git a/CordovaLib/cordova.js b/CordovaLib/cordova.js
> > index 0dc412a..a3d1ae0 100644
> > --- a/CordovaLib/cordova.js
> > +++ b/CordovaLib/cordova.js
> > @@ -1,5 +1,5 @@
> > // Platform: ios
> > -// 2.8.0-0-g6208c95
> > +// 2.7.0rc1-75-g76065a1
> > /*
> > Licensed to the Apache Software Foundation (ASF) under one
> > or more contributor license agreements. See the NOTICE file
> > @@ -19,7 +19,7 @@
> > under the License.
> > */
> > ;(function() {
> > -var CORDOVA_JS_BUILD_LABEL = '2.8.0-0-g6208c95';
> > +var CORDOVA_JS_BUILD_LABEL = '2.7.0rc1-75-g76065a1';
> > // file: lib/scripts/require.js
> >
> > var require,
> > @@ -2383,7 +2383,11 @@ function initRead(reader, file) {
> > reader._error = null;
> > reader._readyState = FileReader.LOADING;
> >
> > -if (typeof file.fullPath == 'string') {
> > +if (typeof file == 'string') {
> > +// Deprecated in Cordova 2.4.
> > +console.warn('Using a string argument with FileReader.readAs
> > functions is deprecated.');
> > +reader._fileName = file;
> > +} else if (typeof file.fullPath == 'string') {
> > reader._fileName = file.fullPath;
> > } else {
> > reader._fileName = '';
> >
> >
>
Re: Release Bugs
It doesn't do cloning but consumes the JIRA rest API I was able to google, to create issues and add subtasks to them. On 6/18/13 4:31 PM, "Andrew Grieve" wrote: >Agree on both fronts! > >I very much dislike that cloning it puts "CLONED" in all the titles. > >I had actually already started moving your tool into coho before I left, >but really only got as far as understanding your code without starting to >integrate it. > > >On Tue, Jun 18, 2013 at 4:07 PM, Filip Maj wrote: > >> Yeh or possibly fold the cordova-labs jira script into the coho >> functionality you've put together Andrew? >> >> On 6/18/13 11:41 AM, "Lorin Beer" wrote: >> >> >cloning the issue is a good solution, but I suggest updating the >>script to >> >reflect Andrew's changes to the release issues. >> > >> > >> >On Tue, Jun 18, 2013 at 10:08 AM, Andrew Grieve >> >wrote: >> > >> >> New release bug: https://issues.apache.org/jira/browse/CB-3906 >> >> >> >> >> >> On Tue, Jun 18, 2013 at 1:02 PM, Andrew Grieve >> >> wrote: >> >> >> >> > Okay, I'm going to close out the auto-created ones and create new >>ones >> >> for >> >> > 2.9 before too much action happens >> >> > >> >> > >> >> > On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI >> >> wrote: >> >> > >> >> >> On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve >>> > >> >> >> wrote: >> >> >> >> >> >> > The bug you created: >>https://issues.apache.org/jira/browse/CB-3857 >> >> >> > - includes platforms that we're not releasing right now >> >> >> > >> >> >> >> >> >> >> >> >> Which means I get spammed for no reason :-) >> >> >> >> >> > >> >> > >> >> >> >>
Re: Release Bugs
Agree on both fronts! I very much dislike that cloning it puts "CLONED" in all the titles. I had actually already started moving your tool into coho before I left, but really only got as far as understanding your code without starting to integrate it. On Tue, Jun 18, 2013 at 4:07 PM, Filip Maj wrote: > Yeh or possibly fold the cordova-labs jira script into the coho > functionality you've put together Andrew? > > On 6/18/13 11:41 AM, "Lorin Beer" wrote: > > >cloning the issue is a good solution, but I suggest updating the script to > >reflect Andrew's changes to the release issues. > > > > > >On Tue, Jun 18, 2013 at 10:08 AM, Andrew Grieve > >wrote: > > > >> New release bug: https://issues.apache.org/jira/browse/CB-3906 > >> > >> > >> On Tue, Jun 18, 2013 at 1:02 PM, Andrew Grieve > >> wrote: > >> > >> > Okay, I'm going to close out the auto-created ones and create new ones > >> for > >> > 2.9 before too much action happens > >> > > >> > > >> > On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI > >> wrote: > >> > > >> >> On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve > > >> >> wrote: > >> >> > >> >> > The bug you created: https://issues.apache.org/jira/browse/CB-3857 > >> >> > - includes platforms that we're not releasing right now > >> >> > > >> >> > >> >> > >> >> Which means I get spammed for no reason :-) > >> >> > >> > > >> > > >> > >
Re: ios commit: Update JS snapshot to version 2.9.0rc1
The version in the js says 2.7.0rc1 :/
On Tue, Jun 18, 2013 at 10:49 AM, wrote:
> Updated Branches:
> refs/heads/master ccf5d88a4 -> d9d77c4fa
>
>
> Update JS snapshot to version 2.9.0rc1
>
>
> Project: http://git-wip-us.apache.org/repos/asf/cordova-ios/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cordova-ios/commit/d9d77c4f
> Tree: http://git-wip-us.apache.org/repos/asf/cordova-ios/tree/d9d77c4f
> Diff: http://git-wip-us.apache.org/repos/asf/cordova-ios/diff/d9d77c4f
>
> Branch: refs/heads/master
> Commit: d9d77c4fa6db02638fa399304d76aab70c66066e
> Parents: ccf5d88
> Author: Andrew Grieve
> Authored: Tue Jun 18 13:49:32 2013 -0400
> Committer: Andrew Grieve
> Committed: Tue Jun 18 13:49:32 2013 -0400
>
> --
> CordovaLib/cordova.js | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
> --
>
>
>
> http://git-wip-us.apache.org/repos/asf/cordova-ios/blob/d9d77c4f/CordovaLib/cordova.js
> --
> diff --git a/CordovaLib/cordova.js b/CordovaLib/cordova.js
> index 0dc412a..a3d1ae0 100644
> --- a/CordovaLib/cordova.js
> +++ b/CordovaLib/cordova.js
> @@ -1,5 +1,5 @@
> // Platform: ios
> -// 2.8.0-0-g6208c95
> +// 2.7.0rc1-75-g76065a1
> /*
> Licensed to the Apache Software Foundation (ASF) under one
> or more contributor license agreements. See the NOTICE file
> @@ -19,7 +19,7 @@
> under the License.
> */
> ;(function() {
> -var CORDOVA_JS_BUILD_LABEL = '2.8.0-0-g6208c95';
> +var CORDOVA_JS_BUILD_LABEL = '2.7.0rc1-75-g76065a1';
> // file: lib/scripts/require.js
>
> var require,
> @@ -2383,7 +2383,11 @@ function initRead(reader, file) {
> reader._error = null;
> reader._readyState = FileReader.LOADING;
>
> -if (typeof file.fullPath == 'string') {
> +if (typeof file == 'string') {
> +// Deprecated in Cordova 2.4.
> +console.warn('Using a string argument with FileReader.readAs
> functions is deprecated.');
> +reader._fileName = file;
> +} else if (typeof file.fullPath == 'string') {
> reader._fileName = file.fullPath;
> } else {
> reader._fileName = '';
>
>
Re: Window line endings
I am confused why I see this in cordova.js -// 2.8.0-0-g6208c95\r +// 2.7.0rc1-75-g76065a1\r We are moving from 2.8.0 to 2.9.0rc1, but the commit looks like were heading back to 2.7.0rc1, it's been a long day already ... @purplecabbage risingj.com On Tue, Jun 18, 2013 at 11:54 AM, Jesse wrote: > > https://git-wip-us.apache.org/repos/asf?p=cordova-wp7.git;a=commitdiff;h=b497a269c09edb2e7e7cdbc49defd80b95d9f927;hp=6f7e2865e39b90c04add0e6366a39e984d665053 > > Whatever, it's fine. > > @purplecabbage > risingj.com > > > On Tue, Jun 18, 2013 at 11:33 AM, Andrew Grieve wrote: > >> I just ran coho and it updated all of the cordova.js snapshots. >> >> Jesse - I think you said that last time this resulted in line-endings >> being >> wrong on the file. Could you confirm this? >> >> If it is a problem, would using a .gitattributes file fix it? >> https://help.github.com/articles/dealing-with-line-endings >> >> Andrew >> > >
Re: [jira] [Created] (CB-3917) CLONE - Tag CLI
So the unfortunate thing about the coho branch+tag script is that it branched off master, not master2, for cordova-cli :( I will delete this branch and rebranch/retag in a bit. On 6/18/13 10:04 AM, "Andrew Grieve (JIRA)" wrote: >Andrew Grieve created CB-3917: >- > > Summary: CLONE - Tag CLI > Key: CB-3917 > URL: https://issues.apache.org/jira/browse/CB-3917 > Project: Apache Cordova > Issue Type: Sub-task > Components: CLI >Reporter: Andrew Grieve >Assignee: Filip Maj > > >This should wait until all platforms are tagged. > >Steps: >1. Update snapshot of repos within cordova-cli >2. Test that basic commands work properly (installing plugins, creating >project, edit / refresh cycle) >3. Test that running CLI on a project created with a previous version of >CLI works as expected >4. Look through all open JIRA bugs targeted at the current version and >either fix or postpone them. >5. Tag (via coho) > >-- >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
Bugs for 2.9.x
Hey I'm going through the process for RC1, and I notice that for Android, there's only one bug marked to be fixed for 2.9.x. If you have anything that you want to get into 2.9.x, please add the fix version for 2.9.x so we can get an idea of what's broken on this release, and whether we can get it in or not. Also, marking things as "In Progress" helps, but not as much as marking the fix version. I'm guessing this may be the case for the other platforms as well. Correct me if I'm wrong! Thanks Joe
Re: Release Bugs
Yeh or possibly fold the cordova-labs jira script into the coho functionality you've put together Andrew? On 6/18/13 11:41 AM, "Lorin Beer" wrote: >cloning the issue is a good solution, but I suggest updating the script to >reflect Andrew's changes to the release issues. > > >On Tue, Jun 18, 2013 at 10:08 AM, Andrew Grieve >wrote: > >> New release bug: https://issues.apache.org/jira/browse/CB-3906 >> >> >> On Tue, Jun 18, 2013 at 1:02 PM, Andrew Grieve >> wrote: >> >> > Okay, I'm going to close out the auto-created ones and create new ones >> for >> > 2.9 before too much action happens >> > >> > >> > On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI >> wrote: >> > >> >> On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve >> >> wrote: >> >> >> >> > The bug you created: https://issues.apache.org/jira/browse/CB-3857 >> >> > - includes platforms that we're not releasing right now >> >> > >> >> >> >> >> >> Which means I get spammed for no reason :-) >> >> >> > >> > >>
Re: Release Masters?
Thanks James! Most of it is on the wiki, and is pretty straightforward: Not surprisingly, I made OS X (almost) the same as iOS in structure as well: http://wiki.apache.org/cordova/IOSReleaseChecklist Some of the task should be covered in the JIRA issues generated I think. On Tue, Jun 18, 2013 at 10:30 AM, James Jong wrote: > Shaz, I haven't done it before but I'll be happy to work with you and help > when you're out for iOS & OS X. FYI for planning, I will be out & away on > vacation June 26-July 15. > -James Jong > > On Jun 18, 2013, at 1:18 PM, Andrew Grieve wrote: > > > Okay, created a new release bug & sub-tasks here: > > https://issues.apache.org/jira/browse/CB-3906 > > > > If you want to own a component, just assign it to yourself. > > > > > > On Tue, Jun 18, 2013 at 12:33 PM, Shazron wrote: > > > >> Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take > over > >> if they wish. What I'm interested in is who should be the "second" in > case > >> I can't do it (for example I am away almost all of August). Technically > >> anyone can take over but it will be nice if they are up to speed and > have > >> the necessary environment to test as a 'second'.. > >> > >> > >> > >> On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: > >> > >>> I am the "lead" for cordova-js in JIRA that anyone else can take over > if > >>> they wish. My focus is more on the tooling nowadays. Lots of > >>> features/improvements/wishes in that component.. > >>> > >>> On 6/18/13 9:02 AM, "Marcel Kinard" wrote: > >>> > On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > > > Think we already have this as per the issue tracker concept of > 'leads' > > but I do agree formalizing the role a little more would help. > > Do all the components leads (as listed in Jira) want to be release > masters for their components? If not, James Jong and I could probably > >> own > the "release master" role for a component each, in case any one is > looking to unload that. > >>> > >>> > >> > >
Re: Whitelist and Wildcards
On BlackBerry10 we use the subdomains attribute and this seems compliant with the spec [1] 1. http://www.w3.org/TR/widgets-access/#attributes On 13-06-17 7:20 PM, "Shazron" wrote: >iOS doesn't use the subdomains attribute, relying on the wildcard in the >origin attribute only. > > >On Mon, Jun 17, 2013 at 4:10 PM, Joe Bowser wrote: > >> Hey >> >> I just answered a question on StackOverflow about the whitelist and >> wildcards. Currently, on Android, doing this: >> >> >> >> >> doesn't work for accessing subdomains, and you have to specify >> subdomains=true. This seems counterintutive to me. I'm wondering if >> this is the case on other platforms, and if this is consistent to the >> spec. Does anyone know? >> >> Joe >> - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Window line endings
https://git-wip-us.apache.org/repos/asf?p=cordova-wp7.git;a=commitdiff;h=b497a269c09edb2e7e7cdbc49defd80b95d9f927;hp=6f7e2865e39b90c04add0e6366a39e984d665053 Whatever, it's fine. @purplecabbage risingj.com On Tue, Jun 18, 2013 at 11:33 AM, Andrew Grieve wrote: > I just ran coho and it updated all of the cordova.js snapshots. > > Jesse - I think you said that last time this resulted in line-endings being > wrong on the file. Could you confirm this? > > If it is a problem, would using a .gitattributes file fix it? > https://help.github.com/articles/dealing-with-line-endings > > Andrew >
Re: Release Bugs
cloning the issue is a good solution, but I suggest updating the script to reflect Andrew's changes to the release issues. On Tue, Jun 18, 2013 at 10:08 AM, Andrew Grieve wrote: > New release bug: https://issues.apache.org/jira/browse/CB-3906 > > > On Tue, Jun 18, 2013 at 1:02 PM, Andrew Grieve > wrote: > > > Okay, I'm going to close out the auto-created ones and create new ones > for > > 2.9 before too much action happens > > > > > > On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI > wrote: > > > >> On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve > >> wrote: > >> > >> > The bug you created: https://issues.apache.org/jira/browse/CB-3857 > >> > - includes platforms that we're not releasing right now > >> > > >> > >> > >> Which means I get spammed for no reason :-) > >> > > > > >
Window line endings
I just ran coho and it updated all of the cordova.js snapshots. Jesse - I think you said that last time this resulted in line-endings being wrong on the file. Could you confirm this? If it is a problem, would using a .gitattributes file fix it? https://help.github.com/articles/dealing-with-line-endings Andrew
Re: CLI: suggested change to "platform ls" command
I think [1] is up to the command patterns that cordova-cli uses. As far as I know, it doesn't use any other shortcuted commands. "ls" is not a highly used command, so a shortcut isn't necessary. I think [2] make sense to implement. Michael On Tue, Jun 18, 2013 at 10:14 AM, Filip Maj wrote: > I had two issues submitted recently, for suggestions to tweaking that > particular command/api: > > [1]: remove the explicit "ls" command > [2]: have "platform(s)" by itself be the ls command, and expand on what it > returns. Not only the currently-installed platforms for a project, but > also which platforms are available and unavailable to install (I.e. Ones > where the check_requirements script passes/fails). > > Thoughts? > > [1] https://issues.apache.org/jira/browse/CB-3903 > > [2] https://issues.apache.org/jira/browse/CB-3904 > >
Re: Release Masters?
Shaz, I haven't done it before but I'll be happy to work with you and help when you're out for iOS & OS X. FYI for planning, I will be out & away on vacation June 26-July 15. -James Jong On Jun 18, 2013, at 1:18 PM, Andrew Grieve wrote: > Okay, created a new release bug & sub-tasks here: > https://issues.apache.org/jira/browse/CB-3906 > > If you want to own a component, just assign it to yourself. > > > On Tue, Jun 18, 2013 at 12:33 PM, Shazron wrote: > >> Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take over >> if they wish. What I'm interested in is who should be the "second" in case >> I can't do it (for example I am away almost all of August). Technically >> anyone can take over but it will be nice if they are up to speed and have >> the necessary environment to test as a 'second'.. >> >> >> >> On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: >> >>> I am the "lead" for cordova-js in JIRA that anyone else can take over if >>> they wish. My focus is more on the tooling nowadays. Lots of >>> features/improvements/wishes in that component.. >>> >>> On 6/18/13 9:02 AM, "Marcel Kinard" wrote: >>> On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > Think we already have this as per the issue tracker concept of 'leads' > but I do agree formalizing the role a little more would help. Do all the components leads (as listed in Jira) want to be release masters for their components? If not, James Jong and I could probably >> own the "release master" role for a component each, in case any one is looking to unload that. >>> >>> >>
Re: Release Masters?
Okay, created a new release bug & sub-tasks here: https://issues.apache.org/jira/browse/CB-3906 If you want to own a component, just assign it to yourself. On Tue, Jun 18, 2013 at 12:33 PM, Shazron wrote: > Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take over > if they wish. What I'm interested in is who should be the "second" in case > I can't do it (for example I am away almost all of August). Technically > anyone can take over but it will be nice if they are up to speed and have > the necessary environment to test as a 'second'.. > > > > On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: > > > I am the "lead" for cordova-js in JIRA that anyone else can take over if > > they wish. My focus is more on the tooling nowadays. Lots of > > features/improvements/wishes in that component.. > > > > On 6/18/13 9:02 AM, "Marcel Kinard" wrote: > > > > >On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > > > > > >> Think we already have this as per the issue tracker concept of 'leads' > > >> but I do agree formalizing the role a little more would help. > > > > > >Do all the components leads (as listed in Jira) want to be release > > >masters for their components? If not, James Jong and I could probably > own > > >the "release master" role for a component each, in case any one is > > >looking to unload that. > > > > >
CLI: suggested change to "platform ls" command
I had two issues submitted recently, for suggestions to tweaking that particular command/api: [1]: remove the explicit "ls" command [2]: have "platform(s)" by itself be the ls command, and expand on what it returns. Not only the currently-installed platforms for a project, but also which platforms are available and unavailable to install (I.e. Ones where the check_requirements script passes/fails). Thoughts? [1] https://issues.apache.org/jira/browse/CB-3903 [2] https://issues.apache.org/jira/browse/CB-3904
Re: Release Bugs
New release bug: https://issues.apache.org/jira/browse/CB-3906 On Tue, Jun 18, 2013 at 1:02 PM, Andrew Grieve wrote: > Okay, I'm going to close out the auto-created ones and create new ones for > 2.9 before too much action happens > > > On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI wrote: > >> On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve >> wrote: >> >> > The bug you created: https://issues.apache.org/jira/browse/CB-3857 >> > - includes platforms that we're not releasing right now >> > >> >> >> Which means I get spammed for no reason :-) >> > >
Re: Release Bugs
Okay, I'm going to close out the auto-created ones and create new ones for 2.9 before too much action happens On Tue, Jun 18, 2013 at 1:49 AM, Anis KADRI wrote: > On Mon, Jun 17, 2013 at 6:42 PM, Andrew Grieve > wrote: > > > The bug you created: https://issues.apache.org/jira/browse/CB-3857 > > - includes platforms that we're not releasing right now > > > > > Which means I get spammed for no reason :-) >
Re: Documentation update to previous version
Yeah I'm interested in the flow as well. I think we published everything again in older releases, not sure if we are still doing that going forward On Tue, Jun 18, 2013 at 9:30 AM, Marcel Kinard wrote: > On Jun 17, 2013, at 6:21 PM, Shazron wrote: > > > Should I bother? I know they will go in edge. There are a couple of > issues: > > https://issues.apache.org/jira/browse/CB-3753 > > https://issues.apache.org/jira/browse/CB-3752 > > > > Basically it's weird since if I added it to the 2.8.0 folder, it's not in > > the 2.8.x branch, but is in master... > > > > So for older version updates, I don't bother with the older branches, > yes? > > Just master and the older folders > > @mwbrooks, when the docs get published to the web at the end of the > release, does just edge or all version folders get published? > > If all folders get published, then correct, no need to commit to old > branches, as all users that browse the docs online will see your change in > the 2.8.0 folder (which is somewhat confusingly [but cleverly] from > master)… unless we ever build a patch release which doesn't seem to happen, > with the possible exception of 2.9.x.
Re: Release Masters?
Echoing Fil here. I am the 'lead' for iOS and OS X but anyone can take over if they wish. What I'm interested in is who should be the "second" in case I can't do it (for example I am away almost all of August). Technically anyone can take over but it will be nice if they are up to speed and have the necessary environment to test as a 'second'.. On Tue, Jun 18, 2013 at 9:04 AM, Filip Maj wrote: > I am the "lead" for cordova-js in JIRA that anyone else can take over if > they wish. My focus is more on the tooling nowadays. Lots of > features/improvements/wishes in that component.. > > On 6/18/13 9:02 AM, "Marcel Kinard" wrote: > > >On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > > > >> Think we already have this as per the issue tracker concept of 'leads' > >> but I do agree formalizing the role a little more would help. > > > >Do all the components leads (as listed in Jira) want to be release > >masters for their components? If not, James Jong and I could probably own > >the "release master" role for a component each, in case any one is > >looking to unload that. > >
Re: Documentation update to previous version
On Jun 17, 2013, at 6:21 PM, Shazron wrote: > Should I bother? I know they will go in edge. There are a couple of issues: > https://issues.apache.org/jira/browse/CB-3753 > https://issues.apache.org/jira/browse/CB-3752 > > Basically it's weird since if I added it to the 2.8.0 folder, it's not in > the 2.8.x branch, but is in master... > > So for older version updates, I don't bother with the older branches, yes? > Just master and the older folders @mwbrooks, when the docs get published to the web at the end of the release, does just edge or all version folders get published? If all folders get published, then correct, no need to commit to old branches, as all users that browse the docs online will see your change in the 2.8.0 folder (which is somewhat confusingly [but cleverly] from master)… unless we ever build a patch release which doesn't seem to happen, with the possible exception of 2.9.x.
Re: How to build apache cordova project from command line?
I've answered on the SO post, let's continue the discussion there. On 6/17/13 10:56 PM, "--sowdri--" wrote: >Hi All, > > > - I've setup apache cordova on my Windows/Cygwin platform. > - I can create project using the command - cordova create . > - I have added android platform using the command - cordova platform >add > android > - I can run the sample 'html/css/js' using cordova ripple android. > - I can upload the project to build.phonegap and get the .apk file. > - > > I know from docs that I can setup eclipse and do the build. (I'm not > looking for this) > - > > But I cannot create .apk file using the command cordova build android. > When I run the command, there is not output on the command line, the > command just finishes. I cannot locate the .apk file. > >Is there a way in which I can create an .apk file from command line? >(Looking for suggestions for other platforms as well) > > >Link to SO posting: > >http://stackoverflow.com/questions/17140227/how-to-build-apache-cordova-pr >oject-from-command-line > > >Thanks, > >-- > >-sowdri-
Re: Release Masters?
On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > Think we already have this as per the issue tracker concept of 'leads' > but I do agree formalizing the role a little more would help. Do all the components leads (as listed in Jira) want to be release masters for their components? If not, James Jong and I could probably own the "release master" role for a component each, in case any one is looking to unload that.
Re: Release Masters?
I am the "lead" for cordova-js in JIRA that anyone else can take over if they wish. My focus is more on the tooling nowadays. Lots of features/improvements/wishes in that component.. On 6/18/13 9:02 AM, "Marcel Kinard" wrote: >On Jun 18, 2013, at 5:07 AM, Brian LeRoux wrote: > >> Think we already have this as per the issue tracker concept of 'leads' >> but I do agree formalizing the role a little more would help. > >Do all the components leads (as listed in Jira) want to be release >masters for their components? If not, James Jong and I could probably own >the "release master" role for a component each, in case any one is >looking to unload that.
Re: 2.9.0rc1 this coming monday??
Tried your coho commands and they worked well Andrew :) ./cordova-coho/coho create-release-branch --version 2.8.0rc1 -r js -r app-hello-world ./cordova-coho/coho tag-release --version 2.8.0rc1 -r js -r app-hello-world App and JS are branched/tagged. On 6/18/13 7:30 AM, "Shazron" wrote: >I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I >wanted to get into rc1, but I don't want to rush it, I'll get to all the >rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get >that done. > > >On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj wrote: > >> I have the rc tag issues for mobile-spec and the JS assigned to me. I >>will >> tag them tomorrow morning unless I hear otherwise. >> >> On 6/17/13 2:01 PM, "James Jong" wrote: >> >> >I'm back this week and will start looking at a couple of the ones Shaz >> >mentioned: CB-3757 , CB-3562. >> >-James Jong >> > >> >On Jun 17, 2013, at 3:21 PM, Andrew Grieve >>wrote: >> > >> >> I would have liked to fix a few more bugs, namely: >> >> - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) >> >> - iOS loading bugs (CB-3005, CB-3530, CB-3534) >> >> - DisallowOverscroll setting inconsistency between Android and iOS >> >>(Jesse >> >> brought this up - no bug filed for this yet I think) >> >> >> >> I was also planning on working on adding some Plugin-behaving-nicely >> >>checks >> >> on the native side. E.g. log a message if a plugin takes spends more >> >>than >> >> 50ms on the UI (for iOS) or WebCore (for Android) thread. >> >> >> >> Of course, I haven't done anything for over 2 weeks, and so I clearly >> >>won't >> >> get this all done in the next few hours :P. >> >> >> >> So, I'm fine with starting the release now so that we can focus more >>on >> >> 3.0. It'll give us a chance to practice our release-foo some more, >>and >> >> hopefully make more enhancements to the coho tool (Steven - I'm >>looking >> >>at >> >> you for the uploading a release part :P). >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj wrote: >> >> >> >>> Thanks Jeff! >> >>> >> >>> On 6/17/13 10:28 AM, "Jeffrey Heifetz" >> wrote: >> >>> >> Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, >> CB-3799 >> >> On 13-06-17 1:26 PM, "Filip Maj" wrote: >> >> > Good stuff Bryan, is this being tracked on issues anywhere? I'd >>like >> >to >> > refer other issues (CLI) to this feature you're speaking of. >> > >> > On 6/17/13 10:18 AM, "Bryan Higgins" >>wrote: >> > >> >> For BB10, we're working on moving out the environment settings >>from >> >> project >> >> to HOME. >> >> >> >> That work is pretty much done. We should have it tested and >> >>committed >> >> within the next few hours. >> >> >> >> >> >> On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland >>> > >> >> wrote: >> >> >> >>> The only thing that I'm working on this morning that could be a >> >>> candidate >> >>> for 2.9 is an extension to FileWriter.write(Blob) that will >>accept >> >>>a >> >>> Cordova File object in place of a native Blob object. >> >>> >> >>> (FileWriter.write(Blob) is CB-2406, and new for 2.9) >> >>> >> >>> If we consider this a bug to be fixed, then I can take care of >>it >> >>> post-rc1. >> >>> Otherwise, I'll work quickly to get it in this morning. >> >>> >> >>> >> >>> >> >>> On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj >>wrote: >> >>> >> SO: we're doing this today ya? Any objections? Anyone still >> working >> >>> on >> something that they are gunning to get in for 2.9? >> >> On 6/14/13 1:12 PM, "Michael Brooks" >> >>> wrote: >> >> > Monday RC1 sounds good to me. >> > >> > >> > On Thu, Jun 13, 2013 at 11:19 AM, Shazron >> >>> wrote: >> > >> >> Looking at iOS 2.9.0: >> >> >> >> Definitely as you said: >> >>> https://issues.apache.org/jira/browse/CB-3757 >> >> Then all iOS cli and docs issues. >> >> >> >> If there is time for iOS I am going to tackle: >> >> https://issues.apache.org/jira/browse/CB-3303 (to fix) >> >> https://issues.apache.org/jira/browse/CB-3451 (to >>investigate, >> >>> no >> >>> fix >> >> yet) >> >> https://issues.apache.org/jira/browse/CB-3567 (there is a PR >>to >> >> investigate) >> >> https://issues.apache.org/jira/browse/CB-3562 (fix in the >> issue, >> >>> to >> >> evaluate) >> >> https://issues.apache.org/jira/browse/CB-3534 (the reporter >>has >> >>> filed >> an >> >> excellent bug report, to repro, and maybe fix) >> >> >> >> Maybe this Untappd issue: >> >>> https://issues.apache.org/jira/browse/CB-3574 >> >> >> >> >> >> >> >> On Thu, Jun 13, 2013 at 11:1
RE: Suggestion - pluginLoader
I have (briefly) looked at Harmony loaders before but that is a spec for a future javascript language version. I have found a module loader that I wish to use (require.js). My point is that the current suggested module definition for cordova plugins INCLUDES a loader implementation. I am suggesting that the loader implementation be removed from the plugin to a new method cordova.pluginLoader This would make the plugins cleaner (as they would only describe their own behaviour) and it would also allow cordova or app developers to change/customize the loader implementation as needed. My suggested approach would result in plugins that could be loaded in multiple different ways including (but not limited to); "classic" window.plugins, cordova.define and require.js > From: jbo...@openmv.com > To: dev@cordova.apache.org > Subject: RE: Suggestion - pluginLoader > Date: Tue, 18 Jun 2013 15:08:27 + > > Take a look at: > http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders > https://gist.github.com/wycats/51c96e3adcdb3a68cbc3 > > That type of extensible loader could make sense in Cordova and seems like it > would meet all your requirements. > > > -Original Message- > From: J Prince [mailto:princej.w...@hotmail.co.uk] > Sent: Monday, June 17, 2013 7:27 AM > To: dev@cordova.apache.org > Subject: RE: Suggestion - pluginLoader > > There are a few main reasons. > > 1. The app I am working on is an Enterprise app. We are designing the app as > a Cordova shell that re-directs to all the html content. This means that we > have to dynamically load a different cordova.js (depending on platform) > following the redirect. > So we are actually unable to do anything other than dynamically load plugins > once the platform specific cordova.js is loaded > > 2. Some of the plugins will be used incredibly rarely. It doesn't seem > necessary to always load plugins until they are needed. > > 3. We are building with a single page architecture so don't want to end up > with lots of script includes in the index.html page. > The define/require pattern feels much cleaner and better compartmentalized. > Our main page currently has 2 script includes: require.js and jqmobi. > > >
Re: 2.9.0rc1 this coming monday??
I am going to tag the tests and JavaScript now.. On 6/18/13 7:30 AM, "Shazron" wrote: >I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I >wanted to get into rc1, but I don't want to rush it, I'll get to all the >rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get >that done. > > >On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj wrote: > >> I have the rc tag issues for mobile-spec and the JS assigned to me. I >>will >> tag them tomorrow morning unless I hear otherwise. >> >> On 6/17/13 2:01 PM, "James Jong" wrote: >> >> >I'm back this week and will start looking at a couple of the ones Shaz >> >mentioned: CB-3757 , CB-3562. >> >-James Jong >> > >> >On Jun 17, 2013, at 3:21 PM, Andrew Grieve >>wrote: >> > >> >> I would have liked to fix a few more bugs, namely: >> >> - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) >> >> - iOS loading bugs (CB-3005, CB-3530, CB-3534) >> >> - DisallowOverscroll setting inconsistency between Android and iOS >> >>(Jesse >> >> brought this up - no bug filed for this yet I think) >> >> >> >> I was also planning on working on adding some Plugin-behaving-nicely >> >>checks >> >> on the native side. E.g. log a message if a plugin takes spends more >> >>than >> >> 50ms on the UI (for iOS) or WebCore (for Android) thread. >> >> >> >> Of course, I haven't done anything for over 2 weeks, and so I clearly >> >>won't >> >> get this all done in the next few hours :P. >> >> >> >> So, I'm fine with starting the release now so that we can focus more >>on >> >> 3.0. It'll give us a chance to practice our release-foo some more, >>and >> >> hopefully make more enhancements to the coho tool (Steven - I'm >>looking >> >>at >> >> you for the uploading a release part :P). >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj wrote: >> >> >> >>> Thanks Jeff! >> >>> >> >>> On 6/17/13 10:28 AM, "Jeffrey Heifetz" >> wrote: >> >>> >> Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, >> CB-3799 >> >> On 13-06-17 1:26 PM, "Filip Maj" wrote: >> >> > Good stuff Bryan, is this being tracked on issues anywhere? I'd >>like >> >to >> > refer other issues (CLI) to this feature you're speaking of. >> > >> > On 6/17/13 10:18 AM, "Bryan Higgins" >>wrote: >> > >> >> For BB10, we're working on moving out the environment settings >>from >> >> project >> >> to HOME. >> >> >> >> That work is pretty much done. We should have it tested and >> >>committed >> >> within the next few hours. >> >> >> >> >> >> On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland >>> > >> >> wrote: >> >> >> >>> The only thing that I'm working on this morning that could be a >> >>> candidate >> >>> for 2.9 is an extension to FileWriter.write(Blob) that will >>accept >> >>>a >> >>> Cordova File object in place of a native Blob object. >> >>> >> >>> (FileWriter.write(Blob) is CB-2406, and new for 2.9) >> >>> >> >>> If we consider this a bug to be fixed, then I can take care of >>it >> >>> post-rc1. >> >>> Otherwise, I'll work quickly to get it in this morning. >> >>> >> >>> >> >>> >> >>> On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj >>wrote: >> >>> >> SO: we're doing this today ya? Any objections? Anyone still >> working >> >>> on >> something that they are gunning to get in for 2.9? >> >> On 6/14/13 1:12 PM, "Michael Brooks" >> >>> wrote: >> >> > Monday RC1 sounds good to me. >> > >> > >> > On Thu, Jun 13, 2013 at 11:19 AM, Shazron >> >>> wrote: >> > >> >> Looking at iOS 2.9.0: >> >> >> >> Definitely as you said: >> >>> https://issues.apache.org/jira/browse/CB-3757 >> >> Then all iOS cli and docs issues. >> >> >> >> If there is time for iOS I am going to tackle: >> >> https://issues.apache.org/jira/browse/CB-3303 (to fix) >> >> https://issues.apache.org/jira/browse/CB-3451 (to >>investigate, >> >>> no >> >>> fix >> >> yet) >> >> https://issues.apache.org/jira/browse/CB-3567 (there is a PR >>to >> >> investigate) >> >> https://issues.apache.org/jira/browse/CB-3562 (fix in the >> issue, >> >>> to >> >> evaluate) >> >> https://issues.apache.org/jira/browse/CB-3534 (the reporter >>has >> >>> filed >> an >> >> excellent bug report, to repro, and maybe fix) >> >> >> >> Maybe this Untappd issue: >> >>> https://issues.apache.org/jira/browse/CB-3574 >> >> >> >> >> >> >> >> On Thu, Jun 13, 2013 at 11:10 AM, Lorin Beer < >> >>> lorin.beer@gmail.com >> >>> wrote: >> >> >> >>> be the leaf in the wind, Shaz. >> >>> >> >>> Anything pressing on iOS that needs t
Re: Android: Use source files instead of .jar file
I think we should seriously consider this, but agree that it should wait until after 3.0. It's a good point that 90% of the code formerly in the jar will be copied in from plugins now. Braden On Tue, Jun 18, 2013 at 6:12 AM, Jesse MacFadyen wrote: > The wp7 change Benn mentioned has several motivations behind it. The > windows phone permission model and the app store's static analysis > decide permission based on linkage, so having 1 library dll would > require all permissions, and a separate dll for each API was unwieldy. > > In my mind, given our move to plugin separation, the base library > should be small enough to re-create on every new project. > > However, I do understand Joe's position, but I think it is going to > make less sense once there is just a bridge, and some helpers in the > 'what was once a jar' > > Having people go and change specific lines of code leads to > challenging updates, since the entire repo becomes modified. That is > the benefit of having a distributed built library, or linking to a > library project. Also, in my mind, distributing a .dll/.jar/.a says > 'here is a thing you can use' while source says, 'here's a pile to > sift thru and take what you need,' but I'm old school. And code is > never finished anyway... > > Also, instead of basing things on number of issues filed, I suggest > helping people on the pg mailing list, you will learn a lot more about > what we do right and wrong. > > Cheers, > Jesse > > Sent from my iPhone5 > > On Jun 17, 2013, at 6:24 PM, Andrew Grieve wrote: > > I don't think it's caused any issues on iOS, and it definitely has improved > bug reports. That's because you get better stack traces on iOS though, I > don't think the same is true for Android. > > I'll also point out that with 3.0, the majority of the code will already be > in the form of source files since plugin code will not be in the form of > jars. > > There have been several times on Android where I've had back-and-forth on a > JIRA issue where I say "Hey - can you trying changing this line to that and > see what happens" and their reply is "I have a JAR and so can't do that". > If they have the source, then this flow works. > > Joe (or anyone else who thinks this is not a good idea) - I'd like to hear > more about why you think this will cause things to break? > > > > On Mon, Jun 17, 2013 at 6:07 PM, Kerri Shotts > wrote: > > > > We surely have data on this, since iOS has transitioned; how many issues > > have been raised on iOS because someone mucked around where they > shouldn't > > have? Perhaps not directly applicable to Android, but it would perhaps > be a > > rough estimate. > > > > > > ___ > > Kerri Shotts > > photoKandy Studios, LLC > > > > On the Web: http://www.photokandy.com/ > > > > Social Media: > > Twitter: @photokandy, http://twitter.com/photokandy > > Tumblr: http://photokandy.tumblr.com/ > > Github: https://github.com/kerrishotts > > > https://github.com/organizations/photokandyStudios > > CoderWall: https://coderwall.com/kerrishotts > > > > Apps on the Apple Store: > > > > https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 > > > > Books: > > > > http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book > > http://www.packtpub.com/phonegap-social-app-development/book > > > > > > > >>> On Jun 17, 2013, at 16:37, Joe Bowser wrote: > >> > >> My bet is six months > >> > >>> On Mon, Jun 17, 2013 at 2:32 PM, Filip Maj wrote: > >>> I'm ambivalent on this issue. > >>> > >>> To play devil's advocate, Joe, it hasn't been an issue on iOS or > Windows > >>> Phone, so any speculation that this _will_ be an issue in the future is > >>> just that: speculation. > >>> > >>> If anything we should set an over/under on how long it will take after > >>> introducing this change before we get "Hey gaiz I changed > >>> CordovaWebView.java and now nothing works!" issues ;) > >>> > >>> My bet is: a long time. > >>> > On 6/17/13 2:11 PM, "Benn Mapes" wrote: > > +1 > I really like having source code. On Windows Phone we have moved from > a > pre-compiled .dll to just the source as well. Like Kerri said, it is > > very > helpful when stepping through your application and debugging any > > problems > you might have, as well as getting more people looking at the code and > understanding it better. > > If users don't want to look at the source at all they can just treat > > the > cordovaLib folder like it's a .jar and not touch it. > > > > On Mon, Jun 17, 2013 at 1:04 PM, Joe Bowser > wrote: > > > > -1 > > > > This only caters to a minority of our users. Most of our users can't > > debug > > Cordova, since they can't write Java (or even Javascript) well. > > > > I think this will have far more things break and we'll have a huge > > backlash > > from our mainstream users, just l
RE: Suggestion - pluginLoader
Take a look at: http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders https://gist.github.com/wycats/51c96e3adcdb3a68cbc3 That type of extensible loader could make sense in Cordova and seems like it would meet all your requirements. -Original Message- From: J Prince [mailto:princej.w...@hotmail.co.uk] Sent: Monday, June 17, 2013 7:27 AM To: dev@cordova.apache.org Subject: RE: Suggestion - pluginLoader There are a few main reasons. 1. The app I am working on is an Enterprise app. We are designing the app as a Cordova shell that re-directs to all the html content. This means that we have to dynamically load a different cordova.js (depending on platform) following the redirect. So we are actually unable to do anything other than dynamically load plugins once the platform specific cordova.js is loaded 2. Some of the plugins will be used incredibly rarely. It doesn't seem necessary to always load plugins until they are needed. 3. We are building with a single page architecture so don't want to end up with lots of script includes in the index.html page. The define/require pattern feels much cleaner and better compartmentalized. Our main page currently has 2 script includes: require.js and jqmobi.
Re: Plugins and IP
Hmm didn't think about JavaScript - the easiest is obfuscation with Closure or something (with exclusions for cordova objects). On Tue, Jun 18, 2013 at 7:30 AM, Ken Wallis wrote: > On BB10, that native side gets compiled into a .so file that you would > distribute. > > Of course there is still the javascript side. Depends on which side of the > plugin you are worried about IP in. > -- > > Ken Wallis > > Product Manager – WebWorks > > BlackBerry > > 289-261-4369 > > > From: Simon MacDonald [simon.macdon...@gmail.com] > Sent: Tuesday, June 18, 2013 7:14 AM > To: dev@cordova.apache.org > Subject: Re: Plugins and IP > > Same deal on Android except you would use a jar or if UI is involved a > library project. > Simon Mac Donald > http://hi.im/simonmacdonald > > > On Tue, Jun 18, 2013 at 10:07 AM, Shazron wrote: > > Forgot to mention, you should build the lib as a fat binary with all > > architectures, don't forget i386 if your users plan to test on the > Simulator > > > > > > On Tue, Jun 18, 2013 at 7:04 AM, Shazron wrote: > > > >> For iOS plugins, compile the source as a lib (.a file). For example, in > >> the TestFlightPlugin I include TestFlight's lib: > >> https://github.com/shazron/TestFlightPlugin > >> https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml#L35 > >> > >> and provide the headers of course > >> > >> > >> On Tue, Jun 18, 2013 at 6:42 AM, Wargo, John > wrote: > >> > >>> Any recommendations on the best way to implement plugins while > protecting > >>> the source code? Our development teams are trying to figure out the > most > >>> efficient way to deliver Cordova plugins to our customers but hide the > IP > >>> and I would like to learn how others are managing this. > >>> > >>> > >> > > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
Re: 2.9.0rc1 this coming monday??
I'm still testing https://issues.apache.org/jira/browse/CB-3530 that I wanted to get into rc1, but I don't want to rush it, I'll get to all the rc1 tasks for iOS this afternoon. OS X has barely had changes so I can get that done. On Mon, Jun 17, 2013 at 5:03 PM, Filip Maj wrote: > I have the rc tag issues for mobile-spec and the JS assigned to me. I will > tag them tomorrow morning unless I hear otherwise. > > On 6/17/13 2:01 PM, "James Jong" wrote: > > >I'm back this week and will start looking at a couple of the ones Shaz > >mentioned: CB-3757 , CB-3562. > >-James Jong > > > >On Jun 17, 2013, at 3:21 PM, Andrew Grieve wrote: > > > >> I would have liked to fix a few more bugs, namely: > >> - Those filed by Abel Muiño (Camera / FileTransfer) (e.g. cb-3185) > >> - iOS loading bugs (CB-3005, CB-3530, CB-3534) > >> - DisallowOverscroll setting inconsistency between Android and iOS > >>(Jesse > >> brought this up - no bug filed for this yet I think) > >> > >> I was also planning on working on adding some Plugin-behaving-nicely > >>checks > >> on the native side. E.g. log a message if a plugin takes spends more > >>than > >> 50ms on the UI (for iOS) or WebCore (for Android) thread. > >> > >> Of course, I haven't done anything for over 2 weeks, and so I clearly > >>won't > >> get this all done in the next few hours :P. > >> > >> So, I'm fine with starting the release now so that we can focus more on > >> 3.0. It'll give us a chance to practice our release-foo some more, and > >> hopefully make more enhancements to the coho tool (Steven - I'm looking > >>at > >> you for the uploading a release part :P). > >> > >> > >> > >> > >> > >> > >> On Mon, Jun 17, 2013 at 1:38 PM, Filip Maj wrote: > >> > >>> Thanks Jeff! > >>> > >>> On 6/17/13 10:28 AM, "Jeffrey Heifetz" > wrote: > >>> > Yep, all BB10 work is being tracked in JIRA. Check out CB-3797, > CB-3799 > > On 13-06-17 1:26 PM, "Filip Maj" wrote: > > > Good stuff Bryan, is this being tracked on issues anywhere? I'd like > >to > > refer other issues (CLI) to this feature you're speaking of. > > > > On 6/17/13 10:18 AM, "Bryan Higgins" wrote: > > > >> For BB10, we're working on moving out the environment settings from > >> project > >> to HOME. > >> > >> That work is pretty much done. We should have it tested and > >>committed > >> within the next few hours. > >> > >> > >> On Mon, Jun 17, 2013 at 1:04 PM, Ian Clelland > > >> wrote: > >> > >>> The only thing that I'm working on this morning that could be a > >>> candidate > >>> for 2.9 is an extension to FileWriter.write(Blob) that will accept > >>>a > >>> Cordova File object in place of a native Blob object. > >>> > >>> (FileWriter.write(Blob) is CB-2406, and new for 2.9) > >>> > >>> If we consider this a bug to be fixed, then I can take care of it > >>> post-rc1. > >>> Otherwise, I'll work quickly to get it in this morning. > >>> > >>> > >>> > >>> On Mon, Jun 17, 2013 at 10:00 AM, Filip Maj wrote: > >>> > SO: we're doing this today ya? Any objections? Anyone still > working > >>> on > something that they are gunning to get in for 2.9? > > On 6/14/13 1:12 PM, "Michael Brooks" > >>> wrote: > > > Monday RC1 sounds good to me. > > > > > > On Thu, Jun 13, 2013 at 11:19 AM, Shazron > >>> wrote: > > > >> Looking at iOS 2.9.0: > >> > >> Definitely as you said: > >>> https://issues.apache.org/jira/browse/CB-3757 > >> Then all iOS cli and docs issues. > >> > >> If there is time for iOS I am going to tackle: > >> https://issues.apache.org/jira/browse/CB-3303 (to fix) > >> https://issues.apache.org/jira/browse/CB-3451 (to investigate, > >>> no > >>> fix > >> yet) > >> https://issues.apache.org/jira/browse/CB-3567 (there is a PR to > >> investigate) > >> https://issues.apache.org/jira/browse/CB-3562 (fix in the > issue, > >>> to > >> evaluate) > >> https://issues.apache.org/jira/browse/CB-3534 (the reporter has > >>> filed > an > >> excellent bug report, to repro, and maybe fix) > >> > >> Maybe this Untappd issue: > >>> https://issues.apache.org/jira/browse/CB-3574 > >> > >> > >> > >> On Thu, Jun 13, 2013 at 11:10 AM, Lorin Beer < > >>> lorin.beer@gmail.com > >>> wrote: > >> > >>> be the leaf in the wind, Shaz. > >>> > >>> Anything pressing on iOS that needs to be resolved? I am aware > >>> of a > >> bug > >> in > >>> Camera, which I can take a look at. Anything else you want in? > >>> > >>> > >>> On Thu, Jun 13, 2013 at 11:01 AM, Shazron > >>> wrote: > >>>
RE: Plugins and IP
On BB10, that native side gets compiled into a .so file that you would distribute. Of course there is still the javascript side. Depends on which side of the plugin you are worried about IP in. -- Ken Wallis Product Manager – WebWorks BlackBerry 289-261-4369 From: Simon MacDonald [simon.macdon...@gmail.com] Sent: Tuesday, June 18, 2013 7:14 AM To: dev@cordova.apache.org Subject: Re: Plugins and IP Same deal on Android except you would use a jar or if UI is involved a library project. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Jun 18, 2013 at 10:07 AM, Shazron wrote: > Forgot to mention, you should build the lib as a fat binary with all > architectures, don't forget i386 if your users plan to test on the Simulator > > > On Tue, Jun 18, 2013 at 7:04 AM, Shazron wrote: > >> For iOS plugins, compile the source as a lib (.a file). For example, in >> the TestFlightPlugin I include TestFlight's lib: >> https://github.com/shazron/TestFlightPlugin >> https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml#L35 >> >> and provide the headers of course >> >> >> On Tue, Jun 18, 2013 at 6:42 AM, Wargo, John wrote: >> >>> Any recommendations on the best way to implement plugins while protecting >>> the source code? Our development teams are trying to figure out the most >>> efficient way to deliver Cordova plugins to our customers but hide the IP >>> and I would like to learn how others are managing this. >>> >>> >> - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Release Masters?
Great! Yes, I think it works well to have the parent bug should be assigned to the release master. I don't think anyone's been trying to base releases on features (aside from 3.0). Our releases have been slow due to the time it takes to test, and the time it takes to go through all of the release steps for all of the platforms. On Tue, Jun 18, 2013 at 5:07 AM, Brian LeRoux wrote: > Think we already have this as per the issue tracker concept of 'leads' > but I do agree formalizing the role a little more would help. I'd > really love it if we got back to shipping to a date and not to any set > of features, only finished work was being merged back to master, so > cutting a release is a ceremony not a struggle. > > On Tue, Jun 18, 2013 at 3:48 AM, Andrew Grieve > wrote: > > Idea here would be to label someone as the "Release Master" for each > > release. Responsibilities would include: > > > > - Creating branches > > - Managing release bugs > > - Nagging people responsible for unfinished release items > > - Creating the final release .zip and uploading it > > - Announcing the release > > - Ensuring that the release process wiki page is up-to-date > > > > I think this would help make sure releases happen quicker and that > release > > tasks are not overlooked. It will also help with knowledge sharing I > think. >
Re: Plugins and IP
Same deal on Android except you would use a jar or if UI is involved a library project. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Jun 18, 2013 at 10:07 AM, Shazron wrote: > Forgot to mention, you should build the lib as a fat binary with all > architectures, don't forget i386 if your users plan to test on the Simulator > > > On Tue, Jun 18, 2013 at 7:04 AM, Shazron wrote: > >> For iOS plugins, compile the source as a lib (.a file). For example, in >> the TestFlightPlugin I include TestFlight's lib: >> https://github.com/shazron/TestFlightPlugin >> https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml#L35 >> >> and provide the headers of course >> >> >> On Tue, Jun 18, 2013 at 6:42 AM, Wargo, John wrote: >> >>> Any recommendations on the best way to implement plugins while protecting >>> the source code? Our development teams are trying to figure out the most >>> efficient way to deliver Cordova plugins to our customers but hide the IP >>> and I would like to learn how others are managing this. >>> >>> >>
Re: Plugins and IP
Forgot to mention, you should build the lib as a fat binary with all architectures, don't forget i386 if your users plan to test on the Simulator On Tue, Jun 18, 2013 at 7:04 AM, Shazron wrote: > For iOS plugins, compile the source as a lib (.a file). For example, in > the TestFlightPlugin I include TestFlight's lib: > https://github.com/shazron/TestFlightPlugin > https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml#L35 > > and provide the headers of course > > > On Tue, Jun 18, 2013 at 6:42 AM, Wargo, John wrote: > >> Any recommendations on the best way to implement plugins while protecting >> the source code? Our development teams are trying to figure out the most >> efficient way to deliver Cordova plugins to our customers but hide the IP >> and I would like to learn how others are managing this. >> >> >
Re: Plugins and IP
For iOS plugins, compile the source as a lib (.a file). For example, in the TestFlightPlugin I include TestFlight's lib: https://github.com/shazron/TestFlightPlugin https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml#L35 and provide the headers of course On Tue, Jun 18, 2013 at 6:42 AM, Wargo, John wrote: > Any recommendations on the best way to implement plugins while protecting > the source code? Our development teams are trying to figure out the most > efficient way to deliver Cordova plugins to our customers but hide the IP > and I would like to learn how others are managing this. > >
Plugins and IP
Any recommendations on the best way to implement plugins while protecting the source code? Our development teams are trying to figure out the most efficient way to deliver Cordova plugins to our customers but hide the IP and I would like to learn how others are managing this.
Re: Android: Use source files instead of .jar file
The wp7 change Benn mentioned has several motivations behind it. The windows phone permission model and the app store's static analysis decide permission based on linkage, so having 1 library dll would require all permissions, and a separate dll for each API was unwieldy. In my mind, given our move to plugin separation, the base library should be small enough to re-create on every new project. However, I do understand Joe's position, but I think it is going to make less sense once there is just a bridge, and some helpers in the 'what was once a jar' Having people go and change specific lines of code leads to challenging updates, since the entire repo becomes modified. That is the benefit of having a distributed built library, or linking to a library project. Also, in my mind, distributing a .dll/.jar/.a says 'here is a thing you can use' while source says, 'here's a pile to sift thru and take what you need,' but I'm old school. And code is never finished anyway... Also, instead of basing things on number of issues filed, I suggest helping people on the pg mailing list, you will learn a lot more about what we do right and wrong. Cheers, Jesse Sent from my iPhone5 On Jun 17, 2013, at 6:24 PM, Andrew Grieve wrote: I don't think it's caused any issues on iOS, and it definitely has improved bug reports. That's because you get better stack traces on iOS though, I don't think the same is true for Android. I'll also point out that with 3.0, the majority of the code will already be in the form of source files since plugin code will not be in the form of jars. There have been several times on Android where I've had back-and-forth on a JIRA issue where I say "Hey - can you trying changing this line to that and see what happens" and their reply is "I have a JAR and so can't do that". If they have the source, then this flow works. Joe (or anyone else who thinks this is not a good idea) - I'd like to hear more about why you think this will cause things to break? > On Mon, Jun 17, 2013 at 6:07 PM, Kerri Shotts wrote: > > We surely have data on this, since iOS has transitioned; how many issues > have been raised on iOS because someone mucked around where they shouldn't > have? Perhaps not directly applicable to Android, but it would perhaps be a > rough estimate. > > > ___ > Kerri Shotts > photoKandy Studios, LLC > > On the Web: http://www.photokandy.com/ > > Social Media: > Twitter: @photokandy, http://twitter.com/photokandy > Tumblr: http://photokandy.tumblr.com/ > Github: https://github.com/kerrishotts >https://github.com/organizations/photokandyStudios > CoderWall: https://coderwall.com/kerrishotts > > Apps on the Apple Store: > > https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 > > Books: > > http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book > http://www.packtpub.com/phonegap-social-app-development/book > > > >>> On Jun 17, 2013, at 16:37, Joe Bowser wrote: >> >> My bet is six months >> >>> On Mon, Jun 17, 2013 at 2:32 PM, Filip Maj wrote: >>> I'm ambivalent on this issue. >>> >>> To play devil's advocate, Joe, it hasn't been an issue on iOS or Windows >>> Phone, so any speculation that this _will_ be an issue in the future is >>> just that: speculation. >>> >>> If anything we should set an over/under on how long it will take after >>> introducing this change before we get "Hey gaiz I changed >>> CordovaWebView.java and now nothing works!" issues ;) >>> >>> My bet is: a long time. >>> On 6/17/13 2:11 PM, "Benn Mapes" wrote: +1 I really like having source code. On Windows Phone we have moved from a pre-compiled .dll to just the source as well. Like Kerri said, it is > very helpful when stepping through your application and debugging any > problems you might have, as well as getting more people looking at the code and understanding it better. If users don't want to look at the source at all they can just treat > the cordovaLib folder like it's a .jar and not touch it. > On Mon, Jun 17, 2013 at 1:04 PM, Joe Bowser wrote: > > -1 > > This only caters to a minority of our users. Most of our users can't > debug > Cordova, since they can't write Java (or even Javascript) well. > > I think this will have far more things break and we'll have a huge > backlash > from our mainstream users, just like when we deprecated plugins. > On Jun 17, 2013 12:48 PM, "Andrew Grieve" > wrote: > >> I'd like to propose that instead of having the create script compile > a >> version of Cordova into a .jar, that instead it copies over the > source >> files instead. >> >> My main motivation is that doing so will make debugging native code > much >> easier since the source code will show up in Eclipse / Android Studio > by >> default instea
Re: Android: Use source files instead of .jar file
We def do not want to do this before 3.0 ...too big of a change. I think while we are seeing lots of benefits in issue tracking for iOS I share Joe's anxiety that we may end up with cowboy upgrades conflicting with project upgrades. Lets get 3 out the door and have a look after. Added to roadmap backlog which we'll be discussing much later this summer I'm sure. [1] [1] http://wiki.apache.org/cordova/RoadmapProjects On Tue, Jun 18, 2013 at 3:23 AM, Andrew Grieve wrote: > I don't think it's caused any issues on iOS, and it definitely has improved > bug reports. That's because you get better stack traces on iOS though, I > don't think the same is true for Android. > > I'll also point out that with 3.0, the majority of the code will already be > in the form of source files since plugin code will not be in the form of > jars. > > There have been several times on Android where I've had back-and-forth on a > JIRA issue where I say "Hey - can you trying changing this line to that and > see what happens" and their reply is "I have a JAR and so can't do that". > If they have the source, then this flow works. > > Joe (or anyone else who thinks this is not a good idea) - I'd like to hear > more about why you think this will cause things to break? > > > On Mon, Jun 17, 2013 at 6:07 PM, Kerri Shotts wrote: > >> We surely have data on this, since iOS has transitioned; how many issues >> have been raised on iOS because someone mucked around where they shouldn't >> have? Perhaps not directly applicable to Android, but it would perhaps be a >> rough estimate. >> >> >> ___ >> Kerri Shotts >> photoKandy Studios, LLC >> >> On the Web: http://www.photokandy.com/ >> >> Social Media: >> Twitter: @photokandy, http://twitter.com/photokandy >> Tumblr: http://photokandy.tumblr.com/ >> Github: https://github.com/kerrishotts >> https://github.com/organizations/photokandyStudios >> CoderWall: https://coderwall.com/kerrishotts >> >> Apps on the Apple Store: >> >> https://itunes.apple.com/us/artist/photokandy-studios-llc/id498577828 >> >> Books: >> >> http://www.packtpub.com/phonegap-2-mobile-application-hotshot/book >> http://www.packtpub.com/phonegap-social-app-development/book >> >> >> >> On Jun 17, 2013, at 16:37, Joe Bowser wrote: >> >> > My bet is six months >> > >> > On Mon, Jun 17, 2013 at 2:32 PM, Filip Maj wrote: >> >> I'm ambivalent on this issue. >> >> >> >> To play devil's advocate, Joe, it hasn't been an issue on iOS or Windows >> >> Phone, so any speculation that this _will_ be an issue in the future is >> >> just that: speculation. >> >> >> >> If anything we should set an over/under on how long it will take after >> >> introducing this change before we get "Hey gaiz I changed >> >> CordovaWebView.java and now nothing works!" issues ;) >> >> >> >> My bet is: a long time. >> >> >> >> On 6/17/13 2:11 PM, "Benn Mapes" wrote: >> >> >> >>> +1 >> >>> I really like having source code. On Windows Phone we have moved from a >> >>> pre-compiled .dll to just the source as well. Like Kerri said, it is >> very >> >>> helpful when stepping through your application and debugging any >> problems >> >>> you might have, as well as getting more people looking at the code and >> >>> understanding it better. >> >>> >> >>> If users don't want to look at the source at all they can just treat >> the >> >>> cordovaLib folder like it's a .jar and not touch it. >> >>> >> >>> >> >>> On Mon, Jun 17, 2013 at 1:04 PM, Joe Bowser wrote: >> >>> >> -1 >> >> This only caters to a minority of our users. Most of our users can't >> debug >> Cordova, since they can't write Java (or even Javascript) well. >> >> I think this will have far more things break and we'll have a huge >> backlash >> from our mainstream users, just like when we deprecated plugins. >> On Jun 17, 2013 12:48 PM, "Andrew Grieve" >> wrote: >> >> > I'd like to propose that instead of having the create script compile >> a >> > version of Cordova into a .jar, that instead it copies over the >> source >> > files instead. >> > >> > My main motivation is that doing so will make debugging native code >> much >> > easier since the source code will show up in Eclipse / Android Studio >> by >> > default instead of needing to reconfigure your project to get this to >> work. >> > >> > We did the same change on iOS a while ago (moving from a precompiled >> > framework library to just copying over source files), and I think the >> > results were quite positive. It helps users file better bug reports, >> and >> I >> > think also encourages them to submit bug fixes. It will also make it >> easier >> > for Plugin developers to figure out our APIs since they'll be able to >> see & >> > tweak the code. >> > >> > Agree / object? >> >> >>
Re: Release Masters?
Think we already have this as per the issue tracker concept of 'leads' but I do agree formalizing the role a little more would help. I'd really love it if we got back to shipping to a date and not to any set of features, only finished work was being merged back to master, so cutting a release is a ceremony not a struggle. On Tue, Jun 18, 2013 at 3:48 AM, Andrew Grieve wrote: > Idea here would be to label someone as the "Release Master" for each > release. Responsibilities would include: > > - Creating branches > - Managing release bugs > - Nagging people responsible for unfinished release items > - Creating the final release .zip and uploading it > - Announcing the release > - Ensuring that the release process wiki page is up-to-date > > I think this would help make sure releases happen quicker and that release > tasks are not overlooked. It will also help with knowledge sharing I think.
Re: iOS - Webkit Debug Proxy
Yes, indeed you can use the awesome Chrome Debugging-Tools and live-debug your app. Really neat! Am 17.06.2013 um 22:48 schrieb Shazron : > Awesome - although if you are developing on Mac, you can already use Safari > 6: http://moduscreate.com/enable-remote-web-inspector-in-ios-6/ > But this will allow you to use Chrome if you want to, I suppose > > > On Mon, Jun 17, 2013 at 12:41 PM, Andreas Sander > wrote: > >> Hi! >> >> I just want to share a brilliant tool for iOS webkit debugging. >> >> It's a Google github project, s. >> https://github.com/google/ios-webkit-debug-proxy/ >> >> Oh man, it's really cool! The best thing is, it also works, due to the >> webview, with Cordova builded apps. It's really neat! >> >> Maybe you're already knowing it. >> >> With best regards, >> >> Andreas >> >>
How to build apache cordova project from command line?
Hi All, - I've setup apache cordova on my Windows/Cygwin platform. - I can create project using the command - cordova create . - I have added android platform using the command - cordova platform add android - I can run the sample 'html/css/js' using cordova ripple android. - I can upload the project to build.phonegap and get the .apk file. - I know from docs that I can setup eclipse and do the build. (I'm not looking for this) - But I cannot create .apk file using the command cordova build android. When I run the command, there is not output on the command line, the command just finishes. I cannot locate the .apk file. Is there a way in which I can create an .apk file from command line? (Looking for suggestions for other platforms as well) Link to SO posting: http://stackoverflow.com/questions/17140227/how-to-build-apache-cordova-project-from-command-line Thanks, -- -sowdri-
