date:20130114

Hi Marcel,

I've got this one my roadmap of tasks.

The short-term goal is to have http://docs.cordova.io host our
documentation and we'll link to it off http://cordova.io.

The longer-term goal is to have the generator and possibly templates
decoupled from the documentation. At that time, we'll redesign the
http://docs.cordova.io to use the http://cordova.io site design.

My plan is to start this work on February 1st and have it completed for the
next board report.

Michael

On Mon, Jan 14, 2013 at 8:52 AM, Ross Gardler rgard...@opendirective.comwrote:

 It not only makes sense I would consider it a priority. Having the only
 source of docs on a third party website is a no-go as far as I'm concerned.
 I raised this issue during incubation and was assured it was a transitional
 thing.

 Ross

 Sent from a mobile device, please excuse mistakes and brevity
 On 14 Jan 2013 08:44, Marcel Kinard cmarc...@gmail.com wrote:

  Would it make sense to host a copy of the docs on cordova.apache.org?
  Other Apache projects have their docs online at their apache.org site.
 
  A couple possibilities:
  1) build the html files and zip them up, so a consumer needs to only
  download and unzip and point their browser at their local offline copy.
  2) build the html files and post them unpacked to cordova.apache.org so
  they can be browsed directly without a zip or src download.
 
  My initial suggestion is to do both: something like /docs/download to
 hold
  the zip files and /docs/browse to have the tree starting with index.html.
 
  Or would it be better to host it in www.apache.org/dist/cordova?
 
  I am willing to do the initial setup and load.
 
  Comments?
 
  -- Marcel Kinard

[jira] [Reopened] (CB-1978) Cordova 2.2 iOS does not work with RequireJS


 [ 
https://issues.apache.org/jira/browse/CB-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Grieve reopened CB-1978:
---


Thanks for bringing this to our attention. I'll have a look into it. Would it 
be possible to upload a hello-world style zip of a project that uses require-js 
to do the loading?

 Cordova 2.2 iOS does not work with RequireJS
 

 Key: CB-1978
 URL: https://issues.apache.org/jira/browse/CB-1978
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0, 2.2.0
 Environment: Use RequireJS to loading cordova.js
 http://requirejs.org/
Reporter: Kenichi Yonekawa
Assignee: Andrew Grieve
Priority: Minor
 Fix For: Master


 Cordova does not fire `deviceready` when using RequireJS to loading cordova.js
 Because, cordova-ios accesses `window.cordova` object at 
 `webViewDidFinishLoad`
 However, window.cordova is undefined. It occurs JavaScript error.
 I create monkey patch for my project.
 it works for me.
 https://gist.github.com/4159669
 So, cordova-2.1.0 has same problem.
 My monkey patch is here.
 https://gist.github.com/3824310

--
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: Regarding inAppPurchase functionality implementation

Hello Rajeev,

We encourage PhoneGap questions to be posted on the PhoneGap Google Groups
[1].

The Apache Cordova mailing list is more centered around contributing to
Apache Cordova and less around support.

Congrats on the big upgrade from 1.3.0-2.3.0. That's no small step. A quick
search shows that the PhoneGap Plugin Repository has an InApp Purchase
plugin [2] updated for Cordova/PhoneGap 2.2.0. In your above message, you
did not mention what platform you are using but typically in app purchase
is iOS terminology, so I'm guessing you're looking for the iOS plugin.

If you have any further questions, please post them to the PhoneGap Google
Groups [1]. You will find an active community there.

Cheers,
Michael

[1] https://groups.google.com/forum/?fromgroups#!forum/phonegap
[2]
https://github.com/phonegap/phonegap-plugins/tree/master/iOS/InAppPurchaseManager

On Mon, Jan 14, 2013 at 5:18 AM, Rajeev Kumar raj...@arcgate.com wrote:

 Hello,

  I hope you are doing great !

 I have implemented the inAppPurchase functionality with phoneGap 1.3.0 and
 its working fine but last few days i have update the phoneGap 1.3.0 to
 Cordova 2.3.0 and also update all library and plugins but my inAppPurchase
 functionality not working so could you possible to provide the simple code
 of inAppPurchase that is help for me.

 Regards
 RAjeev.

Re: docs on cordova.apache.org

@Andrew I was thinking S3 so that a service can auto-update on each commit.
From Yohei's experience with the cordova.apache.org SVN setup, it looks
like automating that is a headache.

Michael

On Mon, Jan 14, 2013 at 9:16 AM, Andrew Grieve agri...@chromium.org wrote:

 cordova.io is a bunch of redirects. Do you mean to have
 docs.cordova.ioredirect to
 cordova.apache.org/docs (or something similar)


 On Mon, Jan 14, 2013 at 12:13 PM, Michael Brooks
 mich...@michaelbrooks.cawrote:

  Hi Marcel,
 
  I've got this one my roadmap of tasks.
 
  The short-term goal is to have http://docs.cordova.io host our
  documentation and we'll link to it off http://cordova.io.
 
  The longer-term goal is to have the generator and possibly templates
  decoupled from the documentation. At that time, we'll redesign the
  http://docs.cordova.io to use the http://cordova.io site design.
 
  My plan is to start this work on February 1st and have it completed for
 the
  next board report.
 
  Michael
 
  On Mon, Jan 14, 2013 at 8:52 AM, Ross Gardler 
 rgard...@opendirective.com
  wrote:
 
   It not only makes sense I would consider it a priority. Having the only
   source of docs on a third party website is a no-go as far as I'm
  concerned.
   I raised this issue during incubation and was assured it was a
  transitional
   thing.
  
   Ross
  
   Sent from a mobile device, please excuse mistakes and brevity
   On 14 Jan 2013 08:44, Marcel Kinard cmarc...@gmail.com wrote:
  
Would it make sense to host a copy of the docs on cordova.apache.org
 ?
Other Apache projects have their docs online at their apache.orgsite.
   
A couple possibilities:
1) build the html files and zip them up, so a consumer needs to only
download and unzip and point their browser at their local offline
 copy.
2) build the html files and post them unpacked to
 cordova.apache.orgso
they can be browsed directly without a zip or src download.
   
My initial suggestion is to do both: something like /docs/download to
   hold
the zip files and /docs/browse to have the tree starting with
  index.html.
   
Or would it be better to host it in www.apache.org/dist/cordova?
   
I am willing to do the initial setup and load.
   
Comments?
   
-- Marcel Kinard

Re: A little late butŠ welcome Marcel!

Welcome Marcel!

On Fri, Jan 11, 2013 at 4:03 PM, Filip Maj f...@adobe.com wrote:

 Marcel got voted in as a committer and PMC member for Apache Cordova last
 week. Marcel did a ton of work on this project across a few platforms
 leading up to his voting in.

 Marcel: congratulations and thank you for all your efforts to date!

Re: [FYI] call for cordova devs to participate in phonegap day event in july

Please come! Submit talks and meet the people using your code!

On Fri, Jan 11, 2013 at 3:46 PM, Brian LeRoux b...@brian.io wrote:

 http://goo.gl/fYW3J

Re: docs on cordova.apache.org

2013-01-14 Thread Shazron

I agree with Ross that it should be on Apache's servers and not somewhere
else (like Amazon S3). At most some dev could locally install Jenkins and
run a CI server with a script that can auto update the SVN repo (using
their creds), or something - until we can get a permanent solution


On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks mich...@michaelbrooks.cawrote:

 @Andrew I was thinking S3 so that a service can auto-update on each commit.
 From Yohei's experience with the cordova.apache.org SVN setup, it looks
 like automating that is a headache.

 Michael

 On Mon, Jan 14, 2013 at 9:16 AM, Andrew Grieve agri...@chromium.org
 wrote:

  cordova.io is a bunch of redirects. Do you mean to have
  docs.cordova.ioredirect to
  cordova.apache.org/docs (or something similar)
 
 
  On Mon, Jan 14, 2013 at 12:13 PM, Michael Brooks
  mich...@michaelbrooks.cawrote:
 
   Hi Marcel,
  
   I've got this one my roadmap of tasks.
  
   The short-term goal is to have http://docs.cordova.io host our
   documentation and we'll link to it off http://cordova.io.
  
   The longer-term goal is to have the generator and possibly templates
   decoupled from the documentation. At that time, we'll redesign the
   http://docs.cordova.io to use the http://cordova.io site design.
  
   My plan is to start this work on February 1st and have it completed for
  the
   next board report.
  
   Michael
  
   On Mon, Jan 14, 2013 at 8:52 AM, Ross Gardler 
  rgard...@opendirective.com
   wrote:
  
It not only makes sense I would consider it a priority. Having the
 only
source of docs on a third party website is a no-go as far as I'm
   concerned.
I raised this issue during incubation and was assured it was a
   transitional
thing.
   
Ross
   
Sent from a mobile device, please excuse mistakes and brevity
On 14 Jan 2013 08:44, Marcel Kinard cmarc...@gmail.com wrote:
   
 Would it make sense to host a copy of the docs on
 cordova.apache.org
  ?
 Other Apache projects have their docs online at their
 apache.orgsite.

 A couple possibilities:
 1) build the html files and zip them up, so a consumer needs to
 only
 download and unzip and point their browser at their local offline
  copy.
 2) build the html files and post them unpacked to
  cordova.apache.orgso
 they can be browsed directly without a zip or src download.

 My initial suggestion is to do both: something like /docs/download
 to
hold
 the zip files and /docs/browse to have the tree starting with
   index.html.

 Or would it be better to host it in www.apache.org/dist/cordova?

 I am willing to do the initial setup and load.

 Comments?

 -- Marcel Kinard

Re: Native URL functionality for files

2013-01-14 Thread Max Woghiren

I've sent a pull request that adds a third option to the
Camera.DestinationType and returns not supported errors in the relevant
methods (for now).


On Fri, Jan 11, 2013 at 3:03 PM, Shazron shaz...@gmail.com wrote:

 I like it. I seem to remember we discussed something related, like
 document:// shortcut to files in the app's Documents folder as well (iOS
 specific) but nothing came out of it.

 For those curious, AssetLibrary urls look like
 this: assets-library://asset/asset.JPG?id=13ext=JPG


 On Fri, Jan 11, 2013 at 10:21 AM, Max Woghiren m...@chromium.org wrote:

  Hi everyone,
 
  I'm working on implementing chrome apps file system functionality using
  Cordova.  I'm focusing on iOS first.
 
  I'm planning on using AssetsLibrary to prevent having to (1) send actual
  file data to and from JS unnecessarily and (2) save temporary copies of
  files.
 
  In order to use asset library URLs (and the equivalents on other
  platforms), I'd like to add a third Camera DestinationType: NATIVE_URL.
  In
  iOS, Camera would send back the assets-library URL, which can then be
  stored in a FileEntry.
 
  This type of URL would then be handled wherever necessary.  For instance,
  uploading an image to a server using FileTransfer would be able do it
  directly from the photo library, since it'd be given the assets-library
  URL.  File would have a bunch of changes to handle this as well.
 
  Please let me know if you have any comments, concerns, or things to
  consider about add this functionality.
 
  Thanks!
  -Max

[jira] [Commented] (CB-2212) FileSystem getFile() call never finds file on WP8 as isolated storage is empty

2013-01-14 Thread Jesse MacFadyen (JIRA)

[
https://issues.apache.org/jira/browse/CB-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552959#comment-13552959
]

Jesse MacFadyen commented on CB-2212:
-

Thanks Michael
Can you post a brief example demonstrating the issue?

FileSystem getFile() call never finds file on WP8 as isolated storage is empty
--

Key: CB-2212
URL: https://issues.apache.org/jira/browse/CB-2212
Project: Apache Cordova
Issue Type: Bug
Components: WP8
Affects Versions: 2.3.0
Reporter: Michael Fry
Assignee: Jesse MacFadyen

In attempting read a file included in my www folder I was continually
returned an error code of 0. In digging in it appears it was due to file not
found.
In the GapBrowser_Loaded handler there is a large chunk of commented out code
that notes that in WP8 isolated storage is no more required in WP8. It
appears that this suppresses the loading of isolated storage because when I
view my emulator using WP power tools it is empty.
The file i/o code in File.cs reads/writes using isolated storage. Without
the www files being loaded at startup it will never be able to make the reads
from things like settings or readme files.
After uncommenting the code and creating a CordovaSourceDictionary.xml file I
was able to load isolated storage. File reads then worked as designed.

--
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-2213) Add support for native URIs

Max Woghiren created CB-2213:


 Summary: Add support for native URIs
 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Joe Bowser
Priority: Minor


It would be useful to add the ability to access files directly from a device's 
photo/video library.  To do this, support for native URIs is necessary—for 
instance, iOS's assets-library:// scheme.

--
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-2087) Creating CordovaStarter-2.2.0(WP8) fails

2013-01-14 Thread Jesse MacFadyen (JIRA)


 [ 
https://issues.apache.org/jira/browse/CB-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jesse MacFadyen resolved CB-2087.
-

Resolution: Unresolved

This appears to be an issue only with the 2.2 template.  Please retest in 2.3.0

 Creating CordovaStarter-2.2.0(WP8) fails
 

 Key: CB-2087
 URL: https://issues.apache.org/jira/browse/CB-2087
 Project: Apache Cordova
  Issue Type: Bug
  Components: WP8
Affects Versions: 2.2.0
Reporter: Raj Singh
Assignee: Jesse MacFadyen
  Labels: build

 I am using VS2012 on Windows 8 OS. I have downloaded the Apache Cordova for 
 Windows Phone 8. I have followed the Getting Started steps in README.md. Now 
 when I am trying to create new project by choosing CordovaStarter template I 
 am getting an error.
 The project file 
 'C:\Users\raj.singh\AppData\Local\Temp\WindowsPhone8App.csproj' cannot be 
 opened.
 There is a missing project subtype. Subtype: 
 '{C089C8C0-30E0-80C0-CE093F111A43}' is unsupported by this installation.

--
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-2213) Add support for native URIs


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13552971#comment-13552971
 ] 

Max Woghiren commented on CB-2213:
--

I've submitted a preliminary pull request here: 
https://github.com/apache/cordova-ios/pull/6

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Joe Bowser
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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: JIRA update access

2013-01-14 Thread Filip Maj

Done and done

On 1/14/13 10:33 AM, Max Woghiren m...@chromium.org wrote:

Hi there,

Can someone please give me the ability to update JIRA bugs?

Thanks!
-Max

Re: Native URL functionality for files

2013-01-14 Thread Shazron

Thanks Max!
https://github.com/apache/cordova-ios/pull/6


On Mon, Jan 14, 2013 at 10:22 AM, Max Woghiren m...@chromium.org wrote:

 I've sent a pull request that adds a third option to the
 Camera.DestinationType and returns not supported errors in the relevant
 methods (for now).


 On Fri, Jan 11, 2013 at 3:03 PM, Shazron shaz...@gmail.com wrote:

  I like it. I seem to remember we discussed something related, like
  document:// shortcut to files in the app's Documents folder as well (iOS
  specific) but nothing came out of it.
 
  For those curious, AssetLibrary urls look like
  this: assets-library://asset/asset.JPG?id=13ext=JPG
 
 
  On Fri, Jan 11, 2013 at 10:21 AM, Max Woghiren m...@chromium.org
 wrote:
 
   Hi everyone,
  
   I'm working on implementing chrome apps file system functionality using
   Cordova.  I'm focusing on iOS first.
  
   I'm planning on using AssetsLibrary to prevent having to (1) send
 actual
   file data to and from JS unnecessarily and (2) save temporary copies of
   files.
  
   In order to use asset library URLs (and the equivalents on other
   platforms), I'd like to add a third Camera DestinationType: NATIVE_URL.
   In
   iOS, Camera would send back the assets-library URL, which can then be
   stored in a FileEntry.
  
   This type of URL would then be handled wherever necessary.  For
 instance,
   uploading an image to a server using FileTransfer would be able do it
   directly from the photo library, since it'd be given the assets-library
   URL.  File would have a bunch of changes to handle this as well.
  
   Please let me know if you have any comments, concerns, or things to
   consider about add this functionality.
  
   Thanks!
   -Max

[jira] [Commented] (CB-2213) Add support for native URIs

2013-01-14 Thread Joe Bowser (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553016#comment-13553016
 ] 

Joe Bowser commented on CB-2213:


On Android, the File System is where the pictures are stored, and we already 
have access to the SD Card.  In addition, we already have access to both the 
assets directory and the resources directory on Android, so I'm not sure how 
Android would be affected by this.

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Joe Bowser
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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: Regarding the InterfaceOrientation

2013-01-14 Thread Michal Mocny

Orientation bugs for ios6 were fixed in 2.1 (see
https://issues.apache.org/jira/browse/CB-1182).


On Mon, Jan 14, 2013 at 8:08 AM, Rajeev Singh rajeev6...@gmail.com wrote:

 Hello,

   I had developed the project in phoneGap 1.3.0 and orientation is working
 fine in iOS 5.0,5.1,and 4.3 but not working in iOS 6.0, iOS 6.1 so could
 you possible to guide me.

 --

 Thanks  Regards
 *Rajeev Kumar Singh** *
 Technical Architect
 P +91-9509974332
 iPhone/Android

Re: Moving plugin JS files around

Jesse, thanks for the explanation. Certainly my experience is just with
Android  iOS, so it's good to get opinions from the other platforms.

I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
of the shared plugin modules and hooks them up with the common bootstrap.
Why do you say that WebOS shares hardly any code?

Blackberry certainly seems to be a bit different in that it looks like it
is actually 4 platforms in one. Not sure why we don't just make it four
separate platforms. Gord?
That said, Blackberry uses the module system even more than other
platforms. I think it would be a lot of work to make plugin within
blackberry have it's own loading logic that selectively loads module based
on the sub-platform (if we went with a single-file pre-built approach).

With the single-file prebuilt approach, I'd guess it would look something
like this:

plugin.xml says which .js file to include for the platform:

platform name=android
  source-file src=filetransfer.js /
/platform


There is certainly a bug-report advantage to having each in its own .js
file. If everything is in cordova.js, and we get bugs with Error on line
##, we can't actually map that to a file. On the other hand, each platform
has bootstrap logic that must come after plugins are loaded. This might
turn into a source of errors if we have a bunch of .js files being added
via script tags.


One aspect of plugin JS that I don't want to lose, is our separate pass of
module - symbol (defaults/merges/clobbers). In fact, I think this is an
area that we may wish to enhance in the future. E.g. a couple of releases
ago we added the ability to print a deprecation message when old namespaces
are referenced. Other advantages of the system:
  - Helps authors write modules side-effect free modules
  - Allows us to detect symbol collisions
  - Gives us control over when the modules are loaded
 - e.g. We could add measurement to see how long this process takes
 - e.g. We could experiment with lazy-loaded modules by using JS
getters that return require(module)
 - e.g. We could use this to support exposing Cordova APIs to iframes


It might be possible for us to maintain the module-symbol mapping system
if we had plugins use pre-built .js files. E.g. their .js could be a
collection of cordova.define() calls, followed by a
cordova.registerModuleMappings() call. Is that what you're thinking?

In either way, I think I'd like to go ahead with this change of moving from
lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think this is
a good first step for either proposal.



On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen purplecabb...@gmail.comwrote:

 Hi Andrew,

 Having spent some time with this, I don't think it's awful, but I am
 worried about complexity.

 To me, a better approach is:

 - all plugins are simply ripped out of cordova-js
 - each plugin is distributed 'built' meaning for an API like file or
 contacts, there is only 1 js file, and while it depends on cordova.js,
 it is not part of it. ( or possibly just a concat )
 - plugman does the work of adding/removing but it is really just
 changing script tags for the js portion

 This means all our core plugs will need to be modified as the
 currently depend on the builder to wrap them.

 I spent some time working with your approach Andrew, and I think it
 sounds better than it is. Blackberry has 4 inter-related branches to
 consider, webos shares hardly any code with the other platforms, ... I
 am more keen on adding consistency than  I am to making the tool work
 around it.

 If we were only concerned with iOS, Android, and windows phone, then
 your  approach might be best, but there are some messes in there.

 I will continue to push for the simpler solution, but I won't block
 you anymore.
 I do think you should dive a little deeper into your approach, and
 possibly prove me wrong. I am completely open to further discussion on
 the point.


 Cheers,
  Jesse

 Sent from my iPhone5

 On 2013-01-10, at 8:09 PM, Andrew Grieve agri...@chromium.org wrote:

 On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner gtan...@gmail.com wrote:

  Ideally the require paths should stay true to the following rules (not
 that
  we follow them exactly now but we are close):
 
  1. should always start with cordova (in case we ever share a require
  framework)
  2. should follow as close as possible to the folder structure.
 
  We don't really do this now (but we are close).  It is mainly to help
 with
  navigation of the project from a require statement:
 
 var foo = require('cordova/plugin/foo/submodule')
 
  Ideally I should be able to navigate to a file that lives in:
 
 ~/cordova.js/plugin/foo/submodule.js
 
  But realistically we are probably going to see:
 
~/cordova.js/plugin/foo/js/submodule.js
 
  Assuming we are dumping everything into a js folder here is the mapping
  off the top of my head:
 
var foo = require('cordova/plugin/foo')

[jira] [Commented] (CB-2213) Add support for native URIs


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553034#comment-13553034
 ] 

Max Woghiren commented on CB-2213:
--

On Android, when Camera.getPicture is called with DestinationType.NATIVE_URI, 
it might be fine to just act as though FILE_URI were passed.

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Joe Bowser
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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-2214) Refactor JS files to be more ready to move into their own repositories

Andrew Grieve created CB-2214:
-

 Summary: Refactor JS files to be more ready to move into their own 
repositories
 Key: CB-2214
 URL: https://issues.apache.org/jira/browse/CB-2214
 Project: Apache Cordova
  Issue Type: Bug
  Components: CordovaJS
Reporter: Andrew Grieve
Assignee: Andrew Grieve
Priority: Minor
 Fix For: 2.4.0


Refer to ML discussion: http://callback.markmail.org/thread/xnhpidbnxg5ps7zr

This task is specifically to move files around. Instead of having : 
lib/$PLATFORM/plugin

We will have: plugin/PLUGIN_NAME/PLATFORM

Changing of common.js / platform.js is *not* a part of this issue, but instead 
will be a follow-up (requires more thought)



--
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: Moving plugin JS files around

Created a bug for the file moving part (CB-2214), but we can
continue discussing here.


On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve agri...@chromium.org wrote:

 Jesse, thanks for the explanation. Certainly my experience is just with
 Android  iOS, so it's good to get opinions from the other platforms.

 I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
 of the shared plugin modules and hooks them up with the common bootstrap.
 Why do you say that WebOS shares hardly any code?

 Blackberry certainly seems to be a bit different in that it looks like it
 is actually 4 platforms in one. Not sure why we don't just make it four
 separate platforms. Gord?
 That said, Blackberry uses the module system even more than other
 platforms. I think it would be a lot of work to make plugin within
 blackberry have it's own loading logic that selectively loads module based
 on the sub-platform (if we went with a single-file pre-built approach).

 With the single-file prebuilt approach, I'd guess it would look something
 like this:

 plugin.xml says which .js file to include for the platform:

 platform name=android
   source-file src=filetransfer.js /
 /platform


 There is certainly a bug-report advantage to having each in its own .js
 file. If everything is in cordova.js, and we get bugs with Error on line
 ##, we can't actually map that to a file. On the other hand, each platform
 has bootstrap logic that must come after plugins are loaded. This might
 turn into a source of errors if we have a bunch of .js files being added
 via script tags.


 One aspect of plugin JS that I don't want to lose, is our separate pass of
 module - symbol (defaults/merges/clobbers). In fact, I think this is an
 area that we may wish to enhance in the future. E.g. a couple of releases
 ago we added the ability to print a deprecation message when old namespaces
 are referenced. Other advantages of the system:
   - Helps authors write modules side-effect free modules
   - Allows us to detect symbol collisions
   - Gives us control over when the modules are loaded
  - e.g. We could add measurement to see how long this process takes
  - e.g. We could experiment with lazy-loaded modules by using JS
 getters that return require(module)
  - e.g. We could use this to support exposing Cordova APIs to iframes


 It might be possible for us to maintain the module-symbol mapping system
 if we had plugins use pre-built .js files. E.g. their .js could be a
 collection of cordova.define() calls, followed by a
 cordova.registerModuleMappings() call. Is that what you're thinking?

 In either way, I think I'd like to go ahead with this change of moving
 from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
 this is a good first step for either proposal.



 On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen 
 purplecabb...@gmail.comwrote:

 Hi Andrew,

 Having spent some time with this, I don't think it's awful, but I am
 worried about complexity.

 To me, a better approach is:

 - all plugins are simply ripped out of cordova-js
 - each plugin is distributed 'built' meaning for an API like file or
 contacts, there is only 1 js file, and while it depends on cordova.js,
 it is not part of it. ( or possibly just a concat )
 - plugman does the work of adding/removing but it is really just
 changing script tags for the js portion

 This means all our core plugs will need to be modified as the
 currently depend on the builder to wrap them.

 I spent some time working with your approach Andrew, and I think it
 sounds better than it is. Blackberry has 4 inter-related branches to
 consider, webos shares hardly any code with the other platforms, ... I
 am more keen on adding consistency than  I am to making the tool work
 around it.

 If we were only concerned with iOS, Android, and windows phone, then
 your  approach might be best, but there are some messes in there.

 I will continue to push for the simpler solution, but I won't block
 you anymore.
 I do think you should dive a little deeper into your approach, and
 possibly prove me wrong. I am completely open to further discussion on
 the point.


 Cheers,
  Jesse

 Sent from my iPhone5

 On 2013-01-10, at 8:09 PM, Andrew Grieve agri...@chromium.org wrote:

 On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner gtan...@gmail.com wrote:

  Ideally the require paths should stay true to the following rules (not
 that
  we follow them exactly now but we are close):
 
  1. should always start with cordova (in case we ever share a require
  framework)
  2. should follow as close as possible to the folder structure.
 
  We don't really do this now (but we are close).  It is mainly to help
 with
  navigation of the project from a require statement:
 
 var foo = require('cordova/plugin/foo/submodule')
 
  Ideally I should be able to navigate to a file that lives in:
 
 ~/cordova.js/plugin/foo/submodule.js
 
  But realistically we are probably going to see:

[jira] [Commented] (CB-2213) Add support for native URIs


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553036#comment-13553036
 ] 

Max Woghiren commented on CB-2213:
--

Also, Joe, this was assigned to you by default—I don't have a way to change 
assignee.  Sorry about that!  Feel free to reassign to me.  (I had Andrew 
Grieve try to do it, but there's apparently some access level neither of us has 
in order to do that.  If you have a moment to give me the ability to do that 
sort of thing, I'd really appreciate it!)

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Joe Bowser
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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-2213) Add support for native URIs


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553041#comment-13553041
 ] 

Max Woghiren commented on CB-2213:
--

Never mind—Fil gave me access.  Thanks Fil!

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Max Woghiren
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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: JIRA update access

2013-01-14 Thread Max Woghiren

Thanks!


On Mon, Jan 14, 2013 at 2:07 PM, Filip Maj f...@adobe.com wrote:

 Done and done

 On 1/14/13 10:33 AM, Max Woghiren m...@chromium.org wrote:

 Hi there,
 
 Can someone please give me the ability to update JIRA bugs?
 
 Thanks!
 -Max

[jira] [Commented] (CB-2213) Add support for native URIs


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553049#comment-13553049
 ] 

Andrew Grieve commented on CB-2213:
---

Joe - Wouldn't this map to content:// URIs on Android? Or do we have the 
ability to convert from content:// to file:// URLs? Never really worked with 
them on Android...

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Max Woghiren
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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-2213) Add support for native URIs

2013-01-14 Thread Simon MacDonald (JIRA)


[ 
https://issues.apache.org/jira/browse/CB-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553052#comment-13553052
 ] 

Simon MacDonald commented on CB-2213:
-

[~agrieve] I added some code to window.resolveLocalFileSystemURI so that it can 
handle most content:// uri's and return a file:// path. It is useful when 
taking a picture and then manipulating the file via the File API.

 Add support for native URIs
 ---

 Key: CB-2213
 URL: https://issues.apache.org/jira/browse/CB-2213
 Project: Apache Cordova
  Issue Type: New Feature
  Components: Android, CordovaJS, iOS
Reporter: Max Woghiren
Assignee: Max Woghiren
Priority: Minor

 It would be useful to add the ability to access files directly from a 
 device's photo/video library.  To do this, support for native URIs is 
 necessary—for instance, iOS's assets-library:// scheme.

--
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: Moving plugin JS files around

2013-01-14 Thread Gord Tanner

Yes,

BlackBerry is really 3 platforms in one.  We used to have them as 3
seperate platforms but was a headache for writing apps and ensuring that
you had the right javascript file in the right place.

Since I wrote most of the module stuff I agree I have abused it a little
with some of the tricks of the trade we have in place with the build step.

I would rather see us handle this via the exec bridge than including script
files in the DOM (stay with me for a little bit).

Not a final spec but an idea would be:

var foo = require('cordova/plugin/foo')

inside require we would realize we don't have foo preloaded in cordova.js
and call exec

exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: foo,
platform: ios})

where success would be something like:

function (func) {
cordova.define('cordova/plugin/foo', func);
}

Thoughts?


On Mon, Jan 14, 2013 at 3:41 PM, Jesse purplecabb...@gmail.com wrote:

 Comments inline below.


 On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve agri...@chromium.org
 wrote:

  Created a bug for the file moving part (CB-2214), but we can
  continue discussing here.
 
 
  On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Jesse, thanks for the explanation. Certainly my experience is just with
   Android  iOS, so it's good to get opinions from the other platforms.
  
   I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in
 all
   of the shared plugin modules and hooks them up with the common
 bootstrap.
   Why do you say that WebOS shares hardly any code?
 

 What I meant about WebOS, was just that it overwrites most of the APIs.
 There is a distinct difference in the way the platforms without a native
 counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)


  
   Blackberry certainly seems to be a bit different in that it looks like
 it
   is actually 4 platforms in one. Not sure why we don't just make it four
   separate platforms. Gord?
   That said, Blackberry uses the module system even more than other
   platforms. I think it would be a lot of work to make plugin within
   blackberry have it's own loading logic that selectively loads module
  based
   on the sub-platform (if we went with a single-file pre-built approach).
  
   With the single-file prebuilt approach, I'd guess it would look
 something
   like this:
  
   plugin.xml says which .js file to include for the platform:
  
   platform name=android
 source-file src=filetransfer.js /
   /platform
 

 And maybe even:
 platform name=android
   source-file src=filetransfer-common.js /
   source-file src=filetransfer-android.js /
 /platform
 ...



  
  
   There is certainly a bug-report advantage to having each in its own .js
   file. If everything is in cordova.js, and we get bugs with Error on
 line
   ##, we can't actually map that to a file. On the other hand, each
  platform
   has bootstrap logic that must come after plugins are loaded. This might
   turn into a source of errors if we have a bunch of .js files being
 added
   via script tags.
  
  
   One aspect of plugin JS that I don't want to lose, is our separate pass
  of
   module - symbol (defaults/merges/clobbers). In fact, I think this is
 an
   area that we may wish to enhance in the future. E.g. a couple of
 releases
   ago we added the ability to print a deprecation message when old
  namespaces
   are referenced. Other advantages of the system:
 - Helps authors write modules side-effect free modules
 - Allows us to detect symbol collisions
 - Gives us control over when the modules are loaded
- e.g. We could add measurement to see how long this process takes
- e.g. We could experiment with lazy-loaded modules by using JS
   getters that return require(module)
- e.g. We could use this to support exposing Cordova APIs to
 iframes
  
  
   It might be possible for us to maintain the module-symbol mapping
 system
   if we had plugins use pre-built .js files. E.g. their .js could be a
   collection of cordova.define() calls, followed by a
   cordova.registerModuleMappings() call. Is that what you're thinking?
 

 Yes, something like this.
 The plugin would be wrapped in a module-closure, and 'define' it's
 interface.

 cordova.define(my/namespace, function(require, exports, module) { });

 Some of this would need to reworked as currently we have 2 aliases for
 every plugin:
 navigator.accelerometer === cordova.plugin.accelerometer




  
   In either way, I think I'd like to go ahead with this change of moving
   from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
   this is a good first step for either proposal.
  
  
  
   On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen 
  purplecabb...@gmail.comwrote:
  
   Hi Andrew,
  
   Having spent some time with this, I don't think it's awful, but I am
   worried about complexity.
  
   To me, a better approach is:
  
   - all plugins are simply ripped out of cordova-js
   - each

Re: too long to package a release?

Ok. Lets go at this from a workflow perspective. One thing I'd like to
note is the two classifications of branch.

There are canonical branches:

- Dev (or Master)
- Unstable (or Next)
- Stable

And then there are feature branches.

Feature branches merge into Canonical branches as appropriate. But do
Canonical branches merge into each other? I'm thinking no. But want to
hear what ppl think. I feel this might be our source of collective
confusion.

[jira] [Updated] (CB-1978) Cordova 2.2 iOS does not work with RequireJS

2013-01-14 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/CB-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frederico Costa Galvão updated CB-1978:
---

Attachment: www.tar.gz

Sure.
All needed www's files, except for cordova-2.3.0.js. Just tested: works on 
android and doesn't on iOS.

 Cordova 2.2 iOS does not work with RequireJS
 

 Key: CB-1978
 URL: https://issues.apache.org/jira/browse/CB-1978
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: 2.1.0, 2.2.0
 Environment: Use RequireJS to loading cordova.js
 http://requirejs.org/
Reporter: Kenichi Yonekawa
Assignee: Andrew Grieve
Priority: Minor
 Fix For: Master

 Attachments: www.tar.gz


 Cordova does not fire `deviceready` when using RequireJS to loading cordova.js
 Because, cordova-ios accesses `window.cordova` object at 
 `webViewDidFinishLoad`
 However, window.cordova is undefined. It occurs JavaScript error.
 I create monkey patch for my project.
 it works for me.
 https://gist.github.com/4159669
 So, cordova-2.1.0 has same problem.
 My monkey patch is here.
 https://gist.github.com/3824310

--
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-2215) Support ArrayBuffer arguments from native to js over exec bridge

Michal Mocny created CB-2215:


 Summary: Support ArrayBuffer arguments from native to js over exec 
bridge
 Key: CB-2215
 URL: https://issues.apache.org/jira/browse/CB-2215
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Michal Mocny
Assignee: Michal Mocny
 Fix For: 2.4.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

Re: Moving plugin JS files around

On Mon, Jan 14, 2013 at 4:04 PM, Gord Tanner gtan...@gmail.com wrote:

 Yes,

 BlackBerry is really 3 platforms in one.  We used to have them as 3
 seperate platforms but was a headache for writing apps and ensuring that
 you had the right javascript file in the right place.

Just so I understand this, is it that blackberry has fat binaries? e.g. one
binary can be deployed to multiple platforms?

Otherwise, it's quite likely that cordova-cli will make the old
multi-platform headaches go away.



 Since I wrote most of the module stuff I agree I have abused it a little
 with some of the tricks of the trade we have in place with the build step.

 I would rather see us handle this via the exec bridge than including script
 files in the DOM (stay with me for a little bit).

 Not a final spec but an idea would be:

 var foo = require('cordova/plugin/foo')

 inside require we would realize we don't have foo preloaded in cordova.js
 and call exec

 exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: foo,
 platform: ios})

 where success would be something like:

 function (func) {
 cordova.define('cordova/plugin/foo', func);
 }

 Thoughts?


Gord, what's the motivation for this? Maybe that it addresses the having
alter script tags when adding/removing plugins?
You'd still need to deal with knowing which JS to include in your App
package (might be a bit bloated to include all JS for all platforms in all
apps)
It would mean making require() an async call (unless you use sync. XHRs),
and I think would have negative effects on performance.





 On Mon, Jan 14, 2013 at 3:41 PM, Jesse purplecabb...@gmail.com wrote:

  Comments inline below.
 
 
  On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Created a bug for the file moving part (CB-2214), but we can
   continue discussing here.
  
  
   On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve agri...@chromium.org
   wrote:
  
Jesse, thanks for the explanation. Certainly my experience is just
 with
Android  iOS, so it's good to get opinions from the other platforms.
   
I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in
  all
of the shared plugin modules and hooks them up with the common
  bootstrap.
Why do you say that WebOS shares hardly any code?
  
 
  What I meant about WebOS, was just that it overwrites most of the APIs.
  There is a distinct difference in the way the platforms without a native
  counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
 
 
   
Blackberry certainly seems to be a bit different in that it looks
 like
  it
is actually 4 platforms in one. Not sure why we don't just make it
 four
separate platforms. Gord?
That said, Blackberry uses the module system even more than other
platforms. I think it would be a lot of work to make plugin within
blackberry have it's own loading logic that selectively loads module
   based
on the sub-platform (if we went with a single-file pre-built
 approach).
   
With the single-file prebuilt approach, I'd guess it would look
  something
like this:
   
plugin.xml says which .js file to include for the platform:
   
platform name=android
  source-file src=filetransfer.js /
/platform
  
 
  And maybe even:
  platform name=android
source-file src=filetransfer-common.js /
source-file src=filetransfer-android.js /
  /platform
  ...
 
 
 
   
   
There is certainly a bug-report advantage to having each in its own
 .js
file. If everything is in cordova.js, and we get bugs with Error on
  line
##, we can't actually map that to a file. On the other hand, each
   platform
has bootstrap logic that must come after plugins are loaded. This
 might
turn into a source of errors if we have a bunch of .js files being
  added
via script tags.
   
   
One aspect of plugin JS that I don't want to lose, is our separate
 pass
   of
module - symbol (defaults/merges/clobbers). In fact, I think this is
  an
area that we may wish to enhance in the future. E.g. a couple of
  releases
ago we added the ability to print a deprecation message when old
   namespaces
are referenced. Other advantages of the system:
  - Helps authors write modules side-effect free modules
  - Allows us to detect symbol collisions
  - Gives us control over when the modules are loaded
 - e.g. We could add measurement to see how long this process
 takes
 - e.g. We could experiment with lazy-loaded modules by using JS
getters that return require(module)
 - e.g. We could use this to support exposing Cordova APIs to
  iframes
   
   
It might be possible for us to maintain the module-symbol mapping
  system
if we had plugins use pre-built .js files. E.g. their .js could be a
collection of cordova.define() calls, followed by a
cordova.registerModuleMappings() call. Is that what you're thinking?
  
 
  Yes, something

Re: Moving plugin JS files around

2013-01-14 Thread Gord Tanner

I was envisioning this working closer to the node_modules pattern.

Ideally with a module loading framework you should be able to XHR these
modules over at require time.

Here is where the debate of commonJS vrs AMD will heat up.  CommonJS will
require sync XHR because of it's ties to node (which I don't think is a bad
thing ;))

Since we have made the leap to a module based javascript layer we should be
able to leverage it to dynamically load the modules for us (may it be XHR,
over the exec bridge, voodoo).




On Mon, Jan 14, 2013 at 4:19 PM, Andrew Grieve agri...@chromium.org wrote:

 On Mon, Jan 14, 2013 at 4:04 PM, Gord Tanner gtan...@gmail.com wrote:

  Yes,
 
  BlackBerry is really 3 platforms in one.  We used to have them as 3
  seperate platforms but was a headache for writing apps and ensuring that
  you had the right javascript file in the right place.
 
 Just so I understand this, is it that blackberry has fat binaries? e.g. one
 binary can be deployed to multiple platforms?

 Otherwise, it's quite likely that cordova-cli will make the old
 multi-platform headaches go away.


 
  Since I wrote most of the module stuff I agree I have abused it a little
  with some of the tricks of the trade we have in place with the build
 step.
 
  I would rather see us handle this via the exec bridge than including
 script
  files in the DOM (stay with me for a little bit).
 
  Not a final spec but an idea would be:
 
  var foo = require('cordova/plugin/foo')
 
  inside require we would realize we don't have foo preloaded in cordova.js
  and call exec
 
  exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: foo,
  platform: ios})
 
  where success would be something like:
 
  function (func) {
  cordova.define('cordova/plugin/foo', func);
  }
 
  Thoughts?
 

 Gord, what's the motivation for this? Maybe that it addresses the having
 alter script tags when adding/removing plugins?
 You'd still need to deal with knowing which JS to include in your App
 package (might be a bit bloated to include all JS for all platforms in all
 apps)
 It would mean making require() an async call (unless you use sync. XHRs),
 and I think would have negative effects on performance.



 
 
  On Mon, Jan 14, 2013 at 3:41 PM, Jesse purplecabb...@gmail.com wrote:
 
   Comments inline below.
  
  
   On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve agri...@chromium.org
   wrote:
  
Created a bug for the file moving part (CB-2214), but we can
continue discussing here.
   
   
On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve agri...@chromium.org
 
wrote:
   
 Jesse, thanks for the explanation. Certainly my experience is just
  with
 Android  iOS, so it's good to get opinions from the other
 platforms.

 I took a look at WebOS, but pkg/cordova.webos.js does seem to pull
 in
   all
 of the shared plugin modules and hooks them up with the common
   bootstrap.
 Why do you say that WebOS shares hardly any code?
   
  
   What I meant about WebOS, was just that it overwrites most of the APIs.
   There is a distinct difference in the way the platforms without a
 native
   counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
  
  

 Blackberry certainly seems to be a bit different in that it looks
  like
   it
 is actually 4 platforms in one. Not sure why we don't just make it
  four
 separate platforms. Gord?
 That said, Blackberry uses the module system even more than other
 platforms. I think it would be a lot of work to make plugin within
 blackberry have it's own loading logic that selectively loads
 module
based
 on the sub-platform (if we went with a single-file pre-built
  approach).

 With the single-file prebuilt approach, I'd guess it would look
   something
 like this:

 plugin.xml says which .js file to include for the platform:

 platform name=android
   source-file src=filetransfer.js /
 /platform
   
  
   And maybe even:
   platform name=android
 source-file src=filetransfer-common.js /
 source-file src=filetransfer-android.js /
   /platform
   ...
  
  
  


 There is certainly a bug-report advantage to having each in its own
  .js
 file. If everything is in cordova.js, and we get bugs with Error
 on
   line
 ##, we can't actually map that to a file. On the other hand, each
platform
 has bootstrap logic that must come after plugins are loaded. This
  might
 turn into a source of errors if we have a bunch of .js files being
   added
 via script tags.


 One aspect of plugin JS that I don't want to lose, is our separate
  pass
of
 module - symbol (defaults/merges/clobbers). In fact, I think this
 is
   an
 area that we may wish to enhance in the future. E.g. a couple of
   releases
 ago we added the ability to print a deprecation message when old
namespaces
 are referenced. Other advantages of the system:
   -

Re: Moving plugin JS files around

On Mon, Jan 14, 2013 at 3:41 PM, Jesse purplecabb...@gmail.com wrote:

 Comments inline below.


 On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve agri...@chromium.org
 wrote:

  Created a bug for the file moving part (CB-2214), but we can
  continue discussing here.
 
 
  On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve agri...@chromium.org
  wrote:
 
   Jesse, thanks for the explanation. Certainly my experience is just with
   Android  iOS, so it's good to get opinions from the other platforms.
  
   I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in
 all
   of the shared plugin modules and hooks them up with the common
 bootstrap.
   Why do you say that WebOS shares hardly any code?
 

 What I meant about WebOS, was just that it overwrites most of the APIs.
 There is a distinct difference in the way the platforms without a native
 counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)


Where do you see it overwriting things? I see a few clobbers / merges in
their platform.js files, but it looks like they re-use the bulk of the
common code. The main difference seems to be that they implement exec() via
a require() call, and the native code on iOS/Android maps to .js code in
their plugin directory.

What would the plugin-specific build system look like for our core plugins?
When you say that they will have pre-built JS, is that just using the
cordova packager as well? Or do you think some other functionality is
required?





  
   Blackberry certainly seems to be a bit different in that it looks like
 it
   is actually 4 platforms in one. Not sure why we don't just make it four
   separate platforms. Gord?
   That said, Blackberry uses the module system even more than other
   platforms. I think it would be a lot of work to make plugin within
   blackberry have it's own loading logic that selectively loads module
  based
   on the sub-platform (if we went with a single-file pre-built approach).
  
   With the single-file prebuilt approach, I'd guess it would look
 something
   like this:
  
   plugin.xml says which .js file to include for the platform:
  
   platform name=android
 source-file src=filetransfer.js /
   /platform
 

 And maybe even:
 platform name=android
   source-file src=filetransfer-common.js /
   source-file src=filetransfer-android.js /
 /platform
 ...



  
  
   There is certainly a bug-report advantage to having each in its own .js
   file. If everything is in cordova.js, and we get bugs with Error on
 line
   ##, we can't actually map that to a file. On the other hand, each
  platform
   has bootstrap logic that must come after plugins are loaded. This might
   turn into a source of errors if we have a bunch of .js files being
 added
   via script tags.
  
  
   One aspect of plugin JS that I don't want to lose, is our separate pass
  of
   module - symbol (defaults/merges/clobbers). In fact, I think this is
 an
   area that we may wish to enhance in the future. E.g. a couple of
 releases
   ago we added the ability to print a deprecation message when old
  namespaces
   are referenced. Other advantages of the system:
 - Helps authors write modules side-effect free modules
 - Allows us to detect symbol collisions
 - Gives us control over when the modules are loaded
- e.g. We could add measurement to see how long this process takes
- e.g. We could experiment with lazy-loaded modules by using JS
   getters that return require(module)
- e.g. We could use this to support exposing Cordova APIs to
 iframes
  
  
   It might be possible for us to maintain the module-symbol mapping
 system
   if we had plugins use pre-built .js files. E.g. their .js could be a
   collection of cordova.define() calls, followed by a
   cordova.registerModuleMappings() call. Is that what you're thinking?
 

 Yes, something like this.
 The plugin would be wrapped in a module-closure, and 'define' it's
 interface.

 cordova.define(my/namespace, function(require, exports, module) { });

 Some of this would need to reworked as currently we have 2 aliases for
 every plugin:
 navigator.accelerometer === cordova.plugin.accelerometer

 Are you sure? I just tested this in mobile-spec on iOS, and cordova.plugin
is undefined.





  
   In either way, I think I'd like to go ahead with this change of moving
   from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
   this is a good first step for either proposal.
  
  
  
   On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen 
  purplecabb...@gmail.comwrote:
  
   Hi Andrew,
  
   Having spent some time with this, I don't think it's awful, but I am
   worried about complexity.
  
   To me, a better approach is:
  
   - all plugins are simply ripped out of cordova-js
   - each plugin is distributed 'built' meaning for an API like file or
   contacts, there is only 1 js file, and while it depends on cordova.js,
   it is not part of it. ( or possibly just a concat )
   - plugman does the

Re: too long to package a release?

2013-01-14 Thread Filip Maj


But do Canonical branches merge into each other? I'm thinking no.

My understanding:

- work goes into feature branches
- when contributor(s) deem feature is ready, merge into Unstable, which
then gets vetted (test!)
- at some point unstable merges into Next
- when tagging, we merge Next into Stable and tag

Would be different for bug fixes or other maintenance-type commits too,
ya? Those would be directly into Next.

Finally, what about hot fixes / patch releases? Branch off the tag in
Stable and put hot patch work into there?

Re: too long to package a release?

On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:


 But do Canonical branches merge into each other? I'm thinking no.

 My understanding:

 - work goes into feature branches
 - when contributor(s) deem feature is ready, merge into Unstable, which
 then gets vetted (test!)
 - at some point unstable merges into Next
 - when tagging, we merge Next into Stable and tag


That's my understanding as well.

The At some point part would be when we say hey, let's start working on
cutting a release, which should align with the wiki's
RoadMaphttp://wiki.apache.org/cordova/RoadmapProjects (which
targeted 2.3 for November, whoops!).



 Would be different for bug fixes or other maintenance-type commits too,
 ya? Those would be directly into Next.

It might cause headaches to commit bug-fixes into Next when it comes time
to merge Unstable - Next.



 Finally, what about hot fixes / patch releases? Branch off the tag in
 Stable and put hot patch work into there?

Agree. I think the flow here should be to commit change to Unstable and
then cherry-pick it into a branch off the tag (when feasible).

[jira] [Commented] (CB-2215) Support ArrayBuffer arguments from native to js over exec bridge


[ 
https://issues.apache.org/jira/browse/CB-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553175#comment-13553175
 ] 

Michal Mocny commented on CB-2215:
--

js: 
https://git-wip-us.apache.org/repos/asf?p=cordova-js.git;a=commit;h=099a51d157bf9bfcb112075f5406453504f40d72
ios: 
https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=6fe1f3d8e011bf79fec9c5c2857b63d7a2621436

 Support ArrayBuffer arguments from native to js over exec bridge
 

 Key: CB-2215
 URL: https://issues.apache.org/jira/browse/CB-2215
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Michal Mocny
Assignee: Michal Mocny
 Fix For: 2.4.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-2215) Support ArrayBuffer arguments from native to js over exec bridge


 [ 
https://issues.apache.org/jira/browse/CB-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michal Mocny resolved CB-2215.
--

Resolution: Fixed

 Support ArrayBuffer arguments from native to js over exec bridge
 

 Key: CB-2215
 URL: https://issues.apache.org/jira/browse/CB-2215
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Reporter: Michal Mocny
Assignee: Michal Mocny
 Fix For: 2.4.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-2216) Create Mobile Spec Test to benchmark ArrayBuffer exec bridge


[ 
https://issues.apache.org/jira/browse/CB-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553185#comment-13553185
 ] 

Michal Mocny commented on CB-2216:
--

Commit: 
https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit;h=f9ae3788b8470be2344f298f7732c1e44ad9b34c

The test is a manual test linked from the current exec() benchmark page, and 
uses a modified Echo plugin.  It does not yet test all configurations.

There seems to be some odd behavior on ios, where if I navigate to the test 
page, the Echo plugin fails to reply, but if I start the app on the test (by 
changing startPage), then it works fine.  DeviceReady does fire and cordova is 
loaded, so I'm not sure whats up.  Will not mark this fixed until that is 
reso'ved, not sure if its a bug on the test page of of mobile-spec/multi-page 
apps.

 Create Mobile Spec Test to benchmark ArrayBuffer exec bridge
 

 Key: CB-2216
 URL: https://issues.apache.org/jira/browse/CB-2216
 Project: Apache Cordova
  Issue Type: Bug
  Components: mobile-spec
Reporter: Michal Mocny
Assignee: Michal Mocny
 Fix For: 2.4.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

Re: too long to package a release?

So, what if Canonical branches only received merges from Feature branches...?

On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve agri...@chromium.org wrote:
 On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:


 But do Canonical branches merge into each other? I'm thinking no.

 My understanding:

 - work goes into feature branches
 - when contributor(s) deem feature is ready, merge into Unstable, which
 then gets vetted (test!)
 - at some point unstable merges into Next
 - when tagging, we merge Next into Stable and tag


 That's my understanding as well.

 The At some point part would be when we say hey, let's start working on
 cutting a release, which should align with the wiki's
 RoadMaphttp://wiki.apache.org/cordova/RoadmapProjects (which
 targeted 2.3 for November, whoops!).



 Would be different for bug fixes or other maintenance-type commits too,
 ya? Those would be directly into Next.

 It might cause headaches to commit bug-fixes into Next when it comes time
 to merge Unstable - Next.



 Finally, what about hot fixes / patch releases? Branch off the tag in
 Stable and put hot patch work into there?

 Agree. I think the flow here should be to commit change to Unstable and
 then cherry-pick it into a branch off the tag (when feasible).

Re: too long to package a release?

2013-01-14 Thread Braden Shepherdson

Andrew beat me to it. I don't see how feature branches can be practical. We
would have to keep track of all the feature branches on the server, and
their current merged state.

I think it makes sense for all new commits to go into unstable, whether
they be urgent bug fixes or new features or whatever. If the bug fix is
needed for a point release, it can be cherrypicked from unstable to the
point release's branch (skipping the others canonical branches), and then
the fix will be in the next {merge to next, merge to stable, full release}
as well, with no special effort.

As long as the flow always goes unstable - next - stable, there are no
problems. Cherrypicking into point release branches is safe, since those
are never merged in and no canonical branches are ever merged to them (or
else they wouldn't actually be point releases). There are no cycles in this
graph.


On Mon, Jan 14, 2013 at 5:18 PM, Andrew Grieve agri...@chromium.org wrote:

 Could you elaborate on what the workflow would be if we merged only from
 Feature branches?

 On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux b...@brian.io wrote:

  So, what if Canonical branches only received merges from Feature
  branches...?
 
  On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve agri...@chromium.org
  wrote:
   On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:
  
  
   But do Canonical branches merge into each other? I'm thinking no.
  
   My understanding:
  
   - work goes into feature branches
   - when contributor(s) deem feature is ready, merge into Unstable,
 which
   then gets vetted (test!)
   - at some point unstable merges into Next
   - when tagging, we merge Next into Stable and tag
  
  
   That's my understanding as well.
  
   The At some point part would be when we say hey, let's start working
  on
   cutting a release, which should align with the wiki's
   RoadMaphttp://wiki.apache.org/cordova/RoadmapProjects (which
   targeted 2.3 for November, whoops!).
  
  
  
   Would be different for bug fixes or other maintenance-type commits
 too,
   ya? Those would be directly into Next.
  
   It might cause headaches to commit bug-fixes into Next when it comes
 time
   to merge Unstable - Next.
  
  
  
   Finally, what about hot fixes / patch releases? Branch off the tag in
   Stable and put hot patch work into there?
  
   Agree. I think the flow here should be to commit change to Unstable and
   then cherry-pick it into a branch off the tag (when feasible).

Re: [BENCHMARKS] (CB-2216) Create Mobile Spec Test to benchmark ArrayBuffer exec bridge

From doing the exec bridge benchmark:
- Joe wrote a version of it that used Jasmine, but it didn't show the same
timing results as the hand-coded one. I don't think Jasmine is a good
option for benchmarks
- I wrote a version of the exec benchmark that used benchmark.js. Found it
worked really well with sync. code, but it's async mode messed up timings.

Possible that we could address/fix the problems I had with benchmark.js,
but I'd be open to hearing what other options we have as well. I like the
idea of this being integrated into your CI system :)


On Mon, Jan 14, 2013 at 5:15 PM, Filip Maj f...@adobe.com wrote:

 The ticket below is related to this:

 https://issues.apache.org/jira/browse/CB-1528


 I was gonna tackle that this week. I would like to automate as much of
 these tests/benchmarks as possible for easy integration into ci.cordova.io
 .

 Thoughts? Any other issues/benchmarks we can think of that should be
 linked up to CB-1528 ?

 On 1/14/13 2:10 PM, Michal Mocny (JIRA) j...@apache.org wrote:

 
 [
 
 https://issues.apache.org/jira/browse/CB-2216?page=com.atlassian.jira.plug
 in.system.issuetabpanels:comment-tabpanelfocusedCommentId=13553185#commen
 t-13553185 ]
 
 Michal Mocny commented on CB-2216:
 --
 
 Commit:
 
 https://git-wip-us.apache.org/repos/asf?p=cordova-mobile-spec.git;a=commit
 ;h=f9ae3788b8470be2344f298f7732c1e44ad9b34c
 
 The test is a manual test linked from the current exec() benchmark page,
 and uses a modified Echo plugin.  It does not yet test all configurations.
 
 There seems to be some odd behavior on ios, where if I navigate to the
 test page, the Echo plugin fails to reply, but if I start the app on the
 test (by changing startPage), then it works fine.  DeviceReady does fire
 and cordova is loaded, so I'm not sure whats up.  Will not mark this
 fixed until that is reso'ved, not sure if its a bug on the test page of
 of mobile-spec/multi-page apps.
 
  Create Mobile Spec Test to benchmark ArrayBuffer exec bridge
  
 
  Key: CB-2216
  URL: https://issues.apache.org/jira/browse/CB-2216
  Project: Apache Cordova
   Issue Type: Bug
   Components: mobile-spec
 Reporter: Michal Mocny
 Assignee: Michal Mocny
  Fix For: 2.4.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

Re: too long to package a release?

2013-01-14 Thread Filip Maj


My ideal here is to get to a point where there is something, whatever
it is, that we want to denote as a release. That something should not
require a whole bunch of coordination. There should be a working
branch, whatever we call it, ready for a tag and nothing else on any
arbitrary date to be considered a release. Does that make sense?

This is the goal we should have in mind for this discussion. So, agreed
and yes, does make sense :)

I would also prefer to stay away from cherry-picking as much as possible.

Re: too long to package a release?


 My ideal here is to get to a point where there is something, whatever
 it is, that we want to denote as a release. That something should not
 require a whole bunch of coordination. There should be a working
 branch, whatever we call it, ready for a tag and nothing else on any
 arbitrary date to be considered a release. Does that make sense?


Now's my chance to loop back to the other discussion point of this thread.
Building a release should be automated and I'd like to propose that we
introduce another script:

./bin/dist version

I would go as far as I require any platform wanting to be included in a
release
to include the distribution script. For what it's worth, BlackBerry has had
this
script for over two years.

Ideally, we should also standardize how to install any dev environment
dependencies. In my mind, it would make sense to require a script similar to
the UNIX ./configure to install and/or verify any developer dependencies.

To do an Apache Cordova release, we following steps similar to:

Each platform
Checkout stable git branch
$ ./configure
$ ./bin/dist version
 Zip everything up

On Mon, Jan 14, 2013 at 2:34 PM, Brian LeRoux b...@brian.io wrote:

 I think its basically the same except cherry picking not necessary.
 (But I've been known to be very wrong so take that with a grain of
 salt!)

 You work on a Feature branch. It gets rolled into Dev as needed so
 others can merge / collaborate on said feature. When it feels right
 instead of merging a large set of potentially breaking commits to
 Unstable the dev working on said feature just merges that feature.
 This would require more responsibility for the committer to keep track
 of their feature branches which I could see as being more overhead.

 My ideal here is to get to a point where there is something, whatever
 it is, that we want to denote as a release. That something should not
 require a whole bunch of coordination. There should be a working
 branch, whatever we call it, ready for a tag and nothing else on any
 arbitrary date to be considered a release. Does that make sense?



 On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve agri...@chromium.org
 wrote:
  Could you elaborate on what the workflow would be if we merged only from
  Feature branches?
 
  On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux b...@brian.io wrote:
 
  So, what if Canonical branches only received merges from Feature
  branches...?
 
  On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve agri...@chromium.org
  wrote:
   On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:
  
  
   But do Canonical branches merge into each other? I'm thinking no.
  
   My understanding:
  
   - work goes into feature branches
   - when contributor(s) deem feature is ready, merge into Unstable,
 which
   then gets vetted (test!)
   - at some point unstable merges into Next
   - when tagging, we merge Next into Stable and tag
  
  
   That's my understanding as well.
  
   The At some point part would be when we say hey, let's start
 working
  on
   cutting a release, which should align with the wiki's
   RoadMaphttp://wiki.apache.org/cordova/RoadmapProjects (which
   targeted 2.3 for November, whoops!).
  
  
  
   Would be different for bug fixes or other maintenance-type commits
 too,
   ya? Those would be directly into Next.
  
   It might cause headaches to commit bug-fixes into Next when it comes
 time
   to merge Unstable - Next.
  
  
  
   Finally, what about hot fixes / patch releases? Branch off the tag in
   Stable and put hot patch work into there?
  
   Agree. I think the flow here should be to commit change to Unstable
 and
   then cherry-pick it into a branch off the tag (when feasible).

Re: too long to package a release?

2013-01-14 Thread Braden Shepherdson

Aside from the extra overhead and coordination, which I think are a major
problem, this is a recipe for disaster with merge commits. This doesn't
require manual conflict resolution to be a problem. Just that, if feature
branches A and B are merged into dev/unstable and a merge commit is
created, they and their merge commit now have to be moved to unstable/next
as a group. These features may be from different developers, etc. etc.


On Mon, Jan 14, 2013 at 5:34 PM, Brian LeRoux b...@brian.io wrote:

 I think its basically the same except cherry picking not necessary.
 (But I've been known to be very wrong so take that with a grain of
 salt!)

 You work on a Feature branch. It gets rolled into Dev as needed so
 others can merge / collaborate on said feature. When it feels right
 instead of merging a large set of potentially breaking commits to
 Unstable the dev working on said feature just merges that feature.
 This would require more responsibility for the committer to keep track
 of their feature branches which I could see as being more overhead.

 My ideal here is to get to a point where there is something, whatever
 it is, that we want to denote as a release. That something should not
 require a whole bunch of coordination. There should be a working
 branch, whatever we call it, ready for a tag and nothing else on any
 arbitrary date to be considered a release. Does that make sense?



 On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve agri...@chromium.org
 wrote:
  Could you elaborate on what the workflow would be if we merged only from
  Feature branches?
 
  On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux b...@brian.io wrote:
 
  So, what if Canonical branches only received merges from Feature
  branches...?
 
  On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve agri...@chromium.org
  wrote:
   On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:
  
  
   But do Canonical branches merge into each other? I'm thinking no.
  
   My understanding:
  
   - work goes into feature branches
   - when contributor(s) deem feature is ready, merge into Unstable,
 which
   then gets vetted (test!)
   - at some point unstable merges into Next
   - when tagging, we merge Next into Stable and tag
  
  
   That's my understanding as well.
  
   The At some point part would be when we say hey, let's start
 working
  on
   cutting a release, which should align with the wiki's
   RoadMaphttp://wiki.apache.org/cordova/RoadmapProjects (which
   targeted 2.3 for November, whoops!).
  
  
  
   Would be different for bug fixes or other maintenance-type commits
 too,
   ya? Those would be directly into Next.
  
   It might cause headaches to commit bug-fixes into Next when it comes
 time
   to merge Unstable - Next.
  
  
  
   Finally, what about hot fixes / patch releases? Branch off the tag in
   Stable and put hot patch work into there?
  
   Agree. I think the flow here should be to commit change to Unstable
 and
   then cherry-pick it into a branch off the tag (when feasible).

Re: too long to package a release?

Hey shawn, feel free to kick up a new thread about Windows Phone dev.
We'd love your help. You can read how we'd like you to work w/ us
here:

http://wiki.apache.org/cordova/ContributorWorkflow


On Mon, Jan 14, 2013 at 2:33 PM, Shawn Wildermuth
shawn.li...@agilitrain.com wrote:
 Anyone actively working on the Windows Phone template and library? I am
 happy to pitch in but don't want to step on toes.  I would like to:

 - Improve the template eliminating opening pivoting animation.
 - Upgrade it to support WP8
 - Fix some issues with opening external links and phone links in the
 library.

 Can I proceed?

 - stw

 I don't even use spell check - my misspellings are on purpose.

Re: too long to package a release?

Oh, yes, that is true. I was assuming (naively) that this wouldn't be
a likely case if we were diligent about rebasing before commits
landing.

So, the real trick here is, a workflow of:

feature -- dev -- unstable -- stable

When, and more importantly who, does the Canonical brach to Canonical
branch merges? (Eg. dev -- stable )



On Mon, Jan 14, 2013 at 2:48 PM, Braden Shepherdson bra...@chromium.org wrote:
 Aside from the extra overhead and coordination, which I think are a major
 problem, this is a recipe for disaster with merge commits. This doesn't
 require manual conflict resolution to be a problem. Just that, if feature
 branches A and B are merged into dev/unstable and a merge commit is
 created, they and their merge commit now have to be moved to unstable/next
 as a group. These features may be from different developers, etc. etc.


 On Mon, Jan 14, 2013 at 5:34 PM, Brian LeRoux b...@brian.io wrote:

 I think its basically the same except cherry picking not necessary.
 (But I've been known to be very wrong so take that with a grain of
 salt!)

 You work on a Feature branch. It gets rolled into Dev as needed so
 others can merge / collaborate on said feature. When it feels right
 instead of merging a large set of potentially breaking commits to
 Unstable the dev working on said feature just merges that feature.
 This would require more responsibility for the committer to keep track
 of their feature branches which I could see as being more overhead.

 My ideal here is to get to a point where there is something, whatever
 it is, that we want to denote as a release. That something should not
 require a whole bunch of coordination. There should be a working
 branch, whatever we call it, ready for a tag and nothing else on any
 arbitrary date to be considered a release. Does that make sense?



 On Mon, Jan 14, 2013 at 2:18 PM, Andrew Grieve agri...@chromium.org
 wrote:
  Could you elaborate on what the workflow would be if we merged only from
  Feature branches?
 
  On Mon, Jan 14, 2013 at 5:14 PM, Brian LeRoux b...@brian.io wrote:
 
  So, what if Canonical branches only received merges from Feature
  branches...?
 
  On Mon, Jan 14, 2013 at 2:02 PM, Andrew Grieve agri...@chromium.org
  wrote:
   On Mon, Jan 14, 2013 at 4:54 PM, Filip Maj f...@adobe.com wrote:
  
  
   But do Canonical branches merge into each other? I'm thinking no.
  
   My understanding:
  
   - work goes into feature branches
   - when contributor(s) deem feature is ready, merge into Unstable,
 which
   then gets vetted (test!)
   - at some point unstable merges into Next
   - when tagging, we merge Next into Stable and tag
  
  
   That's my understanding as well.
  
   The At some point part would be when we say hey, let's start
 working
  on
   cutting a release, which should align with the wiki's
   RoadMaphttp://wiki.apache.org/cordova/RoadmapProjects (which
   targeted 2.3 for November, whoops!).
  
  
  
   Would be different for bug fixes or other maintenance-type commits
 too,
   ya? Those would be directly into Next.
  
   It might cause headaches to commit bug-fixes into Next when it comes
 time
   to merge Unstable - Next.
  
  
  
   Finally, what about hot fixes / patch releases? Branch off the tag in
   Stable and put hot patch work into there?
  
   Agree. I think the flow here should be to commit change to Unstable
 and
   then cherry-pick it into a branch off the tag (when feasible).

[jira] [Created] (CB-2219) Add checks for minimum Android requirements after cli install

2013-01-14 Thread Filip Maj (JIRA)

Filip Maj created CB-2219:
-

 Summary: Add checks for minimum Android requirements after cli 
install
 Key: CB-2219
 URL: https://issues.apache.org/jira/browse/CB-2219
 Project: Apache Cordova
  Issue Type: Bug
  Components: CLI
Affects Versions: 2.3.0
Reporter: Filip Maj
Assignee: Filip Maj
 Fix For: 2.4.0


If you don't have all / latest android sdk targets installed, you can't compile 
the jar.

The CLI tools should check for minimum compatibility after installation, and if 
the check fails, at the minimum let the user know.

--
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: Moving plugin JS files around

2013-01-14 Thread Jesse

 Where do you see it overwriting things? I see a few clobbers / merges 
...
Sorry, off topic ...

 Are you sure? I just tested this ...
Yeah, I was wrong about cordova.plugin, I thought I saw it somewhere, but
indeed, they are destroyed when bootstrapped.
One thing I did notice is that our API does not have a method to state that
for example,
cordova/plugin/accelerometer needs to be mapped to
navigator.accelerometer, although I am not sure this should be the job of
the 'define' function.  Still chewing on this ...


On Mon, Jan 14, 2013 at 1:42 PM, Andrew Grieve agri...@chromium.org wrote:

 Are you sure?





-- 
@purplecabbage
risingj.com

Re: too long to package a release?

2013-01-14 Thread Marcel Kinard

Shawn, be aware that there are separate git repos for Windows desktop 8, 
WP7, and WP8.


On 1/14/2013 5:33 PM, Shawn Wildermuth wrote:

- Upgrade it to support WP8

Re: too long to package a release?

2013-01-14 Thread Marcel Kinard

Sorry if this got asked before, but does a feature branch get deleted 
after it is merged? Just wondering about branch clutter over a long 
period, or if this is just the same as a topic branch using today's 
committer workflow.


On 1/14/2013 5:34 PM, Brian LeRoux wrote:

You work on a Feature branch. It gets rolled into Dev as needed so
others can merge / collaborate on said feature. When it feels right
instead of merging a large set of potentially breaking commits to
Unstable the dev working on said feature just merges that feature.
This would require more responsibility for the committer to keep track
of their feature branches which I could see as being more overhead.

[jira] [Resolved] (CB-2183) [iOS] FileTransfer.didReceiveResponse may not return NSHTTPURLResponse