Re: [plugman] universe and plugin version support needed
+1 for ONE manifest (though that being XML or JSON is the decision, I guess) +1 for plugman create ;) +1 for plugman publish ;) hehe On 23/03/2013, at 2:06 PM, Anis KADRI wrote: > Yes, templates are definitely in the roadmap. A lot of people have > requested it. The goal is to make it super easy for plugin authors to make > their plugins install-able/discoverable. > > I didn't ask for a second manifest. Right now plugin authors can register > plugins to the cordova universe via a web form > (http://plugins.cordova.iowhich I haven't advertised much). We can > just ask them to specify their > plugin version and compatible corodova version and we will deal with the > rest. Eventually, they should be able to publish/unpublish newer versions > directly through plugman (kinda like npm publish). > > So big NO to other manifests, it's already hard enough to convince people > to convert their existing plugins to make them compatible with our spec. > > > On Fri, Mar 22, 2013 at 7:52 PM, Tommy-Carlos Williams > wrote: > >> Yeah exactly… I think it would a great bridge over the moat that has been >> built up around plugin authoring over the last year or so… >> >> - tommy >> >> On 23/03/2013, at 1:46 PM, Michal Mocny wrote: >> >>> Huge +1 to plugin templates. >>> >>> (we already have an app template, right?) >>> >>> -Michal >>> >>> >>> On Fri, Mar 22, 2013 at 10:39 PM, Tommy-Carlos Williams >>> wrote: >>> The barrier of having more config files is real and change is starting >> to cause fatigue amongst the plugin authors I deal with regularly. Having said that, I think JSON would be a welcome change overall… There really are not that many plugins that are set up with a plugin.xml yet that I know of anyway. People on this list are probably the authors >> or maintainers of most of them. ;) I know we are going to start getting tool fatigue ourselves soon, but would something like npm's init[1] be useful to alleviate some of the barriers? Much like the cordova cli sets you up with a folder structure (similarly the yeoman tooling for web dev) maybe we could add a command >> to ask a few questions (or take a few args) and spit out some sane defaults and create a structure for plugin dev? - Tommy-Carlos "fighting for plugin authors since 2010" Williams :P [1] https://npmjs.org/doc/init.html On 23/03/2013, at 1:18 PM, Michal Mocny wrote: > I generally prefer json whenever possible as well, so if its feasible >> to > change I'de give that a +1, but I'm not sure how many plugins out there > already use the manifest based structure. > > As far as creating a second manifest just to register with a universe, this > isn't unheard of may have benefits, but its yet another barrier for >> entry > for 3rdparty plugin devs. It would be really awesome if sharing >> plugins > with the world were as simple as providing a git repo+tag+directory. >> I'm > not sure I buy the versioning argument, whatever structure we come up with > for version dependancies will have the same likelihood of changing over > time no matter which file we put it in. > > -Michal > > > On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI wrote: > >> Yeah the only issue with plugin.xml is that it's XML :-D >> >> It would be so much easier to have it stored in JSON. We can make plugman >> parse the XML from a remote source but I would rather store everything in >> JSON. >> >> Also there can be multiple versions of plugin.xml. I think that is a good >> enough reason to store the relevant data about plugins (compatible cordova >> versions with a given plugin version, dependencies, etc...) in an >> easy-to-read format (JSON). There is a bit of duplication yes but it's for >> a good cause and the gain is huge. >> >> The submission process would be: >> - A plugin author submits a new plugin, gives it a version and >> specifies >> which version of cordova it was tested on. >> - A new version of Cordova comes out and requires the plugin author to >> update their plugin to stay compatible. >> - We start building the Cordova version <=> plugin version mapping >> like >> that. >> >> Thoughts ? >> >> -a >> >> >> On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: >> >>> makes sense to me; we'll likely want to query on that stuff >> eventually >>> >>> On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny >>> wrote: Should the universe just keep a copy of a plugin.xml so that it can >> have >>> a list of plugin dependancies and everything? plugin.xml will already >>> have a list of compatible cordova versions, right? Then the
Re: Platform-level command line scripts ;)
And so the consensus seems to involve breaking down that logic in cordova.js and cordova into multiple files inside a lib sub-directory. I don't really like the idea but I don't really care either as long as the same set of commands is available across platforms. Hopefully, next time we will change/update these things it will be for a real reason (such as SDK tools updates etc...) and not because we think that there might be a better implementation in C#. These scripts have been implemented/renamed/changed using every possible scripting language that I know of (ruby, python, bash, cscript, node, coffeescript, ...) since the beginning of the project. On Fri, Mar 22, 2013 at 5:49 PM, Andrew Grieve wrote: > Given that cordova-cli will be the end goal for people typing in commands, > I guess I don't really care what the scripts look like as long as they are > consistent. > > So.. I guess I'd be fine to have build-release and build-debug as top-level > scripts. Since: > > It would seem weird to me to have a top-level build command that shells out > to build-release vs build-debug. These scripts are identical except for a > single flag, so I think they'd be implemented by calling a common helper > script. Trying to appease both fewer scripts and lots of script ends us up > with a pyramid of scripts! > > > Right now the Android scripts work by: > > 1. Each linux script has an equivalent window .bat file of the same name > 2a. Each .bat forwards to cordova.bat, which forwards to cordova.js > 2b. Each unix script forwards to cordova > 3. cordova.js and cordova have all of the actual logic. > > > > On Fri, Mar 22, 2013 at 7:48 PM, Jeffrey Heifetz >wrote: > > > I like this solution to platform scripts, the only addition I would add > is > > that if the platform allows multiple targets, perhaps it could be > possible > > to set a default one that would be used instead of the timeout to first > one > > (although I suppose that makes first entry inherent default). > > > > Sent from my BlackBerry 10 smartphone. > > From: Benn Mapes > > Sent: Friday, March 22, 2013 6:57 PM > > To: dev@cordova.apache.org > > Reply To: dev@cordova.apache.org > > Subject: Re: Platform-level command line scripts ;) > > > > > > +1 > > I think that would be a good place for the check_reqs script > > > > > > On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj wrote: > > > > > One more addition: based on responses from the cordova-cli threads, it > > > looks like we'll also add a `check_reqs` script to each platform > (perhaps > > > under /cordova/lib) > > > > > > On 3/22/13 3:10 PM, "Michael Wolf" wrote: > > > > > > >I like this. > > > > > > > >mw > > > > > > > >On 3/22/13 6:03 PM, "Brian LeRoux" wrote: > > > > > > > >>YES. Do it. > > > >> > > > >>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: > > > >>> Hai gaiz! > > > >>> > > > >>> Main contention between the two "camps" in this debate is four vs > > eight > > > >>> scripts.. But Brian points out that refactoring smaller bits of > > > >>> functionality into their own script allows us to "have our cake and > > eat > > > >>>it > > > >>> too". This, in turn, results in four + (a subset of the 8) = 10 > > scripts > > > >>>in > > > >>> total.. Which is an argument for just starting with smaller more > > > >>>discrete > > > >>> scripts to begin with, lol. > > > >>> > > > >>> How about this as a middle ground: > > > >>> > > > >>> - under /cordova/ we have the four scripts Anis/Andrew recommend: > > > >>>clean, > > > >>> log, build and run. These call into various scripts under > > cordova/lib, > > > >>> such as.. > > > >>> - under /cordova/lib we have the ~6 scripts I recommended: > > build-debug, > > > >>> build-release, start-emulator, deploy-device, deploy-emulator, and > > > >>> possibly a list-devices one as well. > > > >>> > > > >>> The final point is nailing what `run` does, step-by-step. > > Paraphrasing > > > >>> Anis: > > > >>> > > > >>> If device(s) connected: > > > >>> * Pick device (ignore emulators). > > > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > > > >>>devices > > > >>> are connected (ignore emulators). > > > >>> > > > >>> If device(s) not connected: > > > >>> * Emulator if it is running > > > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > > > >>> emulators are running. > > > >>> * Start emulator. If you have multiple ones set up (Android's > case), > > > >>> prompt, timeout and launch first one (5 to 10 seconds). > > > >>> > > > >>> Yes/no/discuss. Let's try to get to a consensus :) > > > >>> > > > >>> > > > >>> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > > > >>> > > > I knew you'd bring that up! We'll talk more tmrw. > > > > > > On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI > > > wrote: > > > > Šor you can have functions do discrete actions like so: > > > > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f > > > >= > > > >bi > > > > > >
Re: Plugin Repos Created!
Cool! Now we need to populate them at least as fast as it took to get them created :-) On Fri, Mar 22, 2013 at 5:54 PM, Andrew Grieve wrote: > https://issues.apache.org/jira/browse/INFRA-5839 >
Re: [plugman] universe and plugin version support needed
Yes, templates are definitely in the roadmap. A lot of people have requested it. The goal is to make it super easy for plugin authors to make their plugins install-able/discoverable. I didn't ask for a second manifest. Right now plugin authors can register plugins to the cordova universe via a web form (http://plugins.cordova.iowhich I haven't advertised much). We can just ask them to specify their plugin version and compatible corodova version and we will deal with the rest. Eventually, they should be able to publish/unpublish newer versions directly through plugman (kinda like npm publish). So big NO to other manifests, it's already hard enough to convince people to convert their existing plugins to make them compatible with our spec. On Fri, Mar 22, 2013 at 7:52 PM, Tommy-Carlos Williams wrote: > Yeah exactly… I think it would a great bridge over the moat that has been > built up around plugin authoring over the last year or so… > > - tommy > > On 23/03/2013, at 1:46 PM, Michal Mocny wrote: > > > Huge +1 to plugin templates. > > > > (we already have an app template, right?) > > > > -Michal > > > > > > On Fri, Mar 22, 2013 at 10:39 PM, Tommy-Carlos Williams > > wrote: > > > >> The barrier of having more config files is real and change is starting > to > >> cause fatigue amongst the plugin authors I deal with regularly. > >> > >> Having said that, I think JSON would be a welcome change overall… > >> > >> There really are not that many plugins that are set up with a plugin.xml > >> yet that I know of anyway. People on this list are probably the authors > or > >> maintainers of most of them. ;) > >> > >> I know we are going to start getting tool fatigue ourselves soon, but > >> would something like npm's init[1] be useful to alleviate some of the > >> barriers? Much like the cordova cli sets you up with a folder structure > >> (similarly the yeoman tooling for web dev) maybe we could add a command > to > >> ask a few questions (or take a few args) and spit out some sane defaults > >> and create a structure for plugin dev? > >> > >> - Tommy-Carlos "fighting for plugin authors since 2010" Williams > >> > >> :P > >> > >> > >> [1] https://npmjs.org/doc/init.html > >> > >> > >> > >> On 23/03/2013, at 1:18 PM, Michal Mocny wrote: > >> > >>> I generally prefer json whenever possible as well, so if its feasible > to > >>> change I'de give that a +1, but I'm not sure how many plugins out there > >>> already use the manifest based structure. > >>> > >>> As far as creating a second manifest just to register with a universe, > >> this > >>> isn't unheard of may have benefits, but its yet another barrier for > entry > >>> for 3rdparty plugin devs. It would be really awesome if sharing > plugins > >>> with the world were as simple as providing a git repo+tag+directory. > I'm > >>> not sure I buy the versioning argument, whatever structure we come up > >> with > >>> for version dependancies will have the same likelihood of changing over > >>> time no matter which file we put it in. > >>> > >>> -Michal > >>> > >>> > >>> On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI > >> wrote: > >>> > Yeah the only issue with plugin.xml is that it's XML :-D > > It would be so much easier to have it stored in JSON. We can make > >> plugman > parse the XML from a remote source but I would rather store everything > >> in > JSON. > > Also there can be multiple versions of plugin.xml. I think that is a > >> good > enough reason to store the relevant data about plugins (compatible > >> cordova > versions with a given plugin version, dependencies, etc...) in an > easy-to-read format (JSON). There is a bit of duplication yes but it's > >> for > a good cause and the gain is huge. > > The submission process would be: > - A plugin author submits a new plugin, gives it a version and > specifies > which version of cordova it was tested on. > - A new version of Cordova comes out and requires the plugin author to > update their plugin to stay compatible. > - We start building the Cordova version <=> plugin version mapping > like > that. > > Thoughts ? > > -a > > > On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: > > > makes sense to me; we'll likely want to query on that stuff > eventually > > > > On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny > > wrote: > >> Should the universe just keep a copy of a plugin.xml so that it can > have > > a > >> list of plugin dependancies and everything? plugin.xml will already > > have a > >> list of compatible cordova versions, right? > >> > >> Then the universe can manage a reverse mapping if it wants fast > >> access. > >> > >> -Michal > >> > >> > >> On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > >> > >>> A plugin should specify the Cordova versions it supports too. > >>> >
Re: [plugman] universe and plugin version support needed
Yeah exactly… I think it would a great bridge over the moat that has been built up around plugin authoring over the last year or so… - tommy On 23/03/2013, at 1:46 PM, Michal Mocny wrote: > Huge +1 to plugin templates. > > (we already have an app template, right?) > > -Michal > > > On Fri, Mar 22, 2013 at 10:39 PM, Tommy-Carlos Williams > wrote: > >> The barrier of having more config files is real and change is starting to >> cause fatigue amongst the plugin authors I deal with regularly. >> >> Having said that, I think JSON would be a welcome change overall… >> >> There really are not that many plugins that are set up with a plugin.xml >> yet that I know of anyway. People on this list are probably the authors or >> maintainers of most of them. ;) >> >> I know we are going to start getting tool fatigue ourselves soon, but >> would something like npm's init[1] be useful to alleviate some of the >> barriers? Much like the cordova cli sets you up with a folder structure >> (similarly the yeoman tooling for web dev) maybe we could add a command to >> ask a few questions (or take a few args) and spit out some sane defaults >> and create a structure for plugin dev? >> >> - Tommy-Carlos "fighting for plugin authors since 2010" Williams >> >> :P >> >> >> [1] https://npmjs.org/doc/init.html >> >> >> >> On 23/03/2013, at 1:18 PM, Michal Mocny wrote: >> >>> I generally prefer json whenever possible as well, so if its feasible to >>> change I'de give that a +1, but I'm not sure how many plugins out there >>> already use the manifest based structure. >>> >>> As far as creating a second manifest just to register with a universe, >> this >>> isn't unheard of may have benefits, but its yet another barrier for entry >>> for 3rdparty plugin devs. It would be really awesome if sharing plugins >>> with the world were as simple as providing a git repo+tag+directory. I'm >>> not sure I buy the versioning argument, whatever structure we come up >> with >>> for version dependancies will have the same likelihood of changing over >>> time no matter which file we put it in. >>> >>> -Michal >>> >>> >>> On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI >> wrote: >>> Yeah the only issue with plugin.xml is that it's XML :-D It would be so much easier to have it stored in JSON. We can make >> plugman parse the XML from a remote source but I would rather store everything >> in JSON. Also there can be multiple versions of plugin.xml. I think that is a >> good enough reason to store the relevant data about plugins (compatible >> cordova versions with a given plugin version, dependencies, etc...) in an easy-to-read format (JSON). There is a bit of duplication yes but it's >> for a good cause and the gain is huge. The submission process would be: - A plugin author submits a new plugin, gives it a version and specifies which version of cordova it was tested on. - A new version of Cordova comes out and requires the plugin author to update their plugin to stay compatible. - We start building the Cordova version <=> plugin version mapping like that. Thoughts ? -a On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: > makes sense to me; we'll likely want to query on that stuff eventually > > On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny > wrote: >> Should the universe just keep a copy of a plugin.xml so that it can have > a >> list of plugin dependancies and everything? plugin.xml will already > have a >> list of compatible cordova versions, right? >> >> Then the universe can manage a reverse mapping if it wants fast >> access. >> >> -Michal >> >> >> On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: >> >>> A plugin should specify the Cordova versions it supports too. >>> >>> On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: I am sure we all agree to this. Want to get a sense of how it will happen. Anis you mentioned you need Braden to commit the JS stuff first? >>> > >> >>
Re: [plugman] universe and plugin version support needed
Huge +1 to plugin templates. (we already have an app template, right?) -Michal On Fri, Mar 22, 2013 at 10:39 PM, Tommy-Carlos Williams wrote: > The barrier of having more config files is real and change is starting to > cause fatigue amongst the plugin authors I deal with regularly. > > Having said that, I think JSON would be a welcome change overall… > > There really are not that many plugins that are set up with a plugin.xml > yet that I know of anyway. People on this list are probably the authors or > maintainers of most of them. ;) > > I know we are going to start getting tool fatigue ourselves soon, but > would something like npm's init[1] be useful to alleviate some of the > barriers? Much like the cordova cli sets you up with a folder structure > (similarly the yeoman tooling for web dev) maybe we could add a command to > ask a few questions (or take a few args) and spit out some sane defaults > and create a structure for plugin dev? > > - Tommy-Carlos "fighting for plugin authors since 2010" Williams > > :P > > > [1] https://npmjs.org/doc/init.html > > > > On 23/03/2013, at 1:18 PM, Michal Mocny wrote: > > > I generally prefer json whenever possible as well, so if its feasible to > > change I'de give that a +1, but I'm not sure how many plugins out there > > already use the manifest based structure. > > > > As far as creating a second manifest just to register with a universe, > this > > isn't unheard of may have benefits, but its yet another barrier for entry > > for 3rdparty plugin devs. It would be really awesome if sharing plugins > > with the world were as simple as providing a git repo+tag+directory. I'm > > not sure I buy the versioning argument, whatever structure we come up > with > > for version dependancies will have the same likelihood of changing over > > time no matter which file we put it in. > > > > -Michal > > > > > > On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI > wrote: > > > >> Yeah the only issue with plugin.xml is that it's XML :-D > >> > >> It would be so much easier to have it stored in JSON. We can make > plugman > >> parse the XML from a remote source but I would rather store everything > in > >> JSON. > >> > >> Also there can be multiple versions of plugin.xml. I think that is a > good > >> enough reason to store the relevant data about plugins (compatible > cordova > >> versions with a given plugin version, dependencies, etc...) in an > >> easy-to-read format (JSON). There is a bit of duplication yes but it's > for > >> a good cause and the gain is huge. > >> > >> The submission process would be: > >> - A plugin author submits a new plugin, gives it a version and specifies > >> which version of cordova it was tested on. > >> - A new version of Cordova comes out and requires the plugin author to > >> update their plugin to stay compatible. > >> - We start building the Cordova version <=> plugin version mapping like > >> that. > >> > >> Thoughts ? > >> > >> -a > >> > >> > >> On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: > >> > >>> makes sense to me; we'll likely want to query on that stuff eventually > >>> > >>> On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny > >>> wrote: > Should the universe just keep a copy of a plugin.xml so that it can > >> have > >>> a > list of plugin dependancies and everything? plugin.xml will already > >>> have a > list of compatible cordova versions, right? > > Then the universe can manage a reverse mapping if it wants fast > access. > > -Michal > > > On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > > > A plugin should specify the Cordova versions it supports too. > > > > On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: > >> I am sure we all agree to this. Want to get a sense of how it will > >> happen. Anis you mentioned you need Braden to commit the JS stuff > >> first? > > > >>> > >> > >
Re: [plugman] universe and plugin version support needed
The barrier of having more config files is real and change is starting to cause fatigue amongst the plugin authors I deal with regularly. Having said that, I think JSON would be a welcome change overall… There really are not that many plugins that are set up with a plugin.xml yet that I know of anyway. People on this list are probably the authors or maintainers of most of them. ;) I know we are going to start getting tool fatigue ourselves soon, but would something like npm's init[1] be useful to alleviate some of the barriers? Much like the cordova cli sets you up with a folder structure (similarly the yeoman tooling for web dev) maybe we could add a command to ask a few questions (or take a few args) and spit out some sane defaults and create a structure for plugin dev? - Tommy-Carlos "fighting for plugin authors since 2010" Williams :P [1] https://npmjs.org/doc/init.html On 23/03/2013, at 1:18 PM, Michal Mocny wrote: > I generally prefer json whenever possible as well, so if its feasible to > change I'de give that a +1, but I'm not sure how many plugins out there > already use the manifest based structure. > > As far as creating a second manifest just to register with a universe, this > isn't unheard of may have benefits, but its yet another barrier for entry > for 3rdparty plugin devs. It would be really awesome if sharing plugins > with the world were as simple as providing a git repo+tag+directory. I'm > not sure I buy the versioning argument, whatever structure we come up with > for version dependancies will have the same likelihood of changing over > time no matter which file we put it in. > > -Michal > > > On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI wrote: > >> Yeah the only issue with plugin.xml is that it's XML :-D >> >> It would be so much easier to have it stored in JSON. We can make plugman >> parse the XML from a remote source but I would rather store everything in >> JSON. >> >> Also there can be multiple versions of plugin.xml. I think that is a good >> enough reason to store the relevant data about plugins (compatible cordova >> versions with a given plugin version, dependencies, etc...) in an >> easy-to-read format (JSON). There is a bit of duplication yes but it's for >> a good cause and the gain is huge. >> >> The submission process would be: >> - A plugin author submits a new plugin, gives it a version and specifies >> which version of cordova it was tested on. >> - A new version of Cordova comes out and requires the plugin author to >> update their plugin to stay compatible. >> - We start building the Cordova version <=> plugin version mapping like >> that. >> >> Thoughts ? >> >> -a >> >> >> On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: >> >>> makes sense to me; we'll likely want to query on that stuff eventually >>> >>> On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny >>> wrote: Should the universe just keep a copy of a plugin.xml so that it can >> have >>> a list of plugin dependancies and everything? plugin.xml will already >>> have a list of compatible cordova versions, right? Then the universe can manage a reverse mapping if it wants fast access. -Michal On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > A plugin should specify the Cordova versions it supports too. > > On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: >> I am sure we all agree to this. Want to get a sense of how it will >> happen. Anis you mentioned you need Braden to commit the JS stuff >> first? > >>> >>
Re: Moving www into an app folder
Ah yes, I see what you are asking. The point being that phonegap build would need to change to work with the new structure. Its a fair point, and its important generally to not harm downstream distributions on purpose, but I think we generally should do whats best for cordova and give downstream every opportunity to adjust. With this particular proposal I can only image it would not be a problem, especially if they use the same tools internally (but the actual phonegap build team should speak here). -Michal On Fri, Mar 22, 2013 at 10:27 PM, Tommy-Carlos Williams wrote: > I just mean that build expects config.xml to be in www, yeah? > > > > On 23/03/2013, at 1:12 PM, Michal Mocny wrote: > > > But isn't the app incomplete without the merges folder? Most apps > probably > > don't use it, but for those that do, a zip of www isn't enough, you > already > > need to ship more than just the www folder. Creating an app folder would > > actually make the situation easier I think. > > > > project > > - platforms > > - .. > > - plugins > > - ... > > - app(s?) > > - www/ > > - merges/ > > - config.xml > > - README.md > > - docs/ > > - etc stuff that doesn't get copied into platform/ output on build > > > > > > (oh, and hey, notice the similarity in structure to plugins? just > sayin..) > > > > > > > > On Fri, Mar 22, 2013 at 7:00 PM, Tommy-Carlos Williams > > wrote: > > > >> Can I just ask a question about this? > >> > >> Is the config.xml supposed to be compatible with build.phonegap.com at > >> all? > >> > >> I ask because I could see a scenario where you might want to use the cli > >> tools, but still utilise build.phonegap.com for other platforms (or > even > >> for the ones supported by the cli). > >> > >> If the cli config.xml is "build" compatible, it makes sense for it to be > >> in the www folder so that the www folder can go straight to > >> build.phonegap.com. > >> > >> > >> > >> On 23/03/2013, at 9:15 AM, Brian LeRoux wrote: > >> > >>> I'm ok with ./merges at the same level as ./www but the config.xml > >>> inside of ./www bugs me too. I think having a root level ./www just > >>> works well mentally in that its obvious whats there, what it does, and > >>> who it effects. The ./merges folder is really just stuff that gets > >>> added to ./www in the right cases so having at the same depth is ok > >>> (for me). > >>> > >>> I get where you are coming from though. > >>> > >>> The real sticky bit is a config file hiding with the app > >>> implementation. It seems like that would live at the root. The idea of > >>> having it inside of ./www is a simple zip and rename of ./www would > >>> result in an installable package...but logically with our tooling and > >>> such that would be a build artifact that just lives in ./platforms > >>> after we do our magic. > >>> > >>> =/ > >>> > >>> > >>> On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny > >> wrote: > Paraphrasing our meeting notes today: > > * currently www/ has to have config.xml inside it, docs inside it, > >> README > etc > * merges folder is already a sibling of www/ but its logically part of > >> the > app. > * So, why not move everything that isn't the actual assets of the app > itself out of www? > * Option 1: move everything out into the root. > * harder for git versioning your app, since cordova artifacts > (platforms, plugins) are inside. > * Option 2: make a new top level "app/" folder that holds merges/ and > >> www/ > and manifestes etc > * then you can just clone/install an app into one location > > > And I'll throw out a third option: Create an "apps" folder which can > >> have > any number of named apps, like plugins. > > > I think (2) should be totally doable (just change some default paths > in > >> the > tooling) and is a strict improvement (minus the hassle of moving your > >> files > around the first time for app devs). (3) I think is interesting, but > >> is a > bit of a departure. > > -Michal > >> > >> > >
Re: [Android] Plugins to send on the ice flows to die
As long as the alerts for asking for permission (as an example) don't say "index.html would like to use your position" or whatever it is without the PhoneGap/Cordova API over the top… On 23/03/2013, at 9:04 AM, Filip Maj wrote: > +1 geo and websql deprecation > > I would wait on camera until we actually do the api audit > > On 3/22/13 2:54 PM, "Joe Bowser" wrote: > >> Hey >> >> I'm currently looking through the plugins, and I'm thinking more and >> more that Android has at least two plugins that I would like to see no >> longer maintained once we break them off of the main repository. >> >> Geolocation: >> --- >> Our Geolocation doesn't actually give us anything that the browser >> doesn't do. I think that GPS could be done better, and that the spec >> sucks. However our core plugins are supposed to follow the spec, and >> since the browser on Android does this much better, there's no point >> for this plugin to exist. >> >> WebSQL Storage: >> >> Our WebSQL storage is pretty brittle and is just a shim to the raw >> SQLite that Android creates. There's no real exception handling, and >> this could easily crash. I would like to deprecate this and point >> people to a third party plugin if they need their SQLite done. >> >> Camera >> -- >> Also, we need to figure out how we capture things. It'd be good if we >> picked one way to do this over the other. Right now mobile-spec seems >> to use the Camera API, which I don't think is correct. We need to >> write a new test for this, because right now this isn't well tested. >> I'd like to send the old Camera API on the ice flow in favour of >> capture and the native URI handling. >> >> Thoughts on this? >> >> Joe >
Re: Moving www into an app folder
I just mean that build expects config.xml to be in www, yeah? On 23/03/2013, at 1:12 PM, Michal Mocny wrote: > But isn't the app incomplete without the merges folder? Most apps probably > don't use it, but for those that do, a zip of www isn't enough, you already > need to ship more than just the www folder. Creating an app folder would > actually make the situation easier I think. > > project > - platforms > - .. > - plugins > - ... > - app(s?) > - www/ > - merges/ > - config.xml > - README.md > - docs/ > - etc stuff that doesn't get copied into platform/ output on build > > > (oh, and hey, notice the similarity in structure to plugins? just sayin..) > > > > On Fri, Mar 22, 2013 at 7:00 PM, Tommy-Carlos Williams > wrote: > >> Can I just ask a question about this? >> >> Is the config.xml supposed to be compatible with build.phonegap.com at >> all? >> >> I ask because I could see a scenario where you might want to use the cli >> tools, but still utilise build.phonegap.com for other platforms (or even >> for the ones supported by the cli). >> >> If the cli config.xml is "build" compatible, it makes sense for it to be >> in the www folder so that the www folder can go straight to >> build.phonegap.com. >> >> >> >> On 23/03/2013, at 9:15 AM, Brian LeRoux wrote: >> >>> I'm ok with ./merges at the same level as ./www but the config.xml >>> inside of ./www bugs me too. I think having a root level ./www just >>> works well mentally in that its obvious whats there, what it does, and >>> who it effects. The ./merges folder is really just stuff that gets >>> added to ./www in the right cases so having at the same depth is ok >>> (for me). >>> >>> I get where you are coming from though. >>> >>> The real sticky bit is a config file hiding with the app >>> implementation. It seems like that would live at the root. The idea of >>> having it inside of ./www is a simple zip and rename of ./www would >>> result in an installable package...but logically with our tooling and >>> such that would be a build artifact that just lives in ./platforms >>> after we do our magic. >>> >>> =/ >>> >>> >>> On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny >> wrote: Paraphrasing our meeting notes today: * currently www/ has to have config.xml inside it, docs inside it, >> README etc * merges folder is already a sibling of www/ but its logically part of >> the app. * So, why not move everything that isn't the actual assets of the app itself out of www? * Option 1: move everything out into the root. * harder for git versioning your app, since cordova artifacts (platforms, plugins) are inside. * Option 2: make a new top level "app/" folder that holds merges/ and >> www/ and manifestes etc * then you can just clone/install an app into one location And I'll throw out a third option: Create an "apps" folder which can >> have any number of named apps, like plugins. I think (2) should be totally doable (just change some default paths in >> the tooling) and is a strict improvement (minus the hassle of moving your >> files around the first time for app devs). (3) I think is interesting, but >> is a bit of a departure. -Michal >> >>
Re: Capture - specify video quality
Is it possible to do both? A generic map such that you can write a generic
app without platform considerations, but also provide a (less vocally
documented?) way to specify the platform values.
(I only suggest this because complaints about hybrid apps of late are that
they sometimes abstract too much of the underlying platform, I generally do
think sensible simplification is the way to go)
On Fri, Mar 22, 2013 at 8:41 PM, Shazron wrote:
> I would map them.
>
>
> On Fri, Mar 22, 2013 at 2:35 PM, Don Coleman
> wrote:
>
> > I'm looking at adding video quality to CaptureVideoOptions.
> >
> > Android has 2 options, iOS has 5.
> >
> > Should I attempt to map some generic high_quality, medium_quality,
> > low_quality options to platform specific options or just pass in platform
> > specific options?
> >
> > Android:
> > EXTRA_VIDEO_QUALITY
> > 0 low quality
> > 1 high quality (default)
> >
> > iOS:
> > enum {
> >UIImagePickerControllerQualityTypeHigh= 0,
> >UIImagePickerControllerQualityTypeMedium = 1, // default
> value
> >UIImagePickerControllerQualityTypeLow = 2,
> >UIImagePickerControllerQualityType640x480 = 3,
> >UIImagePickerControllerQualityTypeIFrame1280x720 = 4,
> >UIImagePickerControllerQualityTypeIFrame960x540 = 5
> > };
> > typedef NSUInteger UIImagePickerControllerQualityType;
> >
>
Re: [plugman] universe and plugin version support needed
I generally prefer json whenever possible as well, so if its feasible to change I'de give that a +1, but I'm not sure how many plugins out there already use the manifest based structure. As far as creating a second manifest just to register with a universe, this isn't unheard of may have benefits, but its yet another barrier for entry for 3rdparty plugin devs. It would be really awesome if sharing plugins with the world were as simple as providing a git repo+tag+directory. I'm not sure I buy the versioning argument, whatever structure we come up with for version dependancies will have the same likelihood of changing over time no matter which file we put it in. -Michal On Fri, Mar 22, 2013 at 7:53 PM, Anis KADRI wrote: > Yeah the only issue with plugin.xml is that it's XML :-D > > It would be so much easier to have it stored in JSON. We can make plugman > parse the XML from a remote source but I would rather store everything in > JSON. > > Also there can be multiple versions of plugin.xml. I think that is a good > enough reason to store the relevant data about plugins (compatible cordova > versions with a given plugin version, dependencies, etc...) in an > easy-to-read format (JSON). There is a bit of duplication yes but it's for > a good cause and the gain is huge. > > The submission process would be: > - A plugin author submits a new plugin, gives it a version and specifies > which version of cordova it was tested on. > - A new version of Cordova comes out and requires the plugin author to > update their plugin to stay compatible. > - We start building the Cordova version <=> plugin version mapping like > that. > > Thoughts ? > > -a > > > On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: > > > makes sense to me; we'll likely want to query on that stuff eventually > > > > On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny > > wrote: > > > Should the universe just keep a copy of a plugin.xml so that it can > have > > a > > > list of plugin dependancies and everything? plugin.xml will already > > have a > > > list of compatible cordova versions, right? > > > > > > Then the universe can manage a reverse mapping if it wants fast access. > > > > > > -Michal > > > > > > > > > On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > > > > > >> A plugin should specify the Cordova versions it supports too. > > >> > > >> On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: > > >> > I am sure we all agree to this. Want to get a sense of how it will > > >> > happen. Anis you mentioned you need Braden to commit the JS stuff > > >> > first? > > >> > > >
Re: [Android] Plugins to send on the ice flows to die
What spec is that? I would like to research that, I was not aware there was a new one. Thanks! Sent from my BlackBerry Z10 smartphone. From: Shazron Sent: Friday, March 22, 2013 8:43 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: [Android] Plugins to send on the ice flows to die Andrew: Capture API. But that's going away I reckon as well (there is a new spec) On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve wrote: > What's the alternative to Camera? > > > On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj wrote: > > > +1 geo and websql deprecation > > > > I would wait on camera until we actually do the api audit > > > > On 3/22/13 2:54 PM, "Joe Bowser" wrote: > > > > >Hey > > > > > >I'm currently looking through the plugins, and I'm thinking more and > > >more that Android has at least two plugins that I would like to see no > > >longer maintained once we break them off of the main repository. > > > > > >Geolocation: > > >--- > > >Our Geolocation doesn't actually give us anything that the browser > > >doesn't do. I think that GPS could be done better, and that the spec > > >sucks. However our core plugins are supposed to follow the spec, and > > >since the browser on Android does this much better, there's no point > > >for this plugin to exist. > > > > > >WebSQL Storage: > > > > > >Our WebSQL storage is pretty brittle and is just a shim to the raw > > >SQLite that Android creates. There's no real exception handling, and > > >this could easily crash. I would like to deprecate this and point > > >people to a third party plugin if they need their SQLite done. > > > > > >Camera > > >-- > > >Also, we need to figure out how we capture things. It'd be good if we > > >picked one way to do this over the other. Right now mobile-spec seems > > >to use the Camera API, which I don't think is correct. We need to > > >write a new test for this, because right now this isn't well tested. > > >I'd like to send the old Camera API on the ice flow in favour of > > >capture and the native URI handling. > > > > > >Thoughts on this? > > > > > >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: Moving www into an app folder
But isn't the app incomplete without the merges folder? Most apps probably don't use it, but for those that do, a zip of www isn't enough, you already need to ship more than just the www folder. Creating an app folder would actually make the situation easier I think. project - platforms - .. - plugins - ... - app(s?) - www/ - merges/ - config.xml - README.md - docs/ - etc stuff that doesn't get copied into platform/ output on build (oh, and hey, notice the similarity in structure to plugins? just sayin..) On Fri, Mar 22, 2013 at 7:00 PM, Tommy-Carlos Williams wrote: > Can I just ask a question about this? > > Is the config.xml supposed to be compatible with build.phonegap.com at > all? > > I ask because I could see a scenario where you might want to use the cli > tools, but still utilise build.phonegap.com for other platforms (or even > for the ones supported by the cli). > > If the cli config.xml is "build" compatible, it makes sense for it to be > in the www folder so that the www folder can go straight to > build.phonegap.com. > > > > On 23/03/2013, at 9:15 AM, Brian LeRoux wrote: > > > I'm ok with ./merges at the same level as ./www but the config.xml > > inside of ./www bugs me too. I think having a root level ./www just > > works well mentally in that its obvious whats there, what it does, and > > who it effects. The ./merges folder is really just stuff that gets > > added to ./www in the right cases so having at the same depth is ok > > (for me). > > > > I get where you are coming from though. > > > > The real sticky bit is a config file hiding with the app > > implementation. It seems like that would live at the root. The idea of > > having it inside of ./www is a simple zip and rename of ./www would > > result in an installable package...but logically with our tooling and > > such that would be a build artifact that just lives in ./platforms > > after we do our magic. > > > > =/ > > > > > > On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny > wrote: > >> Paraphrasing our meeting notes today: > >> > >> * currently www/ has to have config.xml inside it, docs inside it, > README > >> etc > >> * merges folder is already a sibling of www/ but its logically part of > the > >> app. > >> * So, why not move everything that isn't the actual assets of the app > >> itself out of www? > >> * Option 1: move everything out into the root. > >> * harder for git versioning your app, since cordova artifacts > >> (platforms, plugins) are inside. > >> * Option 2: make a new top level "app/" folder that holds merges/ and > www/ > >> and manifestes etc > >> * then you can just clone/install an app into one location > >> > >> > >> And I'll throw out a third option: Create an "apps" folder which can > have > >> any number of named apps, like plugins. > >> > >> > >> I think (2) should be totally doable (just change some default paths in > the > >> tooling) and is a strict improvement (minus the hassle of moving your > files > >> around the first time for app devs). (3) I think is interesting, but > is a > >> bit of a departure. > >> > >> -Michal > >
Re: [cordova-cli] ripple instead of serve
Dan, my brother showed me this (he is mechatronics student at UW). Is it still on tomorrow? On Fri, Mar 22, 2013 at 6:41 PM, Dan Silivestru wrote: > +1 > > Sorry I'm late to the game, I was judging frisbee throwing, pyramid > climbing robots all day :-) > > https://twitter.com/confusement/status/315162754619162625 > > > On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj wrote: > > > K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry + > > iOS not tagged yet so we can land some more commits in cordova-cli > > > > On 3/22/13 3:02 PM, "Brian LeRoux" wrote: > > > > >Like that plan. Say we proceed and land it in 2.6 to feel out. > > > > > >On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: > > >> I'm fine with removing server. In my mind ripple is just a serve > command > > >> on steroids. At this morning's meeting I believe some of the Googlers > > >> expressed concerns about axing out serve, so perhaps a prudent first > > >>step > > >> would be to add Ripple as an `emulate` command and then we can take > baby > > >> steps to extract out serve over the coming weeks. > > >> > > >> On 3/22/13 2:45 PM, "Gord Tanner" wrote: > > >> > > >>>Ripple is now ready to be integrated, currently I have it added as a > > >>>seperate ripple command in a personal branch [1] > > >>> > > >>>Most of the work on Ripple was a much needed feature we knew we needed > > >>>(Device Selection via query string [2]) as well as adding the ability > to > > >>>serve content from multiple directories [3] (to support www/ merged > with > > >>>platform/www/). > > >>> > > >>>Should I do the full remove serve and add this to emulate or merge > this > > >>>in > > >>>as is? (maybe remove serve in the meantime) > > >>> > > >>>[1] - https://github.com/gtanner/cordova-cli/tree/ripple > > >>>[2] - > > >>> > > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd > > >>>if > > >>>f;h=b36213d426700a3cc62b4701bc75806ff8539528 > > >>>[3] - > > >>> > > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd > > >>>if > > >>>f;h=2e483836bc5a24397ed002556f4209fac9508438 > > >>> > > >>> > > >>>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny > > >>>wrote: > > >>> > > Thats awesome ;) > > > > > > On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner > > wrote: > > > > > Yeah Michal, > > > > > > That is the exact use case I had in mind. When we were a startup > we > > > couldn't afford mac's so just used linux and ripple for all our > > contract > > > work and borrowed a friends macbook when we needed to compile. > > > > > > > > > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny < > mmo...@chromium.org> > > wrote: > > > > > > > Very interesting. Combined with Bradens proposal to support > > pointing > > to > > > a > > > > local platform, looks very good. > > > > > > > > Also note, offline isn't the only reason, platform support on a > > given > > > > machine as well: ie, can "test" iPhone (sorta) on a linux box > > through > > > > Ripple. > > > > > > > > > > > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux > wrote: > > > > > > > > > omg I just realized this would fulfill offline use case vs > lazy > > load > > > > > vendoring > > > > > > > > > > caching could be a future thing > > > > > > > > > > might be a really nice path > > > > > > > > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > > > > > wrote: > > > > > > +1 > > > > > > > > > > > > With this I would want to add the ability to add a platform > > to a > > > > project > > > > > even if we don't have the build dependencies. > > > > > > > > > > > > Emulate would just default to ripple so is still usable if > we > > can't > > > > > build/deploy > > > > > > > > > > > > Sent from my iPhone > > > > > > > > > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > > > > > > > > > >> I think this bleeds back into other discussions. It was > > mentioned > > in > > > > > >> the call earlier. I think some tacit agreement that ./serve > > goes > > > away > > > > > >> and Ripple is the default ./emulate command. But lets > > discuss. > > (Just > > > > > >> this. Lets keep thread focused.) > > > > > > > > > > > > > > > > >> > > > > > > > -- > Dan Silivestru > +1 (519) 589-3624 >
Re: 2.6 platform support and redux
Mostly that they are not super critical / nobody dedicated to them explicitly. I know you keep Mac alive (and well) and Jesse on Win7&8.. If you guys want to continue that sure. On Friday, March 22, 2013, Shazron wrote: > What's the rationale for removing desktop platforms? > > > On Fri, Mar 22, 2013 at 4:33 PM, Anis KADRI > > > wrote: > > > +1 > > > > > > On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes > > > > wrote: > > > > > +1 > > > > > > > > > On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill > > > > > > > > wrote: > > > > > > > +1. I will create issues for coho in regards to this. > > > > > > > > -Steve > > > > > > > > On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj > > > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > On 3/22/13 2:26 PM, "Brian LeRoux" > > wrote: > > > > > > > > > > >Currently a release consists of some boilerplate: > > > > > > > > > > > >DISCLAIMER > > > > > >LICENSE > > > > > >NOTICE > > > > > >README.md > > > > > >changelog > > > > > > > > > > > >And the guts: > > > > > > > > > > > >cordova-android.zip > > > > > >cordova-app-hello-world.zip > > > > > >cordova-bada-wac.zip > > > > > >cordova-bada.zip > > > > > >cordova-blackberry.zip > > > > > >cordova-cli.zip > > > > > >cordova-docs.zip > > > > > >cordova-ios.zip > > > > > >cordova-js.zip > > > > > >cordova-mobile-spec.zip > > > > > >cordova-osx.zip > > > > > >cordova-qt.zip > > > > > >cordova-tizen.zip > > > > > >cordova-webos.zip > > > > > >cordova-windows.zip > > > > > >cordova-wp7.zip > > > > > >cordova-wp8.zip > > > > > > > > > > > >With our recent conversation we discussed changing the guts. > (Which > > > > > >platforms/projects we agree we are tagging and shipping.) > > > > > > > > > > > >I'd like to propose we ship the following for now: > > > > > > > > > > > >cordova-android.zip > > > > > >cordova-app-hello-world.zip > > > > > >cordova-blackberry.zip > > > > > >cordova-cli.zip > > > > > >cordova-docs.zip > > > > > >cordova-ios.zip > > > > > >cordova-js.zip > > > > > >cordova-mobile-spec.zip > > > > > >cordova-wp7.zip > > > > > >cordova-wp8.zip > > > > > > > > > > > >Effectively removing the following from 'a release': > > > > > > > > > > > >cordova-bada-wac.zip > > > > > >cordova-bada.zip > > > > > >cordova-osx.zip > > > > > >cordova-qt.zip > > > > > >cordova-tizen.zip > > > > > >cordova-webos.zip > > > > > >cordova-windows.zip > > > > > > > > > > > >I think this streamlines a release, and makes it easier for > > > > > >downstreams. I recognize there is some drama here removing desktop > > > > > >platforms. Please discuss. > > > > > > > > > > > > > > > > > > > >
Plugin Repos Created!
https://issues.apache.org/jira/browse/INFRA-5839
Re: Platform-level command line scripts ;)
Given that cordova-cli will be the end goal for people typing in commands, I guess I don't really care what the scripts look like as long as they are consistent. So.. I guess I'd be fine to have build-release and build-debug as top-level scripts. Since: It would seem weird to me to have a top-level build command that shells out to build-release vs build-debug. These scripts are identical except for a single flag, so I think they'd be implemented by calling a common helper script. Trying to appease both fewer scripts and lots of script ends us up with a pyramid of scripts! Right now the Android scripts work by: 1. Each linux script has an equivalent window .bat file of the same name 2a. Each .bat forwards to cordova.bat, which forwards to cordova.js 2b. Each unix script forwards to cordova 3. cordova.js and cordova have all of the actual logic. On Fri, Mar 22, 2013 at 7:48 PM, Jeffrey Heifetz wrote: > I like this solution to platform scripts, the only addition I would add is > that if the platform allows multiple targets, perhaps it could be possible > to set a default one that would be used instead of the timeout to first one > (although I suppose that makes first entry inherent default). > > Sent from my BlackBerry 10 smartphone. > From: Benn Mapes > Sent: Friday, March 22, 2013 6:57 PM > To: dev@cordova.apache.org > Reply To: dev@cordova.apache.org > Subject: Re: Platform-level command line scripts ;) > > > +1 > I think that would be a good place for the check_reqs script > > > On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj wrote: > > > One more addition: based on responses from the cordova-cli threads, it > > looks like we'll also add a `check_reqs` script to each platform (perhaps > > under /cordova/lib) > > > > On 3/22/13 3:10 PM, "Michael Wolf" wrote: > > > > >I like this. > > > > > >mw > > > > > >On 3/22/13 6:03 PM, "Brian LeRoux" wrote: > > > > > >>YES. Do it. > > >> > > >>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: > > >>> Hai gaiz! > > >>> > > >>> Main contention between the two "camps" in this debate is four vs > eight > > >>> scripts.. But Brian points out that refactoring smaller bits of > > >>> functionality into their own script allows us to "have our cake and > eat > > >>>it > > >>> too". This, in turn, results in four + (a subset of the 8) = 10 > scripts > > >>>in > > >>> total.. Which is an argument for just starting with smaller more > > >>>discrete > > >>> scripts to begin with, lol. > > >>> > > >>> How about this as a middle ground: > > >>> > > >>> - under /cordova/ we have the four scripts Anis/Andrew recommend: > > >>>clean, > > >>> log, build and run. These call into various scripts under > cordova/lib, > > >>> such as.. > > >>> - under /cordova/lib we have the ~6 scripts I recommended: > build-debug, > > >>> build-release, start-emulator, deploy-device, deploy-emulator, and > > >>> possibly a list-devices one as well. > > >>> > > >>> The final point is nailing what `run` does, step-by-step. > Paraphrasing > > >>> Anis: > > >>> > > >>> If device(s) connected: > > >>> * Pick device (ignore emulators). > > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > > >>>devices > > >>> are connected (ignore emulators). > > >>> > > >>> If device(s) not connected: > > >>> * Emulator if it is running > > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > > >>> emulators are running. > > >>> * Start emulator. If you have multiple ones set up (Android's case), > > >>> prompt, timeout and launch first one (5 to 10 seconds). > > >>> > > >>> Yes/no/discuss. Let's try to get to a consensus :) > > >>> > > >>> > > >>> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > > >>> > > I knew you'd bring that up! We'll talk more tmrw. > > > > On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI > > wrote: > > > Šor you can have functions do discrete actions like so: > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f > > >= > > >bi > > > >n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6 > > >; > > >hb > > >=HEAD > > > > > > Šinstead of creating more inodes. > > > > > > > > > On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > > > > > >> > You could make more scripts as helper scripts, but I still think > > >>that it > > >> > will be confusing if a user types "ls" and sees a large number > of > > >> scripts, > > >> > having to guess what each of them does. > > >> > > >> Put them in a subdir called ./lib and be done w/ it. > > >> > > >> > > >> > I don't think having more scripts will make it more likely that > > >>the > > >> scripts > > >> > will be consistent across platforms. > > >> > > >> Ah, but having smaller responsibilities for a module of code makes > > >>it > > >> more testable in discreet form making it easier to confirm said > > >> suspicions.
Re: 2.6 platform support and redux
What's the rationale for removing desktop platforms? On Fri, Mar 22, 2013 at 4:33 PM, Anis KADRI wrote: > +1 > > > On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes wrote: > > > +1 > > > > > > On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill > > wrote: > > > > > +1. I will create issues for coho in regards to this. > > > > > > -Steve > > > > > > On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote: > > > > > > > +1 > > > > > > > > On 3/22/13 2:26 PM, "Brian LeRoux" wrote: > > > > > > > > >Currently a release consists of some boilerplate: > > > > > > > > > >DISCLAIMER > > > > >LICENSE > > > > >NOTICE > > > > >README.md > > > > >changelog > > > > > > > > > >And the guts: > > > > > > > > > >cordova-android.zip > > > > >cordova-app-hello-world.zip > > > > >cordova-bada-wac.zip > > > > >cordova-bada.zip > > > > >cordova-blackberry.zip > > > > >cordova-cli.zip > > > > >cordova-docs.zip > > > > >cordova-ios.zip > > > > >cordova-js.zip > > > > >cordova-mobile-spec.zip > > > > >cordova-osx.zip > > > > >cordova-qt.zip > > > > >cordova-tizen.zip > > > > >cordova-webos.zip > > > > >cordova-windows.zip > > > > >cordova-wp7.zip > > > > >cordova-wp8.zip > > > > > > > > > >With our recent conversation we discussed changing the guts. (Which > > > > >platforms/projects we agree we are tagging and shipping.) > > > > > > > > > >I'd like to propose we ship the following for now: > > > > > > > > > >cordova-android.zip > > > > >cordova-app-hello-world.zip > > > > >cordova-blackberry.zip > > > > >cordova-cli.zip > > > > >cordova-docs.zip > > > > >cordova-ios.zip > > > > >cordova-js.zip > > > > >cordova-mobile-spec.zip > > > > >cordova-wp7.zip > > > > >cordova-wp8.zip > > > > > > > > > >Effectively removing the following from 'a release': > > > > > > > > > >cordova-bada-wac.zip > > > > >cordova-bada.zip > > > > >cordova-osx.zip > > > > >cordova-qt.zip > > > > >cordova-tizen.zip > > > > >cordova-webos.zip > > > > >cordova-windows.zip > > > > > > > > > >I think this streamlines a release, and makes it easier for > > > > >downstreams. I recognize there is some drama here removing desktop > > > > >platforms. Please discuss. > > > > > > > > > > > > > >
Re: [Android] Plugins to send on the ice flows to die
Andrew: Capture API. But that's going away I reckon as well (there is a new spec) On Fri, Mar 22, 2013 at 5:29 PM, Andrew Grieve wrote: > What's the alternative to Camera? > > > On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj wrote: > > > +1 geo and websql deprecation > > > > I would wait on camera until we actually do the api audit > > > > On 3/22/13 2:54 PM, "Joe Bowser" wrote: > > > > >Hey > > > > > >I'm currently looking through the plugins, and I'm thinking more and > > >more that Android has at least two plugins that I would like to see no > > >longer maintained once we break them off of the main repository. > > > > > >Geolocation: > > >--- > > >Our Geolocation doesn't actually give us anything that the browser > > >doesn't do. I think that GPS could be done better, and that the spec > > >sucks. However our core plugins are supposed to follow the spec, and > > >since the browser on Android does this much better, there's no point > > >for this plugin to exist. > > > > > >WebSQL Storage: > > > > > >Our WebSQL storage is pretty brittle and is just a shim to the raw > > >SQLite that Android creates. There's no real exception handling, and > > >this could easily crash. I would like to deprecate this and point > > >people to a third party plugin if they need their SQLite done. > > > > > >Camera > > >-- > > >Also, we need to figure out how we capture things. It'd be good if we > > >picked one way to do this over the other. Right now mobile-spec seems > > >to use the Camera API, which I don't think is correct. We need to > > >write a new test for this, because right now this isn't well tested. > > >I'd like to send the old Camera API on the ice flow in favour of > > >capture and the native URI handling. > > > > > >Thoughts on this? > > > > > >Joe > > > > >
Re: Capture - specify video quality
I would map them.
On Fri, Mar 22, 2013 at 2:35 PM, Don Coleman wrote:
> I'm looking at adding video quality to CaptureVideoOptions.
>
> Android has 2 options, iOS has 5.
>
> Should I attempt to map some generic high_quality, medium_quality,
> low_quality options to platform specific options or just pass in platform
> specific options?
>
> Android:
> EXTRA_VIDEO_QUALITY
> 0 low quality
> 1 high quality (default)
>
> iOS:
> enum {
>UIImagePickerControllerQualityTypeHigh= 0,
>UIImagePickerControllerQualityTypeMedium = 1, // default value
>UIImagePickerControllerQualityTypeLow = 2,
>UIImagePickerControllerQualityType640x480 = 3,
>UIImagePickerControllerQualityTypeIFrame1280x720 = 4,
>UIImagePickerControllerQualityTypeIFrame960x540 = 5
> };
> typedef NSUInteger UIImagePickerControllerQualityType;
>
Re: [Android] Plugins to send on the ice flows to die
What's the alternative to Camera? On Fri, Mar 22, 2013 at 6:04 PM, Filip Maj wrote: > +1 geo and websql deprecation > > I would wait on camera until we actually do the api audit > > On 3/22/13 2:54 PM, "Joe Bowser" wrote: > > >Hey > > > >I'm currently looking through the plugins, and I'm thinking more and > >more that Android has at least two plugins that I would like to see no > >longer maintained once we break them off of the main repository. > > > >Geolocation: > >--- > >Our Geolocation doesn't actually give us anything that the browser > >doesn't do. I think that GPS could be done better, and that the spec > >sucks. However our core plugins are supposed to follow the spec, and > >since the browser on Android does this much better, there's no point > >for this plugin to exist. > > > >WebSQL Storage: > > > >Our WebSQL storage is pretty brittle and is just a shim to the raw > >SQLite that Android creates. There's no real exception handling, and > >this could easily crash. I would like to deprecate this and point > >people to a third party plugin if they need their SQLite done. > > > >Camera > >-- > >Also, we need to figure out how we capture things. It'd be good if we > >picked one way to do this over the other. Right now mobile-spec seems > >to use the Camera API, which I don't think is correct. We need to > >write a new test for this, because right now this isn't well tested. > >I'd like to send the old Camera API on the ice flow in favour of > >capture and the native URI handling. > > > >Thoughts on this? > > > >Joe > >
Re: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies
Well at least if you're making changes to the BASH ones you're not breaking the cscript ones unless you're changing the whole flow of operations. Also as you mentioned node is a new dependency. On Fri, Mar 22, 2013 at 4:45 PM, Filip Maj wrote: > Well, we *should* be doing this regardless.. I'm super guilty of not doing > it. I really should get that VM installed.. Sigh. > > On 3/22/13 4:42 PM, "Anis KADRI" wrote: > > >Also worth pointing out that as much as node is cross-platforms you will > >have to consider/test both platforms every time you make a modification to > >the scripts. How often do you guys fire up your Windows bootcamp, VM or > >partition to test a tiny change ? How much would you like that ? > > > > > >On Fri, Mar 22, 2013 at 2:40 PM, Tim Kim wrote: > > > >> Let's wait and see for the new BlackBerry repo. I think Jeff mentioned > >>that > >> some scripts were written in node already. > >> > >> > >> On 22 March 2013 12:54, Filip Maj wrote: > >> > >> > Just for clarity's sake, I want to point out that this would add a new > >> > dependency to cordova-android as a standalone project. Worth taking > >>that > >> > into consideration. > >> > > >> > On 3/22/13 11:00 AM, "Anis KADRI" wrote: > >> > > >> > >0 > >> > > > >> > > > >> > >On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote: > >> > > > >> > >> Thoughts? I'm down. But maybe post 3.x since neither is a real > >>issue > >> > >>atm. > >> > >> > >> > > >> > > >> > >> > >> -- > >> Timothy Kim > >> > >
Re: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies
We do have brand new scripts written in node we're struggling to get approval to show off. Sent from my BlackBerry 10 smartphone. From: Filip Maj Sent: Friday, March 22, 2013 7:46 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies Well, we *should* be doing this regardless.. I'm super guilty of not doing it. I really should get that VM installed.. Sigh. On 3/22/13 4:42 PM, "Anis KADRI" wrote: >Also worth pointing out that as much as node is cross-platforms you will >have to consider/test both platforms every time you make a modification to >the scripts. How often do you guys fire up your Windows bootcamp, VM or >partition to test a tiny change ? How much would you like that ? > > >On Fri, Mar 22, 2013 at 2:40 PM, Tim Kim wrote: > >> Let's wait and see for the new BlackBerry repo. I think Jeff mentioned >>that >> some scripts were written in node already. >> >> >> On 22 March 2013 12:54, Filip Maj wrote: >> >> > Just for clarity's sake, I want to point out that this would add a new >> > dependency to cordova-android as a standalone project. Worth taking >>that >> > into consideration. >> > >> > On 3/22/13 11:00 AM, "Anis KADRI" wrote: >> > >> > >0 >> > > >> > > >> > >On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote: >> > > >> > >> Thoughts? I'm down. But maybe post 3.x since neither is a real >>issue >> > >>atm. >> > >> >> > >> > >> >> >> -- >> Timothy Kim >> - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: [plugman] universe and plugin version support needed
Yeah the only issue with plugin.xml is that it's XML :-D It would be so much easier to have it stored in JSON. We can make plugman parse the XML from a remote source but I would rather store everything in JSON. Also there can be multiple versions of plugin.xml. I think that is a good enough reason to store the relevant data about plugins (compatible cordova versions with a given plugin version, dependencies, etc...) in an easy-to-read format (JSON). There is a bit of duplication yes but it's for a good cause and the gain is huge. The submission process would be: - A plugin author submits a new plugin, gives it a version and specifies which version of cordova it was tested on. - A new version of Cordova comes out and requires the plugin author to update their plugin to stay compatible. - We start building the Cordova version <=> plugin version mapping like that. Thoughts ? -a On Fri, Mar 22, 2013 at 2:16 PM, Brian LeRoux wrote: > makes sense to me; we'll likely want to query on that stuff eventually > > On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny > wrote: > > Should the universe just keep a copy of a plugin.xml so that it can have > a > > list of plugin dependancies and everything? plugin.xml will already > have a > > list of compatible cordova versions, right? > > > > Then the universe can manage a reverse mapping if it wants fast access. > > > > -Michal > > > > > > On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > > > >> A plugin should specify the Cordova versions it supports too. > >> > >> On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: > >> > I am sure we all agree to this. Want to get a sense of how it will > >> > happen. Anis you mentioned you need Braden to commit the JS stuff > >> > first? > >> >
Re: Platform-level command line scripts ;)
I like this solution to platform scripts, the only addition I would add is that if the platform allows multiple targets, perhaps it could be possible to set a default one that would be used instead of the timeout to first one (although I suppose that makes first entry inherent default). Sent from my BlackBerry 10 smartphone. From: Benn Mapes Sent: Friday, March 22, 2013 6:57 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Platform-level command line scripts ;) +1 I think that would be a good place for the check_reqs script On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj wrote: > One more addition: based on responses from the cordova-cli threads, it > looks like we'll also add a `check_reqs` script to each platform (perhaps > under /cordova/lib) > > On 3/22/13 3:10 PM, "Michael Wolf" wrote: > > >I like this. > > > >mw > > > >On 3/22/13 6:03 PM, "Brian LeRoux" wrote: > > > >>YES. Do it. > >> > >>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: > >>> Hai gaiz! > >>> > >>> Main contention between the two "camps" in this debate is four vs eight > >>> scripts.. But Brian points out that refactoring smaller bits of > >>> functionality into their own script allows us to "have our cake and eat > >>>it > >>> too". This, in turn, results in four + (a subset of the 8) = 10 scripts > >>>in > >>> total.. Which is an argument for just starting with smaller more > >>>discrete > >>> scripts to begin with, lol. > >>> > >>> How about this as a middle ground: > >>> > >>> - under /cordova/ we have the four scripts Anis/Andrew recommend: > >>>clean, > >>> log, build and run. These call into various scripts under cordova/lib, > >>> such as.. > >>> - under /cordova/lib we have the ~6 scripts I recommended: build-debug, > >>> build-release, start-emulator, deploy-device, deploy-emulator, and > >>> possibly a list-devices one as well. > >>> > >>> The final point is nailing what `run` does, step-by-step. Paraphrasing > >>> Anis: > >>> > >>> If device(s) connected: > >>> * Pick device (ignore emulators). > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > >>>devices > >>> are connected (ignore emulators). > >>> > >>> If device(s) not connected: > >>> * Emulator if it is running > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > >>> emulators are running. > >>> * Start emulator. If you have multiple ones set up (Android's case), > >>> prompt, timeout and launch first one (5 to 10 seconds). > >>> > >>> Yes/no/discuss. Let's try to get to a consensus :) > >>> > >>> > >>> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > >>> > I knew you'd bring that up! We'll talk more tmrw. > > On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI > wrote: > > Šor you can have functions do discrete actions like so: > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f > >= > >bi > >n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6 > >; > >hb > >=HEAD > > > > Šinstead of creating more inodes. > > > > > > On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > > > >> > You could make more scripts as helper scripts, but I still think > >>that it > >> > will be confusing if a user types "ls" and sees a large number of > >> scripts, > >> > having to guess what each of them does. > >> > >> Put them in a subdir called ./lib and be done w/ it. > >> > >> > >> > I don't think having more scripts will make it more likely that > >>the > >> scripts > >> > will be consistent across platforms. > >> > >> Ah, but having smaller responsibilities for a module of code makes > >>it > >> more testable in discreet form making it easier to confirm said > >> suspicions. > >> > >>> > > > > - 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: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies
Well, we *should* be doing this regardless.. I'm super guilty of not doing it. I really should get that VM installed.. Sigh. On 3/22/13 4:42 PM, "Anis KADRI" wrote: >Also worth pointing out that as much as node is cross-platforms you will >have to consider/test both platforms every time you make a modification to >the scripts. How often do you guys fire up your Windows bootcamp, VM or >partition to test a tiny change ? How much would you like that ? > > >On Fri, Mar 22, 2013 at 2:40 PM, Tim Kim wrote: > >> Let's wait and see for the new BlackBerry repo. I think Jeff mentioned >>that >> some scripts were written in node already. >> >> >> On 22 March 2013 12:54, Filip Maj wrote: >> >> > Just for clarity's sake, I want to point out that this would add a new >> > dependency to cordova-android as a standalone project. Worth taking >>that >> > into consideration. >> > >> > On 3/22/13 11:00 AM, "Anis KADRI" wrote: >> > >> > >0 >> > > >> > > >> > >On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote: >> > > >> > >> Thoughts? I'm down. But maybe post 3.x since neither is a real >>issue >> > >>atm. >> > >> >> > >> > >> >> >> -- >> Timothy Kim >>
Re: Platform-level command line scripts ;)
Actually, related to that and an outstanding request for cordova-cli to accept a "--verbose" option: to add that option to all of these proposed scripts. On 3/22/13 3:55 PM, "Tommy-Carlos Williams" wrote: >+1 > >...however, currently the prompt is never shown when using the cli tools as >they are super-mega-secret-silent. > >I only ever know that it wanted me to choose which emulator of the ones I >have available (android avd) when it times out and shows it as part of >the error. > >Something to keep in mind... I know that making the tools less silent is a >whole other issue. > > >On 23/03/2013, at 8:38 AM, Filip Maj wrote: > >> Hai gaiz! >> >> Main contention between the two "camps" in this debate is four vs eight >> scripts.. But Brian points out that refactoring smaller bits of >> functionality into their own script allows us to "have our cake and eat >>it >> too". This, in turn, results in four + (a subset of the 8) = 10 scripts >>in >> total.. Which is an argument for just starting with smaller more >>discrete >> scripts to begin with, lol. >> >> How about this as a middle ground: >> >> - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, >> log, build and run. These call into various scripts under cordova/lib, >> such as.. >> - under /cordova/lib we have the ~6 scripts I recommended: build-debug, >> build-release, start-emulator, deploy-device, deploy-emulator, and >> possibly a list-devices one as well. >> >> The final point is nailing what `run` does, step-by-step. Paraphrasing >> Anis: >> >> If device(s) connected: >> * Pick device (ignore emulators). >> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple >>devices >> are connected (ignore emulators). >> >> If device(s) not connected: >> * Emulator if it is running >> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple >> emulators are running. >> * Start emulator. If you have multiple ones set up (Android's case), >> prompt, timeout and launch first one (5 to 10 seconds). >> >> Yes/no/discuss. Let's try to get to a consensus :) >> >> >> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: >> >>> I knew you'd bring that up! We'll talk more tmrw. >>> >>> On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI >>>wrote: Šor you can have functions do discrete actions like so: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f= bi n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6; hb =HEAD Šinstead of creating more inodes. On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: >> You could make more scripts as helper scripts, but I still think > that it >> will be confusing if a user types "ls" and sees a large number of > scripts, >> having to guess what each of them does. > > Put them in a subdir called ./lib and be done w/ it. > > >> I don't think having more scripts will make it more likely that the > scripts >> will be consistent across platforms. > > Ah, but having smaller responsibilities for a module of code makes it > more testable in discreet form making it easier to confirm said > suspicions. > >> >
Re: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies
Also worth pointing out that as much as node is cross-platforms you will have to consider/test both platforms every time you make a modification to the scripts. How often do you guys fire up your Windows bootcamp, VM or partition to test a tiny change ? How much would you like that ? On Fri, Mar 22, 2013 at 2:40 PM, Tim Kim wrote: > Let's wait and see for the new BlackBerry repo. I think Jeff mentioned that > some scripts were written in node already. > > > On 22 March 2013 12:54, Filip Maj wrote: > > > Just for clarity's sake, I want to point out that this would add a new > > dependency to cordova-android as a standalone project. Worth taking that > > into consideration. > > > > On 3/22/13 11:00 AM, "Anis KADRI" wrote: > > > > >0 > > > > > > > > >On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote: > > > > > >> Thoughts? I'm down. But maybe post 3.x since neither is a real issue > > >>atm. > > >> > > > > > > > -- > Timothy Kim >
Re: 2.6 platform support and redux
+1 On Fri, Mar 22, 2013 at 3:42 PM, Benn Mapes wrote: > +1 > > > On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill > wrote: > > > +1. I will create issues for coho in regards to this. > > > > -Steve > > > > On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote: > > > > > +1 > > > > > > On 3/22/13 2:26 PM, "Brian LeRoux" wrote: > > > > > > >Currently a release consists of some boilerplate: > > > > > > > >DISCLAIMER > > > >LICENSE > > > >NOTICE > > > >README.md > > > >changelog > > > > > > > >And the guts: > > > > > > > >cordova-android.zip > > > >cordova-app-hello-world.zip > > > >cordova-bada-wac.zip > > > >cordova-bada.zip > > > >cordova-blackberry.zip > > > >cordova-cli.zip > > > >cordova-docs.zip > > > >cordova-ios.zip > > > >cordova-js.zip > > > >cordova-mobile-spec.zip > > > >cordova-osx.zip > > > >cordova-qt.zip > > > >cordova-tizen.zip > > > >cordova-webos.zip > > > >cordova-windows.zip > > > >cordova-wp7.zip > > > >cordova-wp8.zip > > > > > > > >With our recent conversation we discussed changing the guts. (Which > > > >platforms/projects we agree we are tagging and shipping.) > > > > > > > >I'd like to propose we ship the following for now: > > > > > > > >cordova-android.zip > > > >cordova-app-hello-world.zip > > > >cordova-blackberry.zip > > > >cordova-cli.zip > > > >cordova-docs.zip > > > >cordova-ios.zip > > > >cordova-js.zip > > > >cordova-mobile-spec.zip > > > >cordova-wp7.zip > > > >cordova-wp8.zip > > > > > > > >Effectively removing the following from 'a release': > > > > > > > >cordova-bada-wac.zip > > > >cordova-bada.zip > > > >cordova-osx.zip > > > >cordova-qt.zip > > > >cordova-tizen.zip > > > >cordova-webos.zip > > > >cordova-windows.zip > > > > > > > >I think this streamlines a release, and makes it easier for > > > >downstreams. I recognize there is some drama here removing desktop > > > >platforms. Please discuss. > > > > > > > > >
Re: Moving www into an app folder
Can I just ask a question about this? Is the config.xml supposed to be compatible with build.phonegap.com at all? I ask because I could see a scenario where you might want to use the cli tools, but still utilise build.phonegap.com for other platforms (or even for the ones supported by the cli). If the cli config.xml is "build" compatible, it makes sense for it to be in the www folder so that the www folder can go straight to build.phonegap.com. On 23/03/2013, at 9:15 AM, Brian LeRoux wrote: > I'm ok with ./merges at the same level as ./www but the config.xml > inside of ./www bugs me too. I think having a root level ./www just > works well mentally in that its obvious whats there, what it does, and > who it effects. The ./merges folder is really just stuff that gets > added to ./www in the right cases so having at the same depth is ok > (for me). > > I get where you are coming from though. > > The real sticky bit is a config file hiding with the app > implementation. It seems like that would live at the root. The idea of > having it inside of ./www is a simple zip and rename of ./www would > result in an installable package...but logically with our tooling and > such that would be a build artifact that just lives in ./platforms > after we do our magic. > > =/ > > > On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny wrote: >> Paraphrasing our meeting notes today: >> >> * currently www/ has to have config.xml inside it, docs inside it, README >> etc >> * merges folder is already a sibling of www/ but its logically part of the >> app. >> * So, why not move everything that isn't the actual assets of the app >> itself out of www? >> * Option 1: move everything out into the root. >> * harder for git versioning your app, since cordova artifacts >> (platforms, plugins) are inside. >> * Option 2: make a new top level "app/" folder that holds merges/ and www/ >> and manifestes etc >> * then you can just clone/install an app into one location >> >> >> And I'll throw out a third option: Create an "apps" folder which can have >> any number of named apps, like plugins. >> >> >> I think (2) should be totally doable (just change some default paths in the >> tooling) and is a strict improvement (minus the hassle of moving your files >> around the first time for app devs). (3) I think is interesting, but is a >> bit of a departure. >> >> -Michal
Re: Platform-level command line scripts ;)
+1 I think that would be a good place for the check_reqs script On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj wrote: > One more addition: based on responses from the cordova-cli threads, it > looks like we'll also add a `check_reqs` script to each platform (perhaps > under /cordova/lib) > > On 3/22/13 3:10 PM, "Michael Wolf" wrote: > > >I like this. > > > >mw > > > >On 3/22/13 6:03 PM, "Brian LeRoux" wrote: > > > >>YES. Do it. > >> > >>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: > >>> Hai gaiz! > >>> > >>> Main contention between the two "camps" in this debate is four vs eight > >>> scripts.. But Brian points out that refactoring smaller bits of > >>> functionality into their own script allows us to "have our cake and eat > >>>it > >>> too". This, in turn, results in four + (a subset of the 8) = 10 scripts > >>>in > >>> total.. Which is an argument for just starting with smaller more > >>>discrete > >>> scripts to begin with, lol. > >>> > >>> How about this as a middle ground: > >>> > >>> - under /cordova/ we have the four scripts Anis/Andrew recommend: > >>>clean, > >>> log, build and run. These call into various scripts under cordova/lib, > >>> such as.. > >>> - under /cordova/lib we have the ~6 scripts I recommended: build-debug, > >>> build-release, start-emulator, deploy-device, deploy-emulator, and > >>> possibly a list-devices one as well. > >>> > >>> The final point is nailing what `run` does, step-by-step. Paraphrasing > >>> Anis: > >>> > >>> If device(s) connected: > >>> * Pick device (ignore emulators). > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > >>>devices > >>> are connected (ignore emulators). > >>> > >>> If device(s) not connected: > >>> * Emulator if it is running > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > >>> emulators are running. > >>> * Start emulator. If you have multiple ones set up (Android's case), > >>> prompt, timeout and launch first one (5 to 10 seconds). > >>> > >>> Yes/no/discuss. Let's try to get to a consensus :) > >>> > >>> > >>> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > >>> > I knew you'd bring that up! We'll talk more tmrw. > > On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI > wrote: > > Šor you can have functions do discrete actions like so: > > > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f > >= > >bi > >n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6 > >; > >hb > >=HEAD > > > > Šinstead of creating more inodes. > > > > > > On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > > > >> > You could make more scripts as helper scripts, but I still think > >>that it > >> > will be confusing if a user types "ls" and sees a large number of > >> scripts, > >> > having to guess what each of them does. > >> > >> Put them in a subdir called ./lib and be done w/ it. > >> > >> > >> > I don't think having more scripts will make it more likely that > >>the > >> scripts > >> > will be consistent across platforms. > >> > >> Ah, but having smaller responsibilities for a module of code makes > >>it > >> more testable in discreet form making it easier to confirm said > >> suspicions. > >> > >>> > > > >
Re: Platform-level command line scripts ;)
+1 …however, currently the prompt is never shown when using the cli tools as they are super-mega-secret-silent. I only ever know that it wanted me to choose which emulator of the ones I have available (android avd) when it times out and shows it as part of the error. Something to keep in mind… I know that making the tools less silent is a whole other issue. On 23/03/2013, at 8:38 AM, Filip Maj wrote: > Hai gaiz! > > Main contention between the two "camps" in this debate is four vs eight > scripts.. But Brian points out that refactoring smaller bits of > functionality into their own script allows us to "have our cake and eat it > too". This, in turn, results in four + (a subset of the 8) = 10 scripts in > total.. Which is an argument for just starting with smaller more discrete > scripts to begin with, lol. > > How about this as a middle ground: > > - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, > log, build and run. These call into various scripts under cordova/lib, > such as.. > - under /cordova/lib we have the ~6 scripts I recommended: build-debug, > build-release, start-emulator, deploy-device, deploy-emulator, and > possibly a list-devices one as well. > > The final point is nailing what `run` does, step-by-step. Paraphrasing > Anis: > > If device(s) connected: > * Pick device (ignore emulators). > * Prompt, timeout and pick first one (5 to 10 seconds) if multiple devices > are connected (ignore emulators). > > If device(s) not connected: > * Emulator if it is running > * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > emulators are running. > * Start emulator. If you have multiple ones set up (Android's case), > prompt, timeout and launch first one (5 to 10 seconds). > > Yes/no/discuss. Let's try to get to a consensus :) > > > On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > >> I knew you'd bring that up! We'll talk more tmrw. >> >> On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote: >>> Šor you can have functions do discrete actions like so: >>> >>> >>> https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bi >>> n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb >>> =HEAD >>> >>> Šinstead of creating more inodes. >>> >>> >>> On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: >>> > You could make more scripts as helper scripts, but I still think that it > will be confusing if a user types "ls" and sees a large number of scripts, > having to guess what each of them does. Put them in a subdir called ./lib and be done w/ it. > I don't think having more scripts will make it more likely that the scripts > will be consistent across platforms. Ah, but having smaller responsibilities for a module of code makes it more testable in discreet form making it easier to confirm said suspicions. >
Re: [cordova-cli] ripple instead of serve
Fyi next branches no longer in use and to be deleted soon.. On 3/22/13 3:52 PM, "Gord Tanner" wrote: >Merged into next [1]. > >I am currently at the pub and a beer or two in so I am not going to code >to >much. If someone wants to axe serve (or refactor it to just use ripple) >that would be awesome. > > >[1] - >https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=ref >s/heads/next > > >On Fri, Mar 22, 2013 at 6:41 PM, Andrew Grieve >wrote: > >> To clarify - I don't mind if serve gets axed for now. >> >> >> On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux wrote: >> >> > Like that plan. Say we proceed and land it in 2.6 to feel out. >> > >> > On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: >> > > I'm fine with removing server. In my mind ripple is just a serve >> command >> > > on steroids. At this morning's meeting I believe some of the >>Googlers >> > > expressed concerns about axing out serve, so perhaps a prudent first >> step >> > > would be to add Ripple as an `emulate` command and then we can take >> baby >> > > steps to extract out serve over the coming weeks. >> > > >> > > On 3/22/13 2:45 PM, "Gord Tanner" wrote: >> > > >> > >>Ripple is now ready to be integrated, currently I have it added as a >> > >>seperate ripple command in a personal branch [1] >> > >> >> > >>Most of the work on Ripple was a much needed feature we knew we >>needed >> > >>(Device Selection via query string [2]) as well as adding the >>ability >> to >> > >>serve content from multiple directories [3] (to support www/ merged >> with >> > >>platform/www/). >> > >> >> > >>Should I do the full remove serve and add this to emulate or merge >>this >> > in >> > >>as is? (maybe remove serve in the meantime) >> > >> >> > >>[1] - https://github.com/gtanner/cordova-cli/tree/ripple >> > >>[2] - >> > >> >> > >> >>https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdi >>f >> > >>f;h=b36213d426700a3cc62b4701bc75806ff8539528 >> > >>[3] - >> > >> >> > >> >>https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdi >>f >> > >>f;h=2e483836bc5a24397ed002556f4209fac9508438 >> > >> >> > >> >> > >>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny >> > wrote: >> > >> >> > >>> Thats awesome ;) >> > >>> >> > >>> >> > >>> On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner >> > wrote: >> > >>> >> > >>> > Yeah Michal, >> > >>> > >> > >>> > That is the exact use case I had in mind. When we were a >>startup >> we >> > >>> > couldn't afford mac's so just used linux and ripple for all our >> > >>>contract >> > >>> > work and borrowed a friends macbook when we needed to compile. >> > >>> > >> > >>> > >> > >>> > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny >>> > >> > >>> wrote: >> > >>> > >> > >>> > > Very interesting. Combined with Bradens proposal to support >> > >>>pointing >> > >>> to >> > >>> > a >> > >>> > > local platform, looks very good. >> > >>> > > >> > >>> > > Also note, offline isn't the only reason, platform support on >>a >> > >>>given >> > >>> > > machine as well: ie, can "test" iPhone (sorta) on a linux box >> > >>>through >> > >>> > > Ripple. >> > >>> > > >> > >>> > > >> > >>> > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux >> wrote: >> > >>> > > >> > >>> > > > omg I just realized this would fulfill offline use case vs >>lazy >> > >>>load >> > >>> > > > vendoring >> > >>> > > > >> > >>> > > > caching could be a future thing >> > >>> > > > >> > >>> > > > might be a really nice path >> > >>> > > > >> > >>> > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner < >> gtan...@gmail.com >> > > >> > >>> > wrote: >> > >>> > > > > +1 >> > >>> > > > > >> > >>> > > > > With this I would want to add the ability to add a >>platform >> to >> > a >> > >>> > > project >> > >>> > > > even if we don't have the build dependencies. >> > >>> > > > > >> > >>> > > > > Emulate would just default to ripple so is still usable >>if we >> > >>>can't >> > >>> > > > build/deploy >> > >>> > > > > >> > >>> > > > > Sent from my iPhone >> > >>> > > > > >> > >>> > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux >>wrote: >> > >>> > > > > >> > >>> > > > >> I think this bleeds back into other discussions. It was >> > >>>mentioned >> > >>> in >> > >>> > > > >> the call earlier. I think some tacit agreement that >>./serve >> > >>>goes >> > >>> > away >> > >>> > > > >> and Ripple is the default ./emulate command. But lets >> discuss. >> > >>> (Just >> > >>> > > > >> this. Lets keep thread focused.) >> > >>> > > > >> > >>> > > >> > >>> > >> > >>> >> > > >> > >>
Re: [cordova-cli] ripple instead of serve
Merged into next [1]. I am currently at the pub and a beer or two in so I am not going to code to much. If someone wants to axe serve (or refactor it to just use ripple) that would be awesome. [1] - https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs/heads/next On Fri, Mar 22, 2013 at 6:41 PM, Andrew Grieve wrote: > To clarify - I don't mind if serve gets axed for now. > > > On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux wrote: > > > Like that plan. Say we proceed and land it in 2.6 to feel out. > > > > On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: > > > I'm fine with removing server. In my mind ripple is just a serve > command > > > on steroids. At this morning's meeting I believe some of the Googlers > > > expressed concerns about axing out serve, so perhaps a prudent first > step > > > would be to add Ripple as an `emulate` command and then we can take > baby > > > steps to extract out serve over the coming weeks. > > > > > > On 3/22/13 2:45 PM, "Gord Tanner" wrote: > > > > > >>Ripple is now ready to be integrated, currently I have it added as a > > >>seperate ripple command in a personal branch [1] > > >> > > >>Most of the work on Ripple was a much needed feature we knew we needed > > >>(Device Selection via query string [2]) as well as adding the ability > to > > >>serve content from multiple directories [3] (to support www/ merged > with > > >>platform/www/). > > >> > > >>Should I do the full remove serve and add this to emulate or merge this > > in > > >>as is? (maybe remove serve in the meantime) > > >> > > >>[1] - https://github.com/gtanner/cordova-cli/tree/ripple > > >>[2] - > > >> > > > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif > > >>f;h=b36213d426700a3cc62b4701bc75806ff8539528 > > >>[3] - > > >> > > > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif > > >>f;h=2e483836bc5a24397ed002556f4209fac9508438 > > >> > > >> > > >>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny > > wrote: > > >> > > >>> Thats awesome ;) > > >>> > > >>> > > >>> On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner > > wrote: > > >>> > > >>> > Yeah Michal, > > >>> > > > >>> > That is the exact use case I had in mind. When we were a startup > we > > >>> > couldn't afford mac's so just used linux and ripple for all our > > >>>contract > > >>> > work and borrowed a friends macbook when we needed to compile. > > >>> > > > >>> > > > >>> > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny > > > >>> wrote: > > >>> > > > >>> > > Very interesting. Combined with Bradens proposal to support > > >>>pointing > > >>> to > > >>> > a > > >>> > > local platform, looks very good. > > >>> > > > > >>> > > Also note, offline isn't the only reason, platform support on a > > >>>given > > >>> > > machine as well: ie, can "test" iPhone (sorta) on a linux box > > >>>through > > >>> > > Ripple. > > >>> > > > > >>> > > > > >>> > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux > wrote: > > >>> > > > > >>> > > > omg I just realized this would fulfill offline use case vs lazy > > >>>load > > >>> > > > vendoring > > >>> > > > > > >>> > > > caching could be a future thing > > >>> > > > > > >>> > > > might be a really nice path > > >>> > > > > > >>> > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner < > gtan...@gmail.com > > > > > >>> > wrote: > > >>> > > > > +1 > > >>> > > > > > > >>> > > > > With this I would want to add the ability to add a platform > to > > a > > >>> > > project > > >>> > > > even if we don't have the build dependencies. > > >>> > > > > > > >>> > > > > Emulate would just default to ripple so is still usable if we > > >>>can't > > >>> > > > build/deploy > > >>> > > > > > > >>> > > > > Sent from my iPhone > > >>> > > > > > > >>> > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > >>> > > > > > > >>> > > > >> I think this bleeds back into other discussions. It was > > >>>mentioned > > >>> in > > >>> > > > >> the call earlier. I think some tacit agreement that ./serve > > >>>goes > > >>> > away > > >>> > > > >> and Ripple is the default ./emulate command. But lets > discuss. > > >>> (Just > > >>> > > > >> this. Lets keep thread focused.) > > >>> > > > > > >>> > > > > >>> > > > >>> > > > > > >
Re: Platform-level command line scripts ;)
One more addition: based on responses from the cordova-cli threads, it looks like we'll also add a `check_reqs` script to each platform (perhaps under /cordova/lib) On 3/22/13 3:10 PM, "Michael Wolf" wrote: >I like this. > >mw > >On 3/22/13 6:03 PM, "Brian LeRoux" wrote: > >>YES. Do it. >> >>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: >>> Hai gaiz! >>> >>> Main contention between the two "camps" in this debate is four vs eight >>> scripts.. But Brian points out that refactoring smaller bits of >>> functionality into their own script allows us to "have our cake and eat >>>it >>> too". This, in turn, results in four + (a subset of the 8) = 10 scripts >>>in >>> total.. Which is an argument for just starting with smaller more >>>discrete >>> scripts to begin with, lol. >>> >>> How about this as a middle ground: >>> >>> - under /cordova/ we have the four scripts Anis/Andrew recommend: >>>clean, >>> log, build and run. These call into various scripts under cordova/lib, >>> such as.. >>> - under /cordova/lib we have the ~6 scripts I recommended: build-debug, >>> build-release, start-emulator, deploy-device, deploy-emulator, and >>> possibly a list-devices one as well. >>> >>> The final point is nailing what `run` does, step-by-step. Paraphrasing >>> Anis: >>> >>> If device(s) connected: >>> * Pick device (ignore emulators). >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple >>>devices >>> are connected (ignore emulators). >>> >>> If device(s) not connected: >>> * Emulator if it is running >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple >>> emulators are running. >>> * Start emulator. If you have multiple ones set up (Android's case), >>> prompt, timeout and launch first one (5 to 10 seconds). >>> >>> Yes/no/discuss. Let's try to get to a consensus :) >>> >>> >>> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: >>> I knew you'd bring that up! We'll talk more tmrw. On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote: > Šor you can have functions do discrete actions like so: > > >https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f >= >bi >n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6 >; >hb >=HEAD > > Šinstead of creating more inodes. > > > On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > >> > You could make more scripts as helper scripts, but I still think >>that it >> > will be confusing if a user types "ls" and sees a large number of >> scripts, >> > having to guess what each of them does. >> >> Put them in a subdir called ./lib and be done w/ it. >> >> >> > I don't think having more scripts will make it more likely that >>the >> scripts >> > will be consistent across platforms. >> >> Ah, but having smaller responsibilities for a module of code makes >>it >> more testable in discreet form making it easier to confirm said >> suspicions. >> >>> >
Re: [cordova-cli] - check_req's should move into the platforms.
+1 for windows On Fri, Mar 22, 2013 at 11:08 AM, Filip Maj wrote: > +1 ! > > On 3/22/13 10:34 AM, "Shazron" wrote: > > >+1 > > > > > >On Fri, Mar 22, 2013 at 10:33 AM, Jeffrey Heifetz > >wrote: > > > >> +1 > >> > >> On 13-03-22 1:32 PM, "Anis KADRI" wrote: > >> > >> >+1 > >> > > >> > > >> >On Fri, Mar 22, 2013 at 10:29 AM, Brian LeRoux wrote: > >> > > >> >> Propose we add ./bin/check_requirements to each platforms in 2.7 > >> >> timeframe so as to remove that logic from the cordova-cli tool. > >> >> > >> > >> > >> - > >> 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.6 platform support and redux
+1 On Fri, Mar 22, 2013 at 3:04 PM, Steven Gill wrote: > +1. I will create issues for coho in regards to this. > > -Steve > > On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote: > > > +1 > > > > On 3/22/13 2:26 PM, "Brian LeRoux" wrote: > > > > >Currently a release consists of some boilerplate: > > > > > >DISCLAIMER > > >LICENSE > > >NOTICE > > >README.md > > >changelog > > > > > >And the guts: > > > > > >cordova-android.zip > > >cordova-app-hello-world.zip > > >cordova-bada-wac.zip > > >cordova-bada.zip > > >cordova-blackberry.zip > > >cordova-cli.zip > > >cordova-docs.zip > > >cordova-ios.zip > > >cordova-js.zip > > >cordova-mobile-spec.zip > > >cordova-osx.zip > > >cordova-qt.zip > > >cordova-tizen.zip > > >cordova-webos.zip > > >cordova-windows.zip > > >cordova-wp7.zip > > >cordova-wp8.zip > > > > > >With our recent conversation we discussed changing the guts. (Which > > >platforms/projects we agree we are tagging and shipping.) > > > > > >I'd like to propose we ship the following for now: > > > > > >cordova-android.zip > > >cordova-app-hello-world.zip > > >cordova-blackberry.zip > > >cordova-cli.zip > > >cordova-docs.zip > > >cordova-ios.zip > > >cordova-js.zip > > >cordova-mobile-spec.zip > > >cordova-wp7.zip > > >cordova-wp8.zip > > > > > >Effectively removing the following from 'a release': > > > > > >cordova-bada-wac.zip > > >cordova-bada.zip > > >cordova-osx.zip > > >cordova-qt.zip > > >cordova-tizen.zip > > >cordova-webos.zip > > >cordova-windows.zip > > > > > >I think this streamlines a release, and makes it easier for > > >downstreams. I recognize there is some drama here removing desktop > > >platforms. Please discuss. > > > > >
Re: [cordova-cli] ripple instead of serve
To clarify - I don't mind if serve gets axed for now. On Fri, Mar 22, 2013 at 6:02 PM, Brian LeRoux wrote: > Like that plan. Say we proceed and land it in 2.6 to feel out. > > On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: > > I'm fine with removing server. In my mind ripple is just a serve command > > on steroids. At this morning's meeting I believe some of the Googlers > > expressed concerns about axing out serve, so perhaps a prudent first step > > would be to add Ripple as an `emulate` command and then we can take baby > > steps to extract out serve over the coming weeks. > > > > On 3/22/13 2:45 PM, "Gord Tanner" wrote: > > > >>Ripple is now ready to be integrated, currently I have it added as a > >>seperate ripple command in a personal branch [1] > >> > >>Most of the work on Ripple was a much needed feature we knew we needed > >>(Device Selection via query string [2]) as well as adding the ability to > >>serve content from multiple directories [3] (to support www/ merged with > >>platform/www/). > >> > >>Should I do the full remove serve and add this to emulate or merge this > in > >>as is? (maybe remove serve in the meantime) > >> > >>[1] - https://github.com/gtanner/cordova-cli/tree/ripple > >>[2] - > >> > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif > >>f;h=b36213d426700a3cc62b4701bc75806ff8539528 > >>[3] - > >> > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif > >>f;h=2e483836bc5a24397ed002556f4209fac9508438 > >> > >> > >>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny > wrote: > >> > >>> Thats awesome ;) > >>> > >>> > >>> On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner > wrote: > >>> > >>> > Yeah Michal, > >>> > > >>> > That is the exact use case I had in mind. When we were a startup we > >>> > couldn't afford mac's so just used linux and ripple for all our > >>>contract > >>> > work and borrowed a friends macbook when we needed to compile. > >>> > > >>> > > >>> > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny > >>> wrote: > >>> > > >>> > > Very interesting. Combined with Bradens proposal to support > >>>pointing > >>> to > >>> > a > >>> > > local platform, looks very good. > >>> > > > >>> > > Also note, offline isn't the only reason, platform support on a > >>>given > >>> > > machine as well: ie, can "test" iPhone (sorta) on a linux box > >>>through > >>> > > Ripple. > >>> > > > >>> > > > >>> > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > >>> > > > >>> > > > omg I just realized this would fulfill offline use case vs lazy > >>>load > >>> > > > vendoring > >>> > > > > >>> > > > caching could be a future thing > >>> > > > > >>> > > > might be a really nice path > >>> > > > > >>> > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > > >>> > wrote: > >>> > > > > +1 > >>> > > > > > >>> > > > > With this I would want to add the ability to add a platform to > a > >>> > > project > >>> > > > even if we don't have the build dependencies. > >>> > > > > > >>> > > > > Emulate would just default to ripple so is still usable if we > >>>can't > >>> > > > build/deploy > >>> > > > > > >>> > > > > Sent from my iPhone > >>> > > > > > >>> > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > >>> > > > > > >>> > > > >> I think this bleeds back into other discussions. It was > >>>mentioned > >>> in > >>> > > > >> the call earlier. I think some tacit agreement that ./serve > >>>goes > >>> > away > >>> > > > >> and Ripple is the default ./emulate command. But lets discuss. > >>> (Just > >>> > > > >> this. Lets keep thread focused.) > >>> > > > > >>> > > > >>> > > >>> > > >
Re: [cordova-cli] ripple instead of serve
+1 Sorry I'm late to the game, I was judging frisbee throwing, pyramid climbing robots all day :-) https://twitter.com/confusement/status/315162754619162625 On Fri, Mar 22, 2013 at 6:35 PM, Filip Maj wrote: > K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry + > iOS not tagged yet so we can land some more commits in cordova-cli > > On 3/22/13 3:02 PM, "Brian LeRoux" wrote: > > >Like that plan. Say we proceed and land it in 2.6 to feel out. > > > >On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: > >> I'm fine with removing server. In my mind ripple is just a serve command > >> on steroids. At this morning's meeting I believe some of the Googlers > >> expressed concerns about axing out serve, so perhaps a prudent first > >>step > >> would be to add Ripple as an `emulate` command and then we can take baby > >> steps to extract out serve over the coming weeks. > >> > >> On 3/22/13 2:45 PM, "Gord Tanner" wrote: > >> > >>>Ripple is now ready to be integrated, currently I have it added as a > >>>seperate ripple command in a personal branch [1] > >>> > >>>Most of the work on Ripple was a much needed feature we knew we needed > >>>(Device Selection via query string [2]) as well as adding the ability to > >>>serve content from multiple directories [3] (to support www/ merged with > >>>platform/www/). > >>> > >>>Should I do the full remove serve and add this to emulate or merge this > >>>in > >>>as is? (maybe remove serve in the meantime) > >>> > >>>[1] - https://github.com/gtanner/cordova-cli/tree/ripple > >>>[2] - > >>> > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd > >>>if > >>>f;h=b36213d426700a3cc62b4701bc75806ff8539528 > >>>[3] - > >>> > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd > >>>if > >>>f;h=2e483836bc5a24397ed002556f4209fac9508438 > >>> > >>> > >>>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny > >>>wrote: > >>> > Thats awesome ;) > > > On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner > wrote: > > > Yeah Michal, > > > > That is the exact use case I had in mind. When we were a startup we > > couldn't afford mac's so just used linux and ripple for all our > contract > > work and borrowed a friends macbook when we needed to compile. > > > > > > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny > wrote: > > > > > Very interesting. Combined with Bradens proposal to support > pointing > to > > a > > > local platform, looks very good. > > > > > > Also note, offline isn't the only reason, platform support on a > given > > > machine as well: ie, can "test" iPhone (sorta) on a linux box > through > > > Ripple. > > > > > > > > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > > > > > > > omg I just realized this would fulfill offline use case vs lazy > load > > > > vendoring > > > > > > > > caching could be a future thing > > > > > > > > might be a really nice path > > > > > > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > > > wrote: > > > > > +1 > > > > > > > > > > With this I would want to add the ability to add a platform > to a > > > project > > > > even if we don't have the build dependencies. > > > > > > > > > > Emulate would just default to ripple so is still usable if we > can't > > > > build/deploy > > > > > > > > > > Sent from my iPhone > > > > > > > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > > > > > > > >> I think this bleeds back into other discussions. It was > mentioned > in > > > > >> the call earlier. I think some tacit agreement that ./serve > goes > > away > > > > >> and Ripple is the default ./emulate command. But lets > discuss. > (Just > > > > >> this. Lets keep thread focused.) > > > > > > > > > > > >> > > -- Dan Silivestru +1 (519) 589-3624
Re: request focus
On Fri, Mar 22, 2013 at 1:01 PM, Andrew Grieve wrote: > Could you call requestFocusFromTouch() on your other component after the > WebView calls it? > I was going to ask the same question. I also got frustrated with methods being protected or private but there are usually ways around it.
Re: [cordova-cli] ripple instead of serve
K lets try to land it in 2.6.0rc1. There is still time Gord! Blackberry + iOS not tagged yet so we can land some more commits in cordova-cli On 3/22/13 3:02 PM, "Brian LeRoux" wrote: >Like that plan. Say we proceed and land it in 2.6 to feel out. > >On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: >> I'm fine with removing server. In my mind ripple is just a serve command >> on steroids. At this morning's meeting I believe some of the Googlers >> expressed concerns about axing out serve, so perhaps a prudent first >>step >> would be to add Ripple as an `emulate` command and then we can take baby >> steps to extract out serve over the coming weeks. >> >> On 3/22/13 2:45 PM, "Gord Tanner" wrote: >> >>>Ripple is now ready to be integrated, currently I have it added as a >>>seperate ripple command in a personal branch [1] >>> >>>Most of the work on Ripple was a much needed feature we knew we needed >>>(Device Selection via query string [2]) as well as adding the ability to >>>serve content from multiple directories [3] (to support www/ merged with >>>platform/www/). >>> >>>Should I do the full remove serve and add this to emulate or merge this >>>in >>>as is? (maybe remove serve in the meantime) >>> >>>[1] - https://github.com/gtanner/cordova-cli/tree/ripple >>>[2] - >>>https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd >>>if >>>f;h=b36213d426700a3cc62b4701bc75806ff8539528 >>>[3] - >>>https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitd >>>if >>>f;h=2e483836bc5a24397ed002556f4209fac9508438 >>> >>> >>>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny >>>wrote: >>> Thats awesome ;) On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote: > Yeah Michal, > > That is the exact use case I had in mind. When we were a startup we > couldn't afford mac's so just used linux and ripple for all our contract > work and borrowed a friends macbook when we needed to compile. > > > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny wrote: > > > Very interesting. Combined with Bradens proposal to support pointing to > a > > local platform, looks very good. > > > > Also note, offline isn't the only reason, platform support on a given > > machine as well: ie, can "test" iPhone (sorta) on a linux box through > > Ripple. > > > > > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > > > > > omg I just realized this would fulfill offline use case vs lazy load > > > vendoring > > > > > > caching could be a future thing > > > > > > might be a really nice path > > > > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > wrote: > > > > +1 > > > > > > > > With this I would want to add the ability to add a platform to a > > project > > > even if we don't have the build dependencies. > > > > > > > > Emulate would just default to ripple so is still usable if we can't > > > build/deploy > > > > > > > > Sent from my iPhone > > > > > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > > > > > >> I think this bleeds back into other discussions. It was mentioned in > > > >> the call earlier. I think some tacit agreement that ./serve goes > away > > > >> and Ripple is the default ./emulate command. But lets discuss. (Just > > > >> this. Lets keep thread focused.) > > > > > > >>
Re: Moving www into an app folder
On merges in the root, in our internal implementation it was under www, however this became problematic to devs understanding. It became far to easy for root level www code to end up in merges. We even named ours _platformOverrides to try and make it pretty explicit, but no one liked the mixing the peanut butter w/ the jelly. Thus the root level designation, which I like. Option 2 doesn't kill me, however it does muddy the water a bit when deving purely in browser that www lives under a top level app, as app is Š dare I say nebulous. The benefit of the current set up is that while it might not be strictly just www, its simple. When some one starts they gravitate to www, and look around and then the readme and config are in context to where they will for the most partŠ. live, which is a good thing. mw On 3/22/13 6:15 PM, "Brian LeRoux" wrote: >I'm ok with ./merges at the same level as ./www but the config.xml >inside of ./www bugs me too. I think having a root level ./www just >works well mentally in that its obvious whats there, what it does, and >who it effects. The ./merges folder is really just stuff that gets >added to ./www in the right cases so having at the same depth is ok >(for me). > >I get where you are coming from though. > >The real sticky bit is a config file hiding with the app >implementation. It seems like that would live at the root. The idea of >having it inside of ./www is a simple zip and rename of ./www would >result in an installable package...but logically with our tooling and >such that would be a build artifact that just lives in ./platforms >after we do our magic. > >=/ > > >On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny wrote: >> Paraphrasing our meeting notes today: >> >> * currently www/ has to have config.xml inside it, docs inside it, >>README >> etc >> * merges folder is already a sibling of www/ but its logically part of >>the >> app. >> * So, why not move everything that isn't the actual assets of the app >> itself out of www? >> * Option 1: move everything out into the root. >>* harder for git versioning your app, since cordova artifacts >> (platforms, plugins) are inside. >> * Option 2: make a new top level "app/" folder that holds merges/ and >>www/ >> and manifestes etc >>* then you can just clone/install an app into one location >> >> >> And I'll throw out a third option: Create an "apps" folder which can >>have >> any number of named apps, like plugins. >> >> >> I think (2) should be totally doable (just change some default paths in >>the >> tooling) and is a strict improvement (minus the hassle of moving your >>files >> around the first time for app devs). (3) I think is interesting, but >>is a >> bit of a departure. >> >> -Michal
Re: Moving www into an app folder
I'm ok with ./merges at the same level as ./www but the config.xml inside of ./www bugs me too. I think having a root level ./www just works well mentally in that its obvious whats there, what it does, and who it effects. The ./merges folder is really just stuff that gets added to ./www in the right cases so having at the same depth is ok (for me). I get where you are coming from though. The real sticky bit is a config file hiding with the app implementation. It seems like that would live at the root. The idea of having it inside of ./www is a simple zip and rename of ./www would result in an installable package...but logically with our tooling and such that would be a build artifact that just lives in ./platforms after we do our magic. =/ On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny wrote: > Paraphrasing our meeting notes today: > > * currently www/ has to have config.xml inside it, docs inside it, README > etc > * merges folder is already a sibling of www/ but its logically part of the > app. > * So, why not move everything that isn't the actual assets of the app > itself out of www? > * Option 1: move everything out into the root. >* harder for git versioning your app, since cordova artifacts > (platforms, plugins) are inside. > * Option 2: make a new top level "app/" folder that holds merges/ and www/ > and manifestes etc >* then you can just clone/install an app into one location > > > And I'll throw out a third option: Create an "apps" folder which can have > any number of named apps, like plugins. > > > I think (2) should be totally doable (just change some default paths in the > tooling) and is a strict improvement (minus the hassle of moving your files > around the first time for app devs). (3) I think is interesting, but is a > bit of a departure. > > -Michal
Re: Platform-level command line scripts ;)
I like this. mw On 3/22/13 6:03 PM, "Brian LeRoux" wrote: >YES. Do it. > >On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: >> Hai gaiz! >> >> Main contention between the two "camps" in this debate is four vs eight >> scripts.. But Brian points out that refactoring smaller bits of >> functionality into their own script allows us to "have our cake and eat >>it >> too". This, in turn, results in four + (a subset of the 8) = 10 scripts >>in >> total.. Which is an argument for just starting with smaller more >>discrete >> scripts to begin with, lol. >> >> How about this as a middle ground: >> >> - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, >> log, build and run. These call into various scripts under cordova/lib, >> such as.. >> - under /cordova/lib we have the ~6 scripts I recommended: build-debug, >> build-release, start-emulator, deploy-device, deploy-emulator, and >> possibly a list-devices one as well. >> >> The final point is nailing what `run` does, step-by-step. Paraphrasing >> Anis: >> >> If device(s) connected: >> * Pick device (ignore emulators). >> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple >>devices >> are connected (ignore emulators). >> >> If device(s) not connected: >> * Emulator if it is running >> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple >> emulators are running. >> * Start emulator. If you have multiple ones set up (Android's case), >> prompt, timeout and launch first one (5 to 10 seconds). >> >> Yes/no/discuss. Let's try to get to a consensus :) >> >> >> On 3/21/13 5:29 PM, "Brian LeRoux" wrote: >> >>>I knew you'd bring that up! We'll talk more tmrw. >>> >>>On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI >>>wrote: Šor you can have functions do discrete actions like so: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f= bi n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6; hb =HEAD Šinstead of creating more inodes. On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > > You could make more scripts as helper scripts, but I still think >that it > > will be confusing if a user types "ls" and sees a large number of > scripts, > > having to guess what each of them does. > > Put them in a subdir called ./lib and be done w/ it. > > > > I don't think having more scripts will make it more likely that the > scripts > > will be consistent across platforms. > > Ah, but having smaller responsibilities for a module of code makes it > more testable in discreet form making it easier to confirm said > suspicions. > >>
Re: Platform-level command line scripts ;)
Sounds good to me, though the prompting with a timeout seems a little weird. If there is multiple I think it would be better just to prompt and wait for a response On Fri, Mar 22, 2013 at 3:03 PM, Brian LeRoux wrote: > YES. Do it. > > On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: > > Hai gaiz! > > > > Main contention between the two "camps" in this debate is four vs eight > > scripts.. But Brian points out that refactoring smaller bits of > > functionality into their own script allows us to "have our cake and eat > it > > too". This, in turn, results in four + (a subset of the 8) = 10 scripts > in > > total.. Which is an argument for just starting with smaller more discrete > > scripts to begin with, lol. > > > > How about this as a middle ground: > > > > - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, > > log, build and run. These call into various scripts under cordova/lib, > > such as.. > > - under /cordova/lib we have the ~6 scripts I recommended: build-debug, > > build-release, start-emulator, deploy-device, deploy-emulator, and > > possibly a list-devices one as well. > > > > The final point is nailing what `run` does, step-by-step. Paraphrasing > > Anis: > > > > If device(s) connected: > > * Pick device (ignore emulators). > > * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > devices > > are connected (ignore emulators). > > > > If device(s) not connected: > > * Emulator if it is running > > * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > > emulators are running. > > * Start emulator. If you have multiple ones set up (Android's case), > > prompt, timeout and launch first one (5 to 10 seconds). > > > > Yes/no/discuss. Let's try to get to a consensus :) > > > > > > On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > > > >>I knew you'd bring that up! We'll talk more tmrw. > >> > >>On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI > wrote: > >>> Šor you can have functions do discrete actions like so: > >>> > >>> > >>> > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bi > > >>>n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb > >>>=HEAD > >>> > >>> Šinstead of creating more inodes. > >>> > >>> > >>> On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: > >>> > > You could make more scripts as helper scripts, but I still think > that it > > will be confusing if a user types "ls" and sees a large number of > scripts, > > having to guess what each of them does. > > Put them in a subdir called ./lib and be done w/ it. > > > > I don't think having more scripts will make it more likely that the > scripts > > will be consistent across platforms. > > Ah, but having smaller responsibilities for a module of code makes it > more testable in discreet form making it easier to confirm said > suspicions. > > > >
Re: [cordova-cli] windows phone 8, firefox os, webos are at a disadvantage
Sweet. Don't forget tests :) On 3/22/13 3:02 PM, "Benn Mapes" wrote: >I have added support for wp7 + wp8 on this branch and made a pull request >to cordova-cli but I think it would be best to hold off merging it >in until we decide what to do with the lib folder (i.e dynamically load >platforms when we call `cordova platform add foo` for the first time). > >https://github.com/bennmapes/cordova-cli/tree/windows > >Just woking on the update_config function in the wp*_parser so that you >can >change the name/id from the config.xml > > >On Fri, Mar 22, 2013 at 10:58 AM, Brian LeRoux wrote: > >> None have support currently in the CLI tools. >> >> - Herm is pursuing platform level scripts so support for FxOS can >>happen. >> - Mapes is doing the same in Windows land. >> >> Both cases we could use some help. If any on this list care about >> those platforms and would like to pitch in this is the thread to >> introduce yourself. >>
Re: [cordova-cli] vendoring the platforms instead of lazy download
Offline happens! I think by default nobody needs ANY of our APIs but the transition to that thinking will be the trick. On Fri, Mar 22, 2013 at 1:07 PM, Michal Mocny wrote: > Hmm, but then the versioning of the core plugins is tied to the version of > your cordova-cli tool at install time? > > I'm not opposed to installing cordova-core plugins by default which can > optionally be used as a fallback when or something, but I'm not sure that > every app you create should by default include those. You are right, this > is worthy of a longer discussion. > > (p.s. who goes offline?) > > -Michal > > > On Fri, Mar 22, 2013 at 4:01 PM, Brian LeRoux wrote: > >> Good question. >> >> My intuition is saying for as long as 3.x is around we preload w/ core >> plugins. We'll do as such w/ the PhoneGap distribution to minimize >> pain. Once ppl are used to the tools they'll be asking for us to >> default to none. >> >> My thoughts where that we'd start that way w/ Cordova but thats open too. >> >> >> On Fri, Mar 22, 2013 at 12:51 PM, Andrew Grieve >> wrote: >> > Yep, my biggest concern is that we are able to use CLI but still work >> > against master. I think braden's ask covers that though. >> > >> > What good is working offline if you have no plugins? Are you suggesting >> > that we also include some set of plugins inside of cordova-cli? >> > >> > >> > >> > >> > On Fri, Mar 22, 2013 at 2:13 PM, Brian LeRoux wrote: >> > >> >> It big. Certainly would be more efficient to lazy load, and cache so >> >> offline works. >> >> >> >> On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner >> wrote: >> >> > There was some issues over download size for our cli, any idea what >> the >> >> size of all the platforms are? >> >> > >> >> > Sent from my iPhone >> >> > >> >> > On 2013-03-22, at 1:42 PM, Braden Shepherdson >> >> wrote: >> >> > >> >> >> I'm content to have the vendoring, it has some advantages as you >> wrote. >> >> >> >> >> >> However, I would also very much like to add a platform that's running >> >> from >> >> >> somewhere on my local disk, as I described in my feature request in >> the >> >> doc. >> >> >> >> >> >> So I propose a flag like cordova platform add android >> >> >> --target=../../cordova-android where that local directory can have >> >> >> whatever locally patched code I want. >> >> >> >> >> >> Braden >> >> >> >> >> >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux wrote: >> >> >> >> >> >>> Right now we put the release of Cordova into the npm package for >> >> >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x === >> >> >>> Cordova/Platform 2.5.latest). >> >> >>> >> >> >>> We did this because: >> >> >>> >> >> >>> - has to work offline >> >> >>> - cannot have a Git dep to do development >> >> >>> - issue tracking locked to the real version of Cordova >> >> >>> >> >> >>> We can solve all these issues. The code to do that isn't really a >> huge >> >> >>> deal. But to add it we gain very little that isn't already achieved >> by >> >> >>> vendoring. I'd like for us to be aware the current can be improved >> but >> >> >>> its low priority compared to, say, ripple and plugin integration. >> >> >>> >> >> >>
Re: [cordova-cli] - what does the plugins folder do?
Agreed +1 On 3/22/13 4:23 PM, "Brian LeRoux" wrote: >Ya love it. =) > >On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj wrote: >> Agree with everything Braden said >> >> On 3/22/13 12:05 PM, "tommy-carlos Williams" wrote: >> >>>+1 for ./platforms becoming a build artifact. >>> >>>That is already how we are attempting to roll in our project using the >>>cli, though its not quite right yet. >>> >>>On 23/03/2013, at 5:26, Braden Shepherdson wrote: >>> We want this to stick around. One of my goals for the CLI is to make the platforms/foo subdirectories completely build artifacts. Native code, web assets, JS code, all get copied on every prepare. That's not currently true for native code, but it is for the rest. Since we're doing that, we need the full content of the plugins to stick around. Is there a problem with keeping this around? Braden On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux wrote: > Cool. So, is this interim or necessary to exist for all of time? > (Would assume you need some sort of staging area but not sure you >need > to keep em around if we can cache the manifest info or something.) > > On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson > wrote: >> I assume you mean the top-level plugins/ folder in the CLI? >> >> That is where plugins are cached when you cordova plugin add them. > Whether >> they're coming from local directories or git or wherever, they get >>copied >> here. Then on a prepare this is where the plugin's assets are copied > from. >> >> Braden >> >> >> On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux wrote: >> >>> ... > >>
Re: [Android] Plugins to send on the ice flows to die
+1 geo and websql deprecation I would wait on camera until we actually do the api audit On 3/22/13 2:54 PM, "Joe Bowser" wrote: >Hey > >I'm currently looking through the plugins, and I'm thinking more and >more that Android has at least two plugins that I would like to see no >longer maintained once we break them off of the main repository. > >Geolocation: >--- >Our Geolocation doesn't actually give us anything that the browser >doesn't do. I think that GPS could be done better, and that the spec >sucks. However our core plugins are supposed to follow the spec, and >since the browser on Android does this much better, there's no point >for this plugin to exist. > >WebSQL Storage: > >Our WebSQL storage is pretty brittle and is just a shim to the raw >SQLite that Android creates. There's no real exception handling, and >this could easily crash. I would like to deprecate this and point >people to a third party plugin if they need their SQLite done. > >Camera >-- >Also, we need to figure out how we capture things. It'd be good if we >picked one way to do this over the other. Right now mobile-spec seems >to use the Camera API, which I don't think is correct. We need to >write a new test for this, because right now this isn't well tested. >I'd like to send the old Camera API on the ice flow in favour of >capture and the native URI handling. > >Thoughts on this? > >Joe
Re: [Android] Plugins to send on the ice flows to die
Given that plugins will be independently versioned once they break off I think it will be a whole new world for where we focus our efforts next year. I suspect most of what you propose will be without contention. On Fri, Mar 22, 2013 at 2:54 PM, Joe Bowser wrote: > Hey > > I'm currently looking through the plugins, and I'm thinking more and > more that Android has at least two plugins that I would like to see no > longer maintained once we break them off of the main repository. > > Geolocation: > --- > Our Geolocation doesn't actually give us anything that the browser > doesn't do. I think that GPS could be done better, and that the spec > sucks. However our core plugins are supposed to follow the spec, and > since the browser on Android does this much better, there's no point > for this plugin to exist. > > WebSQL Storage: > > Our WebSQL storage is pretty brittle and is just a shim to the raw > SQLite that Android creates. There's no real exception handling, and > this could easily crash. I would like to deprecate this and point > people to a third party plugin if they need their SQLite done. > > Camera > -- > Also, we need to figure out how we capture things. It'd be good if we > picked one way to do this over the other. Right now mobile-spec seems > to use the Camera API, which I don't think is correct. We need to > write a new test for this, because right now this isn't well tested. > I'd like to send the old Camera API on the ice flow in favour of > capture and the native URI handling. > > Thoughts on this? > > Joe
Re: 2.6 platform support and redux
+1. I will create issues for coho in regards to this. -Steve On Fri, Mar 22, 2013 at 2:35 PM, Filip Maj wrote: > +1 > > On 3/22/13 2:26 PM, "Brian LeRoux" wrote: > > >Currently a release consists of some boilerplate: > > > >DISCLAIMER > >LICENSE > >NOTICE > >README.md > >changelog > > > >And the guts: > > > >cordova-android.zip > >cordova-app-hello-world.zip > >cordova-bada-wac.zip > >cordova-bada.zip > >cordova-blackberry.zip > >cordova-cli.zip > >cordova-docs.zip > >cordova-ios.zip > >cordova-js.zip > >cordova-mobile-spec.zip > >cordova-osx.zip > >cordova-qt.zip > >cordova-tizen.zip > >cordova-webos.zip > >cordova-windows.zip > >cordova-wp7.zip > >cordova-wp8.zip > > > >With our recent conversation we discussed changing the guts. (Which > >platforms/projects we agree we are tagging and shipping.) > > > >I'd like to propose we ship the following for now: > > > >cordova-android.zip > >cordova-app-hello-world.zip > >cordova-blackberry.zip > >cordova-cli.zip > >cordova-docs.zip > >cordova-ios.zip > >cordova-js.zip > >cordova-mobile-spec.zip > >cordova-wp7.zip > >cordova-wp8.zip > > > >Effectively removing the following from 'a release': > > > >cordova-bada-wac.zip > >cordova-bada.zip > >cordova-osx.zip > >cordova-qt.zip > >cordova-tizen.zip > >cordova-webos.zip > >cordova-windows.zip > > > >I think this streamlines a release, and makes it easier for > >downstreams. I recognize there is some drama here removing desktop > >platforms. Please discuss. > >
Re: Platform-level command line scripts ;)
YES. Do it. On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj wrote: > Hai gaiz! > > Main contention between the two "camps" in this debate is four vs eight > scripts.. But Brian points out that refactoring smaller bits of > functionality into their own script allows us to "have our cake and eat it > too". This, in turn, results in four + (a subset of the 8) = 10 scripts in > total.. Which is an argument for just starting with smaller more discrete > scripts to begin with, lol. > > How about this as a middle ground: > > - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, > log, build and run. These call into various scripts under cordova/lib, > such as.. > - under /cordova/lib we have the ~6 scripts I recommended: build-debug, > build-release, start-emulator, deploy-device, deploy-emulator, and > possibly a list-devices one as well. > > The final point is nailing what `run` does, step-by-step. Paraphrasing > Anis: > > If device(s) connected: > * Pick device (ignore emulators). > * Prompt, timeout and pick first one (5 to 10 seconds) if multiple devices > are connected (ignore emulators). > > If device(s) not connected: > * Emulator if it is running > * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > emulators are running. > * Start emulator. If you have multiple ones set up (Android's case), > prompt, timeout and launch first one (5 to 10 seconds). > > Yes/no/discuss. Let's try to get to a consensus :) > > > On 3/21/13 5:29 PM, "Brian LeRoux" wrote: > >>I knew you'd bring that up! We'll talk more tmrw. >> >>On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote: >>> Šor you can have functions do discrete actions like so: >>> >>> >>>https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bi >>>n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb >>>=HEAD >>> >>> Šinstead of creating more inodes. >>> >>> >>> On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: >>> > You could make more scripts as helper scripts, but I still think that it > will be confusing if a user types "ls" and sees a large number of scripts, > having to guess what each of them does. Put them in a subdir called ./lib and be done w/ it. > I don't think having more scripts will make it more likely that the scripts > will be consistent across platforms. Ah, but having smaller responsibilities for a module of code makes it more testable in discreet form making it easier to confirm said suspicions. >
Re: [cordova-cli] ripple instead of serve
Like that plan. Say we proceed and land it in 2.6 to feel out. On Fri, Mar 22, 2013 at 2:50 PM, Filip Maj wrote: > I'm fine with removing server. In my mind ripple is just a serve command > on steroids. At this morning's meeting I believe some of the Googlers > expressed concerns about axing out serve, so perhaps a prudent first step > would be to add Ripple as an `emulate` command and then we can take baby > steps to extract out serve over the coming weeks. > > On 3/22/13 2:45 PM, "Gord Tanner" wrote: > >>Ripple is now ready to be integrated, currently I have it added as a >>seperate ripple command in a personal branch [1] >> >>Most of the work on Ripple was a much needed feature we knew we needed >>(Device Selection via query string [2]) as well as adding the ability to >>serve content from multiple directories [3] (to support www/ merged with >>platform/www/). >> >>Should I do the full remove serve and add this to emulate or merge this in >>as is? (maybe remove serve in the meantime) >> >>[1] - https://github.com/gtanner/cordova-cli/tree/ripple >>[2] - >>https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif >>f;h=b36213d426700a3cc62b4701bc75806ff8539528 >>[3] - >>https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif >>f;h=2e483836bc5a24397ed002556f4209fac9508438 >> >> >>On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny wrote: >> >>> Thats awesome ;) >>> >>> >>> On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote: >>> >>> > Yeah Michal, >>> > >>> > That is the exact use case I had in mind. When we were a startup we >>> > couldn't afford mac's so just used linux and ripple for all our >>>contract >>> > work and borrowed a friends macbook when we needed to compile. >>> > >>> > >>> > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny >>> wrote: >>> > >>> > > Very interesting. Combined with Bradens proposal to support >>>pointing >>> to >>> > a >>> > > local platform, looks very good. >>> > > >>> > > Also note, offline isn't the only reason, platform support on a >>>given >>> > > machine as well: ie, can "test" iPhone (sorta) on a linux box >>>through >>> > > Ripple. >>> > > >>> > > >>> > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: >>> > > >>> > > > omg I just realized this would fulfill offline use case vs lazy >>>load >>> > > > vendoring >>> > > > >>> > > > caching could be a future thing >>> > > > >>> > > > might be a really nice path >>> > > > >>> > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner >>> > wrote: >>> > > > > +1 >>> > > > > >>> > > > > With this I would want to add the ability to add a platform to a >>> > > project >>> > > > even if we don't have the build dependencies. >>> > > > > >>> > > > > Emulate would just default to ripple so is still usable if we >>>can't >>> > > > build/deploy >>> > > > > >>> > > > > Sent from my iPhone >>> > > > > >>> > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: >>> > > > > >>> > > > >> I think this bleeds back into other discussions. It was >>>mentioned >>> in >>> > > > >> the call earlier. I think some tacit agreement that ./serve >>>goes >>> > away >>> > > > >> and Ripple is the default ./emulate command. But lets discuss. >>> (Just >>> > > > >> this. Lets keep thread focused.) >>> > > > >>> > > >>> > >>> >
Re: [cordova-cli] windows phone 8, firefox os, webos are at a disadvantage
I have added support for wp7 + wp8 on this branch and made a pull request to cordova-cli but I think it would be best to hold off merging it in until we decide what to do with the lib folder (i.e dynamically load platforms when we call `cordova platform add foo` for the first time). https://github.com/bennmapes/cordova-cli/tree/windows Just woking on the update_config function in the wp*_parser so that you can change the name/id from the config.xml On Fri, Mar 22, 2013 at 10:58 AM, Brian LeRoux wrote: > None have support currently in the CLI tools. > > - Herm is pursuing platform level scripts so support for FxOS can happen. > - Mapes is doing the same in Windows land. > > Both cases we could use some help. If any on this list care about > those platforms and would like to pitch in this is the thread to > introduce yourself. >
Re: [cordova-cli] ripple instead of serve
Ripple can do everything serve does right now and if you don't pass enableRipple as a command arg it will just host your content exactly like serve. Should we just route the serve command to ripple? On Fri, Mar 22, 2013 at 5:50 PM, Filip Maj wrote: > I'm fine with removing server. In my mind ripple is just a serve command > on steroids. At this morning's meeting I believe some of the Googlers > expressed concerns about axing out serve, so perhaps a prudent first step > would be to add Ripple as an `emulate` command and then we can take baby > steps to extract out serve over the coming weeks. > > On 3/22/13 2:45 PM, "Gord Tanner" wrote: > > >Ripple is now ready to be integrated, currently I have it added as a > >seperate ripple command in a personal branch [1] > > > >Most of the work on Ripple was a much needed feature we knew we needed > >(Device Selection via query string [2]) as well as adding the ability to > >serve content from multiple directories [3] (to support www/ merged with > >platform/www/). > > > >Should I do the full remove serve and add this to emulate or merge this in > >as is? (maybe remove serve in the meantime) > > > >[1] - https://github.com/gtanner/cordova-cli/tree/ripple > >[2] - > > > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif > >f;h=b36213d426700a3cc62b4701bc75806ff8539528 > >[3] - > > > https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif > >f;h=2e483836bc5a24397ed002556f4209fac9508438 > > > > > >On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny > wrote: > > > >> Thats awesome ;) > >> > >> > >> On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote: > >> > >> > Yeah Michal, > >> > > >> > That is the exact use case I had in mind. When we were a startup we > >> > couldn't afford mac's so just used linux and ripple for all our > >>contract > >> > work and borrowed a friends macbook when we needed to compile. > >> > > >> > > >> > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny > >> wrote: > >> > > >> > > Very interesting. Combined with Bradens proposal to support > >>pointing > >> to > >> > a > >> > > local platform, looks very good. > >> > > > >> > > Also note, offline isn't the only reason, platform support on a > >>given > >> > > machine as well: ie, can "test" iPhone (sorta) on a linux box > >>through > >> > > Ripple. > >> > > > >> > > > >> > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > >> > > > >> > > > omg I just realized this would fulfill offline use case vs lazy > >>load > >> > > > vendoring > >> > > > > >> > > > caching could be a future thing > >> > > > > >> > > > might be a really nice path > >> > > > > >> > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > >> > wrote: > >> > > > > +1 > >> > > > > > >> > > > > With this I would want to add the ability to add a platform to a > >> > > project > >> > > > even if we don't have the build dependencies. > >> > > > > > >> > > > > Emulate would just default to ripple so is still usable if we > >>can't > >> > > > build/deploy > >> > > > > > >> > > > > Sent from my iPhone > >> > > > > > >> > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > >> > > > > > >> > > > >> I think this bleeds back into other discussions. It was > >>mentioned > >> in > >> > > > >> the call earlier. I think some tacit agreement that ./serve > >>goes > >> > away > >> > > > >> and Ripple is the default ./emulate command. But lets discuss. > >> (Just > >> > > > >> this. Lets keep thread focused.) > >> > > > > >> > > > >> > > >> > >
[Android] Plugins to send on the ice flows to die
Hey I'm currently looking through the plugins, and I'm thinking more and more that Android has at least two plugins that I would like to see no longer maintained once we break them off of the main repository. Geolocation: --- Our Geolocation doesn't actually give us anything that the browser doesn't do. I think that GPS could be done better, and that the spec sucks. However our core plugins are supposed to follow the spec, and since the browser on Android does this much better, there's no point for this plugin to exist. WebSQL Storage: Our WebSQL storage is pretty brittle and is just a shim to the raw SQLite that Android creates. There's no real exception handling, and this could easily crash. I would like to deprecate this and point people to a third party plugin if they need their SQLite done. Camera -- Also, we need to figure out how we capture things. It'd be good if we picked one way to do this over the other. Right now mobile-spec seems to use the Camera API, which I don't think is correct. We need to write a new test for this, because right now this isn't well tested. I'd like to send the old Camera API on the ice flow in favour of capture and the native URI handling. Thoughts on this? Joe
Re: [cordova-cli] ripple instead of serve
I'm fine with removing server. In my mind ripple is just a serve command on steroids. At this morning's meeting I believe some of the Googlers expressed concerns about axing out serve, so perhaps a prudent first step would be to add Ripple as an `emulate` command and then we can take baby steps to extract out serve over the coming weeks. On 3/22/13 2:45 PM, "Gord Tanner" wrote: >Ripple is now ready to be integrated, currently I have it added as a >seperate ripple command in a personal branch [1] > >Most of the work on Ripple was a much needed feature we knew we needed >(Device Selection via query string [2]) as well as adding the ability to >serve content from multiple directories [3] (to support www/ merged with >platform/www/). > >Should I do the full remove serve and add this to emulate or merge this in >as is? (maybe remove serve in the meantime) > >[1] - https://github.com/gtanner/cordova-cli/tree/ripple >[2] - >https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif >f;h=b36213d426700a3cc62b4701bc75806ff8539528 >[3] - >https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdif >f;h=2e483836bc5a24397ed002556f4209fac9508438 > > >On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny wrote: > >> Thats awesome ;) >> >> >> On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote: >> >> > Yeah Michal, >> > >> > That is the exact use case I had in mind. When we were a startup we >> > couldn't afford mac's so just used linux and ripple for all our >>contract >> > work and borrowed a friends macbook when we needed to compile. >> > >> > >> > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny >> wrote: >> > >> > > Very interesting. Combined with Bradens proposal to support >>pointing >> to >> > a >> > > local platform, looks very good. >> > > >> > > Also note, offline isn't the only reason, platform support on a >>given >> > > machine as well: ie, can "test" iPhone (sorta) on a linux box >>through >> > > Ripple. >> > > >> > > >> > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: >> > > >> > > > omg I just realized this would fulfill offline use case vs lazy >>load >> > > > vendoring >> > > > >> > > > caching could be a future thing >> > > > >> > > > might be a really nice path >> > > > >> > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner >> > wrote: >> > > > > +1 >> > > > > >> > > > > With this I would want to add the ability to add a platform to a >> > > project >> > > > even if we don't have the build dependencies. >> > > > > >> > > > > Emulate would just default to ripple so is still usable if we >>can't >> > > > build/deploy >> > > > > >> > > > > Sent from my iPhone >> > > > > >> > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: >> > > > > >> > > > >> I think this bleeds back into other discussions. It was >>mentioned >> in >> > > > >> the call earlier. I think some tacit agreement that ./serve >>goes >> > away >> > > > >> and Ripple is the default ./emulate command. But lets discuss. >> (Just >> > > > >> this. Lets keep thread focused.) >> > > > >> > > >> > >>
Re: [cordova-cli] ripple instead of serve
Ripple is now ready to be integrated, currently I have it added as a seperate ripple command in a personal branch [1] Most of the work on Ripple was a much needed feature we knew we needed (Device Selection via query string [2]) as well as adding the ability to serve content from multiple directories [3] (to support www/ merged with platform/www/). Should I do the full remove serve and add this to emulate or merge this in as is? (maybe remove serve in the meantime) [1] - https://github.com/gtanner/cordova-cli/tree/ripple [2] - https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdiff;h=b36213d426700a3cc62b4701bc75806ff8539528 [3] - https://git-wip-us.apache.org/repos/asf?p=incubator-ripple.git;a=commitdiff;h=2e483836bc5a24397ed002556f4209fac9508438 On Fri, Mar 22, 2013 at 3:54 PM, Michal Mocny wrote: > Thats awesome ;) > > > On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote: > > > Yeah Michal, > > > > That is the exact use case I had in mind. When we were a startup we > > couldn't afford mac's so just used linux and ripple for all our contract > > work and borrowed a friends macbook when we needed to compile. > > > > > > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny > wrote: > > > > > Very interesting. Combined with Bradens proposal to support pointing > to > > a > > > local platform, looks very good. > > > > > > Also note, offline isn't the only reason, platform support on a given > > > machine as well: ie, can "test" iPhone (sorta) on a linux box through > > > Ripple. > > > > > > > > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > > > > > > > omg I just realized this would fulfill offline use case vs lazy load > > > > vendoring > > > > > > > > caching could be a future thing > > > > > > > > might be a really nice path > > > > > > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > > wrote: > > > > > +1 > > > > > > > > > > With this I would want to add the ability to add a platform to a > > > project > > > > even if we don't have the build dependencies. > > > > > > > > > > Emulate would just default to ripple so is still usable if we can't > > > > build/deploy > > > > > > > > > > Sent from my iPhone > > > > > > > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > > > > > > > >> I think this bleeds back into other discussions. It was mentioned > in > > > > >> the call earlier. I think some tacit agreement that ./serve goes > > away > > > > >> and Ripple is the default ./emulate command. But lets discuss. > (Just > > > > >> this. Lets keep thread focused.) > > > > > > > > > >
Re: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies
Let's wait and see for the new BlackBerry repo. I think Jeff mentioned that some scripts were written in node already. On 22 March 2013 12:54, Filip Maj wrote: > Just for clarity's sake, I want to point out that this would add a new > dependency to cordova-android as a standalone project. Worth taking that > into consideration. > > On 3/22/13 11:00 AM, "Anis KADRI" wrote: > > >0 > > > > > >On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote: > > > >> Thoughts? I'm down. But maybe post 3.x since neither is a real issue > >>atm. > >> > > -- Timothy Kim
wp8 concurrent alerts can't be dismissed
Jesse, when you resolved this Jira item, I don't see that my pull request ever got merged. Did you provide an alternate implementation, or is this a won't-fix, or something else? I'm confused why the issue is marked resolved. The reason I ask is because I'd like to get this fix into 2.6. Thanks! -- Marcel Kinard Begin forwarded message: > From: "Jesse MacFadyen (JIRA)" > Subject: [jira] [Resolved] (CB-2500) wp8: concurrent alerts can't be dismissed > Date: February 27, 2013 6:43:13 PM EST > To: cmarc...@gmail.com > > > > Jesse MacFadyen resolved CB-2500 as Fixed > wp8: concurrent alerts can't be dismissed > Change By:Jesse MacFadyen (27/Feb/13 23:42) > Resolution: Fixed > Status: Open Resolved > 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: Platform-level command line scripts ;)
Hai gaiz! Main contention between the two "camps" in this debate is four vs eight scripts.. But Brian points out that refactoring smaller bits of functionality into their own script allows us to "have our cake and eat it too". This, in turn, results in four + (a subset of the 8) = 10 scripts in total.. Which is an argument for just starting with smaller more discrete scripts to begin with, lol. How about this as a middle ground: - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, log, build and run. These call into various scripts under cordova/lib, such as.. - under /cordova/lib we have the ~6 scripts I recommended: build-debug, build-release, start-emulator, deploy-device, deploy-emulator, and possibly a list-devices one as well. The final point is nailing what `run` does, step-by-step. Paraphrasing Anis: If device(s) connected: * Pick device (ignore emulators). * Prompt, timeout and pick first one (5 to 10 seconds) if multiple devices are connected (ignore emulators). If device(s) not connected: * Emulator if it is running * Prompt, timeout and pick first one (5 to 10 seconds) if multiple emulators are running. * Start emulator. If you have multiple ones set up (Android's case), prompt, timeout and launch first one (5 to 10 seconds). Yes/no/discuss. Let's try to get to a consensus :) On 3/21/13 5:29 PM, "Brian LeRoux" wrote: >I knew you'd bring that up! We'll talk more tmrw. > >On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI wrote: >> Šor you can have functions do discrete actions like so: >> >> >>https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f=bi >>n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6;hb >>=HEAD >> >> Šinstead of creating more inodes. >> >> >> On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux wrote: >> >>> > You could make more scripts as helper scripts, but I still think >>>that it >>> > will be confusing if a user types "ls" and sees a large number of >>> scripts, >>> > having to guess what each of them does. >>> >>> Put them in a subdir called ./lib and be done w/ it. >>> >>> >>> > I don't think having more scripts will make it more likely that the >>> scripts >>> > will be consistent across platforms. >>> >>> Ah, but having smaller responsibilities for a module of code makes it >>> more testable in discreet form making it easier to confirm said >>> suspicions. >>>
Re: 2.6 platform support and redux
+1 On 3/22/13 2:26 PM, "Brian LeRoux" wrote: >Currently a release consists of some boilerplate: > >DISCLAIMER >LICENSE >NOTICE >README.md >changelog > >And the guts: > >cordova-android.zip >cordova-app-hello-world.zip >cordova-bada-wac.zip >cordova-bada.zip >cordova-blackberry.zip >cordova-cli.zip >cordova-docs.zip >cordova-ios.zip >cordova-js.zip >cordova-mobile-spec.zip >cordova-osx.zip >cordova-qt.zip >cordova-tizen.zip >cordova-webos.zip >cordova-windows.zip >cordova-wp7.zip >cordova-wp8.zip > >With our recent conversation we discussed changing the guts. (Which >platforms/projects we agree we are tagging and shipping.) > >I'd like to propose we ship the following for now: > >cordova-android.zip >cordova-app-hello-world.zip >cordova-blackberry.zip >cordova-cli.zip >cordova-docs.zip >cordova-ios.zip >cordova-js.zip >cordova-mobile-spec.zip >cordova-wp7.zip >cordova-wp8.zip > >Effectively removing the following from 'a release': > >cordova-bada-wac.zip >cordova-bada.zip >cordova-osx.zip >cordova-qt.zip >cordova-tizen.zip >cordova-webos.zip >cordova-windows.zip > >I think this streamlines a release, and makes it easier for >downstreams. I recognize there is some drama here removing desktop >platforms. Please discuss.
Capture - specify video quality
I'm looking at adding video quality to CaptureVideoOptions.
Android has 2 options, iOS has 5.
Should I attempt to map some generic high_quality, medium_quality,
low_quality options to platform specific options or just pass in platform
specific options?
Android:
EXTRA_VIDEO_QUALITY
0 low quality
1 high quality (default)
iOS:
enum {
UIImagePickerControllerQualityTypeHigh= 0,
UIImagePickerControllerQualityTypeMedium = 1, // default value
UIImagePickerControllerQualityTypeLow = 2,
UIImagePickerControllerQualityType640x480 = 3,
UIImagePickerControllerQualityTypeIFrame1280x720 = 4,
UIImagePickerControllerQualityTypeIFrame960x540 = 5
};
typedef NSUInteger UIImagePickerControllerQualityType;
2.6 platform support and redux
Currently a release consists of some boilerplate: DISCLAIMER LICENSE NOTICE README.md changelog And the guts: cordova-android.zip cordova-app-hello-world.zip cordova-bada-wac.zip cordova-bada.zip cordova-blackberry.zip cordova-cli.zip cordova-docs.zip cordova-ios.zip cordova-js.zip cordova-mobile-spec.zip cordova-osx.zip cordova-qt.zip cordova-tizen.zip cordova-webos.zip cordova-windows.zip cordova-wp7.zip cordova-wp8.zip With our recent conversation we discussed changing the guts. (Which platforms/projects we agree we are tagging and shipping.) I'd like to propose we ship the following for now: cordova-android.zip cordova-app-hello-world.zip cordova-blackberry.zip cordova-cli.zip cordova-docs.zip cordova-ios.zip cordova-js.zip cordova-mobile-spec.zip cordova-wp7.zip cordova-wp8.zip Effectively removing the following from 'a release': cordova-bada-wac.zip cordova-bada.zip cordova-osx.zip cordova-qt.zip cordova-tizen.zip cordova-webos.zip cordova-windows.zip I think this streamlines a release, and makes it easier for downstreams. I recognize there is some drama here removing desktop platforms. Please discuss.
Re: [plugman] universe and plugin version support needed
makes sense to me; we'll likely want to query on that stuff eventually On Fri, Mar 22, 2013 at 11:53 AM, Michal Mocny wrote: > Should the universe just keep a copy of a plugin.xml so that it can have a > list of plugin dependancies and everything? plugin.xml will already have a > list of compatible cordova versions, right? > > Then the universe can manage a reverse mapping if it wants fast access. > > -Michal > > > On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > >> A plugin should specify the Cordova versions it supports too. >> >> On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: >> > I am sure we all agree to this. Want to get a sense of how it will >> > happen. Anis you mentioned you need Braden to commit the JS stuff >> > first? >>
Re: cordova-cli and plugman overview march 22nd 9am Pacific
Link to recording: http://my.adobeconnect.com/p5vaenqvrsc/ Let me know if any of you have issues viewing. Cheers, -Steve On Fri, Mar 22, 2013 at 11:43 AM, Michal Mocny wrote: > Here are the meeting notes: > > Meeting Notes > > >1. > >Fil describing the tools >- > > command line tools, readme from github > - > > application assets are platform agnostic > - > > platform, plugin, prepare, compile, build, emulate, serve > - > > www/config.xml description > - > > prepare command: > - > > check_platforms command > - > > aside: perhaps it should be a script called out to each > platform > - > > update_from_config command > - > > platform specific magic, config formats > - > > update_www > - > > copy your app over platform www > - > > destroys the platform’s www each time > - > > update_project > - > > project specific magic > - > > quick note: update_project simply calls update_from_config, > update_www, and update_overrides (and lets each parser add > more magic if it > needs to here). > - > > platform command: > - > > ls, remove obvious > - > > add, calls check_requirements, then massages based on target > platform > - > > libs folder contains cached versions of the platforms at the last > release > - > > Braden dislikes this: feature request: flag like `cordova > platform add android --target=../../cordova-android` so > that I can install > an arbitrary version of the platform code, potentially > with local patches. > - > > compile command: > - > > shell_out_to_debug > - > > emulate command: > - > > shell_out_to_emulate > - > > plugin command: > - > > lots of error checking right now > - > > shells out to plugman to do its thing > - > > most of the error checking will move into plugman > - > > will look more like emulate/compile > - > > serve command: > - > > serves up the platform www content > - > > Possible future update to use Ripple instead > - > > project/module level hooks > - > > merges folder > - > > project parsers > 2. > >Michael Brooks discusses phonegap-cli >- > > https://github.com/mwbrooks/phonegap-cli > - > > uses cordova-cli under the hook, plus a phonegap-build command > - > > phonegap-* commands have cloud backups, if it fails to work locally > - > > Aside: app-harness work. Michael has plans, but little/no dev work, > Shravan may start this soon, will sync up. > 3. > >Anis discusses plugman >- > > Examples of plugin add, remove, updates to config.xml > - > > plugin.xml specifies changes needed to project files, config.xml > - > > lookup by name > 4. > >Tests as plugins >- > > The team approves in general. > - > > Generic test suite, install as many test plugins as you like, it runs > them all. > - > > Some common framework for registering tests and reporting results, > ideally independent of test harness. > - > > Part of the motivation for multiple plugins in one repo, since now > tests and sample apps can live in the same repo. Reduces logistical > pain > for us and others. > 5. > >Apps as plugins >- > > Michal presented the various ideas we had, arguments in both > directions. > - > > No conclusions today, just something to think about. > - > > Considerations: > - > > plugins are getting awesome treatment: > - > > universe > - > > dependencies > - > > versioning > - > > add/remove/upgrade > - > > access to native > - > > multiple plugins in one repo > - > > apps are getting some treatment: > - > > the app manifest has access to platform properties > - > > merges folder > - > > So the observation is, if we merge the two concepts, we could > potentially share the benefits, with some changes to the tools > required > (and certain confusion). > 6. > >www to be moved into a named app folder >- > > currently www/ has to have config.xml inside it, docs inside it, > README etc > - > > merges folder is already a sibl
apps as plugins
Paraphrasing from meeting notes today: * plugins are getting awesome treatment: * universe * dependencies * versioning * add/remove/upgrade * access to native * multiple plugins in one repo * apps are getting some treatment: * the app manifest has access to platform properties * merges folder My observation is, if we merged the two concepts, we could share the benefits, but with some changes to the tools required, and certainty for confusion. I think we've solved a lot of problems in the last few weeks, that will make cordova-cli pretty awesome. As a result it will have enough flexibility that we can accomplish a lot of the above in a variety of ways. For example, I could already ship my app code within a directory of a plugin, and document that you should manually symlink to that app within your workspace. That way I can get app versioning, plugin dependancies, etc, just by way of packaging apps within plugins. -Michal
Moving www into an app folder
Paraphrasing our meeting notes today: * currently www/ has to have config.xml inside it, docs inside it, README etc * merges folder is already a sibling of www/ but its logically part of the app. * So, why not move everything that isn't the actual assets of the app itself out of www? * Option 1: move everything out into the root. * harder for git versioning your app, since cordova artifacts (platforms, plugins) are inside. * Option 2: make a new top level "app/" folder that holds merges/ and www/ and manifestes etc * then you can just clone/install an app into one location And I'll throw out a third option: Create an "apps" folder which can have any number of named apps, like plugins. I think (2) should be totally doable (just change some default paths in the tooling) and is a strict improvement (minus the hassle of moving your files around the first time for app devs). (3) I think is interesting, but is a bit of a departure. -Michal
Re: [cordova-cli] - what does the plugins folder do?
Ya love it. =) On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj wrote: > Agree with everything Braden said > > On 3/22/13 12:05 PM, "tommy-carlos Williams" wrote: > >>+1 for ./platforms becoming a build artifact. >> >>That is already how we are attempting to roll in our project using the >>cli, though its not quite right yet. >> >>On 23/03/2013, at 5:26, Braden Shepherdson wrote: >> >>> We want this to stick around. One of my goals for the CLI is to make the >>> platforms/foo subdirectories completely build artifacts. Native code, >>>web >>> assets, JS code, all get copied on every prepare. That's not currently >>>true >>> for native code, but it is for the rest. >>> >>> Since we're doing that, we need the full content of the plugins to stick >>> around. Is there a problem with keeping this around? >>> >>> Braden >>> >>> >>> On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux wrote: >>> Cool. So, is this interim or necessary to exist for all of time? (Would assume you need some sort of staging area but not sure you need to keep em around if we can cache the manifest info or something.) On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson wrote: > I assume you mean the top-level plugins/ folder in the CLI? > > That is where plugins are cached when you cordova plugin add them. Whether > they're coming from local directories or git or wherever, they get >copied > here. Then on a prepare this is where the plugin's assets are copied from. > > Braden > > > On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux wrote: > >> ... >
Re: [cordova-cli] versioning
As Tommay pointed out, you need to create the cordova project structure in the first place with some manner of tool.. On 3/22/13 11:58 AM, "tommy-carlos Williams" wrote: >I don't have much to add except that I really like this about Grunt. > >However, it would get "interesting" with Cordova since the global is what >creates a project in the first place. I still think it could work and >have the global only responsible for creating dirs and setting up >package.json stuff etc... > >+1 for looking into this. > >On 23/03/2013, at 4:53, Brian LeRoux wrote: > >> Right now the global executable is version locked to a Cordova >> release. If you have a project running 2.5 you are required to have >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to >> downgrade (not really but you would to be safe). >> >> In Grunt .4 the global executable is dumb. It just shells to locally >> installed ./node_module version of Grunt. This enables project level >> versioning of Grunt. Nice feature. We can do the same thing: with the >> caveat that you would then require a package.json and ./node_modules >> folder in our Cordova projects. >> >> Discuss.
Re: [cordova-cli] vendoring the platforms instead of lazy download
Hmm, but then the versioning of the core plugins is tied to the version of your cordova-cli tool at install time? I'm not opposed to installing cordova-core plugins by default which can optionally be used as a fallback when or something, but I'm not sure that every app you create should by default include those. You are right, this is worthy of a longer discussion. (p.s. who goes offline?) -Michal On Fri, Mar 22, 2013 at 4:01 PM, Brian LeRoux wrote: > Good question. > > My intuition is saying for as long as 3.x is around we preload w/ core > plugins. We'll do as such w/ the PhoneGap distribution to minimize > pain. Once ppl are used to the tools they'll be asking for us to > default to none. > > My thoughts where that we'd start that way w/ Cordova but thats open too. > > > On Fri, Mar 22, 2013 at 12:51 PM, Andrew Grieve > wrote: > > Yep, my biggest concern is that we are able to use CLI but still work > > against master. I think braden's ask covers that though. > > > > What good is working offline if you have no plugins? Are you suggesting > > that we also include some set of plugins inside of cordova-cli? > > > > > > > > > > On Fri, Mar 22, 2013 at 2:13 PM, Brian LeRoux wrote: > > > >> It big. Certainly would be more efficient to lazy load, and cache so > >> offline works. > >> > >> On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner > wrote: > >> > There was some issues over download size for our cli, any idea what > the > >> size of all the platforms are? > >> > > >> > Sent from my iPhone > >> > > >> > On 2013-03-22, at 1:42 PM, Braden Shepherdson > >> wrote: > >> > > >> >> I'm content to have the vendoring, it has some advantages as you > wrote. > >> >> > >> >> However, I would also very much like to add a platform that's running > >> from > >> >> somewhere on my local disk, as I described in my feature request in > the > >> doc. > >> >> > >> >> So I propose a flag like cordova platform add android > >> >> --target=../../cordova-android where that local directory can have > >> >> whatever locally patched code I want. > >> >> > >> >> Braden > >> >> > >> >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux wrote: > >> >> > >> >>> Right now we put the release of Cordova into the npm package for > >> >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x === > >> >>> Cordova/Platform 2.5.latest). > >> >>> > >> >>> We did this because: > >> >>> > >> >>> - has to work offline > >> >>> - cannot have a Git dep to do development > >> >>> - issue tracking locked to the real version of Cordova > >> >>> > >> >>> We can solve all these issues. The code to do that isn't really a > huge > >> >>> deal. But to add it we gain very little that isn't already achieved > by > >> >>> vendoring. I'd like for us to be aware the current can be improved > but > >> >>> its low priority compared to, say, ripple and plugin integration. > >> >>> > >> >
Re: [cordova-cli] versioning
Maybe a good first stab at this (and maybe this works already), is to ensure multiple versions of CLI can be installed at the same time. e.g. /usr/loca/cordova-cli/2.4 /usr/loca/cordova-cli/2.5 /usr/loca/cordova-cli/2.6 The global symlink in /usr/local/bin would point to the latest, but your project can just call the relevant one directly. On Fri, Mar 22, 2013 at 2:58 PM, tommy-carlos Williams wrote: > I don't have much to add except that I really like this about Grunt. > > However, it would get "interesting" with Cordova since the global is what > creates a project in the first place. I still think it could work and have > the global only responsible for creating dirs and setting up package.json > stuff etc... > > +1 for looking into this. > > On 23/03/2013, at 4:53, Brian LeRoux wrote: > > > Right now the global executable is version locked to a Cordova > > release. If you have a project running 2.5 you are required to have > > Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to > > downgrade (not really but you would to be safe). > > > > In Grunt .4 the global executable is dumb. It just shells to locally > > installed ./node_module version of Grunt. This enables project level > > versioning of Grunt. Nice feature. We can do the same thing: with the > > caveat that you would then require a package.json and ./node_modules > > folder in our Cordova projects. > > > > Discuss. >
Re: [cordova-cli] - what does the plugins folder do?
Agree with everything Braden said On 3/22/13 12:05 PM, "tommy-carlos Williams" wrote: >+1 for ./platforms becoming a build artifact. > >That is already how we are attempting to roll in our project using the >cli, though its not quite right yet. > >On 23/03/2013, at 5:26, Braden Shepherdson wrote: > >> We want this to stick around. One of my goals for the CLI is to make the >> platforms/foo subdirectories completely build artifacts. Native code, >>web >> assets, JS code, all get copied on every prepare. That's not currently >>true >> for native code, but it is for the rest. >> >> Since we're doing that, we need the full content of the plugins to stick >> around. Is there a problem with keeping this around? >> >> Braden >> >> >> On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux wrote: >> >>> Cool. So, is this interim or necessary to exist for all of time? >>> (Would assume you need some sort of staging area but not sure you need >>> to keep em around if we can cache the manifest info or something.) >>> >>> On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson >>> wrote: I assume you mean the top-level plugins/ folder in the CLI? That is where plugins are cached when you cordova plugin add them. >>> Whether they're coming from local directories or git or wherever, they get copied here. Then on a prepare this is where the plugin's assets are copied >>> from. Braden On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux wrote: > ... >>>
Re: request focus
Yeah, this was a concern for me as well, but I figured I'd wait and see what the pull request looked like to know whether it would be a hard thing to maintain. - Could you call requestFocusFromTouch() on your other component after the WebView calls it? On Fri, Mar 22, 2013 at 2:50 PM, Joe Bowser wrote: > -1 > > I don't want anything public until we have a process to decide on what > we should or should not support. We've been burned in the past by > making certain things public, and then not being able to change those > methods because someone somewhere depends on it for their app. > Architectural flexibility be isn't useful if it removes our > flexibility to change things! This is something that has driven us > nuts in the past, and that's why we by default try to make things > private. > > If it's private and undocumented, we should reserve the right to > change it without having to go through the pain of the deprecation > policy. You're free to maintain your local copy and make it public, > but it's private right now because we may want to change this in the > future, and did not plan for it to be a public api call. > > > > On Fri, Mar 22, 2013 at 11:21 AM, Lorin Beer > wrote: > > I've messed around with programmatic view manipulation in native apps, on > > droid and iOS primarily. There's no reason that I'm aware of that these > > methods need to be private, and making sure that plugins/native code can > > change the view layout is important for overall architecture flexibility. > > It may not be the most common use case, but it's certainly an important > one. > > > > +1 from me > > > > > > On Fri, Mar 22, 2013 at 7:38 AM, Andrew Grieve > wrote: > > > >> Sounds good to me! > >> > >> > >> On Thu, Mar 21, 2013 at 9:09 PM, wrote: > >> > >> > Hi all, > >> > > >> > > >> > > >> > We have an android application mixing native views and a > CordovaWebView. > >> > The problem is the CordovaWebView request the focus when launching the > >> > application even in our case it should not be the view selected by > >> > default. Unfortunately there is no easy way to override this behavior > >> > because inside CordovaWebView constructors a call to a private method > >> > setup is done where the focus is requested by calling > >> > requestFocusFromTouch which is also final. I would like to submit a > pull > >> > request for at least change the visibility of setup to protected in > >> > order to override this behavior. How does it sound? Did I miss > something > >> > about why setup is private? > >> > > >> > > >> > > >> > BR > >> > > >> > > >> > > >> > Denis > >> > > >> > > >> >
Re: [cordova-cli] vendoring the platforms instead of lazy download
Good question. My intuition is saying for as long as 3.x is around we preload w/ core plugins. We'll do as such w/ the PhoneGap distribution to minimize pain. Once ppl are used to the tools they'll be asking for us to default to none. My thoughts where that we'd start that way w/ Cordova but thats open too. On Fri, Mar 22, 2013 at 12:51 PM, Andrew Grieve wrote: > Yep, my biggest concern is that we are able to use CLI but still work > against master. I think braden's ask covers that though. > > What good is working offline if you have no plugins? Are you suggesting > that we also include some set of plugins inside of cordova-cli? > > > > > On Fri, Mar 22, 2013 at 2:13 PM, Brian LeRoux wrote: > >> It big. Certainly would be more efficient to lazy load, and cache so >> offline works. >> >> On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner wrote: >> > There was some issues over download size for our cli, any idea what the >> size of all the platforms are? >> > >> > Sent from my iPhone >> > >> > On 2013-03-22, at 1:42 PM, Braden Shepherdson >> wrote: >> > >> >> I'm content to have the vendoring, it has some advantages as you wrote. >> >> >> >> However, I would also very much like to add a platform that's running >> from >> >> somewhere on my local disk, as I described in my feature request in the >> doc. >> >> >> >> So I propose a flag like cordova platform add android >> >> --target=../../cordova-android where that local directory can have >> >> whatever locally patched code I want. >> >> >> >> Braden >> >> >> >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux wrote: >> >> >> >>> Right now we put the release of Cordova into the npm package for >> >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x === >> >>> Cordova/Platform 2.5.latest). >> >>> >> >>> We did this because: >> >>> >> >>> - has to work offline >> >>> - cannot have a Git dep to do development >> >>> - issue tracking locked to the real version of Cordova >> >>> >> >>> We can solve all these issues. The code to do that isn't really a huge >> >>> deal. But to add it we gain very little that isn't already achieved by >> >>> vendoring. I'd like for us to be aware the current can be improved but >> >>> its low priority compared to, say, ripple and plugin integration. >> >>> >>
Re: tag 2.6.0rc1 soon?
It's under cordova-labs' jira branch. Start at line 151 of jira.js [1]. Increment the num_callbacks var. Check out the flow a little bit to get an idea of what you need to do. Then copy/paste to add the new subtasks. Cathc me on gtalk if you have more qs. [1] https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=blob;f=jira.js ;h=18a76980566e6972203b92ade12bb21f3a9d79a8;hb=refs/heads/jira#l151 On 3/22/13 11:35 AM, "Shazron" wrote: >Hi Fil, >Since cordova-osx is functional now -- how do I add JIRA tasks to the >script (not sure where it is exactly) you used to add subtasks for a >release? I want to add "Update www/ application for OS X" and "Update >JavaScript for OS X" sub-tasks. > > >On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote: > >> Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the >> 2.6.x branches on both those repos are now pushed up. Gogo release mode! >> >> On 3/21/13 9:12 AM, "James Jong" wrote: >> >> >Nice. Thanks Michal. >> > >> >-James Jong >> > >> >On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: >> > >> >> Yes, the intent is to have living branches. We may also cherry-pick >> >> regressions back to more than just the current release. >> >> >> >> >> >> On Thu, Mar 21, 2013 at 11:50 AM, James Jong >> >>wrote: >> >> >> >>> Thanks Braden. Is the intent to have 'living' branches for each >>major >> >>> release (e.g. 2.6, 3.0) which contain tags for release candidates >>and >> >>>minor >> >>> revisions? So going forward we would have 2.6.x , 3.0.x, ... >>branches? >> >>> >> >>> -James Jong >> >>> >> >>> On Mar 21, 2013, at 10:36 AM, Braden Shepherdson >> >> >>> wrote: >> >>> >> I meant to send an email about this last night. Here's the >> (high-level) >> process we'll need to follow for each of the repos. >> >> Step 0: This time only, delete the 'next' branch. We're not using >>them >> anymore, and they'll just add confusion. >> Step 1: Checkout and pull master. >> Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) >> Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) >> Step 4: Push the branch and tag. >> >> NB: The branch is for the minor revision (ie. 2.6.x) not the point >> >>> release >> (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. >>and >> >>> then >> 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, >>just >> adding more tags. >> >> Remember that commits always land in master first. Regression fixes >> >>> should >> be cherry-picked to 2.6.x after being committed to master. >> >> Braden >> >> >> >> >> On Thu, Mar 21, 2013 at 10:17 AM, James Jong >> >>> wrote: >> >> > Is the new release branching process for 2.6 posted somewhere? I >> >didn't >> > see it searching through the emails. >> > >> > -James Jong >> > >> > On Mar 20, 2013, at 1:37 PM, Braden Shepherdson >>> > >> > wrote: >> > >> >> My changes are in. >> >> >> >> >> >> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: >> >> >> >>> Alright sounds like we need to wait on those pull reqs. >> >>> >> >>> Braden, if you get it in time, great, otherwise, not a big deal. >> >>> >> >>> Related: can someone recap the newer release/branching/tagging >> >>> approach >> > we >> >>> talked about at the face-to-face (and let's decide if we want to >> >>>use >> >>> it >> > or >> >>> not)? >> >>> >> >>> On 3/20/13 9:20 AM, "Shazron" wrote: >> >>> >> I'm trying to get CB-52 for FileTransfer upload/download and >>the >> keyboardformaccessorybar re-fix in as well - also seeing if the >> FileTransfer mobile-spec stuff works to test. Was planning on >> pulling >> > in >> the iOS pull requests but may not have time, but it seems >>Andrew >> is >> >>> on >> > it >> already :) >> >> >> On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson >> wrote: >> >> > I'm working on rolling some of the plugin JS loading logic >>into >> > cordova-js. >> > If that makes this release then it will be possible to play >>with >> > plugman >> > without also needing bleeding-edge JS. Note that this logic >> >won't be >> > active >> > if there are no plugins, so it shouldn't be a high-risk >>change to >> > slide >> > in >> > before a release. >> > >> > >> > On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < >> >>> agri...@chromium.org >> >> wrote: >> > >> >> Time's feeling right for a release. >> >> >> >> I'm planning on going through pull requests today. Makes >>sense >> >>to >> >>> get >> > those >> >> all in before starting the release. >> >> >> >> >> >>
Re: [cordova-cli] vendoring the platforms instead of lazy download
If you previously cloned platforms and plugins into some global location, you should be able to create a new HelloWorld app while offline, by using --link (for both platforms and plugins). Does that work? On Fri, Mar 22, 2013 at 3:51 PM, Andrew Grieve wrote: > Yep, my biggest concern is that we are able to use CLI but still work > against master. I think braden's ask covers that though. > > What good is working offline if you have no plugins? Are you suggesting > that we also include some set of plugins inside of cordova-cli? > > > > > On Fri, Mar 22, 2013 at 2:13 PM, Brian LeRoux wrote: > > > It big. Certainly would be more efficient to lazy load, and cache so > > offline works. > > > > On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner wrote: > > > There was some issues over download size for our cli, any idea what the > > size of all the platforms are? > > > > > > Sent from my iPhone > > > > > > On 2013-03-22, at 1:42 PM, Braden Shepherdson > > wrote: > > > > > >> I'm content to have the vendoring, it has some advantages as you > wrote. > > >> > > >> However, I would also very much like to add a platform that's running > > from > > >> somewhere on my local disk, as I described in my feature request in > the > > doc. > > >> > > >> So I propose a flag like cordova platform add android > > >> --target=../../cordova-android where that local directory can have > > >> whatever locally patched code I want. > > >> > > >> Braden > > >> > > >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux wrote: > > >> > > >>> Right now we put the release of Cordova into the npm package for > > >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x === > > >>> Cordova/Platform 2.5.latest). > > >>> > > >>> We did this because: > > >>> > > >>> - has to work offline > > >>> - cannot have a Git dep to do development > > >>> - issue tracking locked to the real version of Cordova > > >>> > > >>> We can solve all these issues. The code to do that isn't really a > huge > > >>> deal. But to add it we gain very little that isn't already achieved > by > > >>> vendoring. I'd like for us to be aware the current can be improved > but > > >>> its low priority compared to, say, ripple and plugin integration. > > >>> > > >
Re: [cordova-cli] - rewrite Blackberry and Android scripts in Node to minimize surface for inconsistencies
Just for clarity's sake, I want to point out that this would add a new dependency to cordova-android as a standalone project. Worth taking that into consideration. On 3/22/13 11:00 AM, "Anis KADRI" wrote: >0 > > >On Fri, Mar 22, 2013 at 10:56 AM, Brian LeRoux wrote: > >> Thoughts? I'm down. But maybe post 3.x since neither is a real issue >>atm. >>
Re: [cordova-cli] ripple instead of serve
Thats awesome ;) On Fri, Mar 22, 2013 at 3:51 PM, Gord Tanner wrote: > Yeah Michal, > > That is the exact use case I had in mind. When we were a startup we > couldn't afford mac's so just used linux and ripple for all our contract > work and borrowed a friends macbook when we needed to compile. > > > On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny wrote: > > > Very interesting. Combined with Bradens proposal to support pointing to > a > > local platform, looks very good. > > > > Also note, offline isn't the only reason, platform support on a given > > machine as well: ie, can "test" iPhone (sorta) on a linux box through > > Ripple. > > > > > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > > > > > omg I just realized this would fulfill offline use case vs lazy load > > > vendoring > > > > > > caching could be a future thing > > > > > > might be a really nice path > > > > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner > wrote: > > > > +1 > > > > > > > > With this I would want to add the ability to add a platform to a > > project > > > even if we don't have the build dependencies. > > > > > > > > Emulate would just default to ripple so is still usable if we can't > > > build/deploy > > > > > > > > Sent from my iPhone > > > > > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > > > > > >> I think this bleeds back into other discussions. It was mentioned in > > > >> the call earlier. I think some tacit agreement that ./serve goes > away > > > >> and Ripple is the default ./emulate command. But lets discuss. (Just > > > >> this. Lets keep thread focused.) > > > > > >
Re: [cordova-cli] vendoring the platforms instead of lazy download
Yep, my biggest concern is that we are able to use CLI but still work against master. I think braden's ask covers that though. What good is working offline if you have no plugins? Are you suggesting that we also include some set of plugins inside of cordova-cli? On Fri, Mar 22, 2013 at 2:13 PM, Brian LeRoux wrote: > It big. Certainly would be more efficient to lazy load, and cache so > offline works. > > On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner wrote: > > There was some issues over download size for our cli, any idea what the > size of all the platforms are? > > > > Sent from my iPhone > > > > On 2013-03-22, at 1:42 PM, Braden Shepherdson > wrote: > > > >> I'm content to have the vendoring, it has some advantages as you wrote. > >> > >> However, I would also very much like to add a platform that's running > from > >> somewhere on my local disk, as I described in my feature request in the > doc. > >> > >> So I propose a flag like cordova platform add android > >> --target=../../cordova-android where that local directory can have > >> whatever locally patched code I want. > >> > >> Braden > >> > >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux wrote: > >> > >>> Right now we put the release of Cordova into the npm package for > >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x === > >>> Cordova/Platform 2.5.latest). > >>> > >>> We did this because: > >>> > >>> - has to work offline > >>> - cannot have a Git dep to do development > >>> - issue tracking locked to the real version of Cordova > >>> > >>> We can solve all these issues. The code to do that isn't really a huge > >>> deal. But to add it we gain very little that isn't already achieved by > >>> vendoring. I'd like for us to be aware the current can be improved but > >>> its low priority compared to, say, ripple and plugin integration. > >>> >
Re: [cordova-cli] ripple instead of serve
Yeah Michal, That is the exact use case I had in mind. When we were a startup we couldn't afford mac's so just used linux and ripple for all our contract work and borrowed a friends macbook when we needed to compile. On Fri, Mar 22, 2013 at 3:12 PM, Michal Mocny wrote: > Very interesting. Combined with Bradens proposal to support pointing to a > local platform, looks very good. > > Also note, offline isn't the only reason, platform support on a given > machine as well: ie, can "test" iPhone (sorta) on a linux box through > Ripple. > > > On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > > > omg I just realized this would fulfill offline use case vs lazy load > > vendoring > > > > caching could be a future thing > > > > might be a really nice path > > > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner wrote: > > > +1 > > > > > > With this I would want to add the ability to add a platform to a > project > > even if we don't have the build dependencies. > > > > > > Emulate would just default to ripple so is still usable if we can't > > build/deploy > > > > > > Sent from my iPhone > > > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > > > >> I think this bleeds back into other discussions. It was mentioned in > > >> the call earlier. I think some tacit agreement that ./serve goes away > > >> and Ripple is the default ./emulate command. But lets discuss. (Just > > >> this. Lets keep thread focused.) > > >
Re: [plugman] logic to support a repo that has more than one plugin
(1) That seems useful (eg. install plugin_foo and plugin_foo_test in one
command). Maybe, by default, omitting the `--name` parameter could install
all plugins found in the specified repo/hash.
(2) I think there's theoretical value in this, but cloning is somewhat
cheap so it's probably not worth the effort, especially with (1)
implemented (as you said).
On Fri, Mar 22, 2013 at 3:20 PM, Michal Mocny wrote:
> Huge +1.
>
> Questions:
> 1. Could we allow installing multiple plugins/subdirectories from within
> the same repo in one step. Support wildcards? (i.e. cordova plugin add
> --repo=git --version=hash --name="*")
> 2. Should we cache git repos so we dont need clone over and over for each
> plugin and app. I think this isn't necessary if you just allow (1) and/or
> make it easy to --link to local folders by default (then you cache
> manually).
>
>
> On Fri, Mar 22, 2013 at 2:28 PM, Braden Shepherdson >wrote:
>
> > This has all of my +1s. Especially if our testing story is a dependent
> > plugin, this is way more convenient than two repos.
> >
> > Braden
> >
> >
> > On Fri, Mar 22, 2013 at 2:19 PM, Brian LeRoux wrote:
> >
> > > I'm into it.
> > >
> > > On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren
> > wrote:
> > > > The main technical ask here is the ability to specify a plugin as {
> git
> > > > repo, commit hash, subdirectory } instead of just { git repo, commit
> > > hash }.
> > > >
> > > > On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux wrote:
> > > >
> > > >> Would have the benefit of enabling a plugin, and plugin-test
> existence
> > > >> in a single repo. Consolidates a lot of tooling. Lets discuss more
> > > >> herein
> > > >>
> > >
> >
>
Re: [plugman] logic to support a repo that has more than one plugin
Huge +1.
Questions:
1. Could we allow installing multiple plugins/subdirectories from within
the same repo in one step. Support wildcards? (i.e. cordova plugin add
--repo=git --version=hash --name="*")
2. Should we cache git repos so we dont need clone over and over for each
plugin and app. I think this isn't necessary if you just allow (1) and/or
make it easy to --link to local folders by default (then you cache
manually).
On Fri, Mar 22, 2013 at 2:28 PM, Braden Shepherdson wrote:
> This has all of my +1s. Especially if our testing story is a dependent
> plugin, this is way more convenient than two repos.
>
> Braden
>
>
> On Fri, Mar 22, 2013 at 2:19 PM, Brian LeRoux wrote:
>
> > I'm into it.
> >
> > On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren
> wrote:
> > > The main technical ask here is the ability to specify a plugin as { git
> > > repo, commit hash, subdirectory } instead of just { git repo, commit
> > hash }.
> > >
> > > On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux wrote:
> > >
> > >> Would have the benefit of enabling a plugin, and plugin-test existence
> > >> in a single repo. Consolidates a lot of tooling. Lets discuss more
> > >> herein
> > >>
> >
>
Re: [cordova-cli] ripple instead of serve
Very interesting. Combined with Bradens proposal to support pointing to a local platform, looks very good. Also note, offline isn't the only reason, platform support on a given machine as well: ie, can "test" iPhone (sorta) on a linux box through Ripple. On Fri, Mar 22, 2013 at 2:15 PM, Brian LeRoux wrote: > omg I just realized this would fulfill offline use case vs lazy load > vendoring > > caching could be a future thing > > might be a really nice path > > On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner wrote: > > +1 > > > > With this I would want to add the ability to add a platform to a project > even if we don't have the build dependencies. > > > > Emulate would just default to ripple so is still usable if we can't > build/deploy > > > > Sent from my iPhone > > > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > > > >> I think this bleeds back into other discussions. It was mentioned in > >> the call earlier. I think some tacit agreement that ./serve goes away > >> and Ripple is the default ./emulate command. But lets discuss. (Just > >> this. Lets keep thread focused.) >
Re: [cordova-cli] - what does the plugins folder do?
+1 for ./platforms becoming a build artifact. That is already how we are attempting to roll in our project using the cli, though its not quite right yet. On 23/03/2013, at 5:26, Braden Shepherdson wrote: > We want this to stick around. One of my goals for the CLI is to make the > platforms/foo subdirectories completely build artifacts. Native code, web > assets, JS code, all get copied on every prepare. That's not currently true > for native code, but it is for the rest. > > Since we're doing that, we need the full content of the plugins to stick > around. Is there a problem with keeping this around? > > Braden > > > On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux wrote: > >> Cool. So, is this interim or necessary to exist for all of time? >> (Would assume you need some sort of staging area but not sure you need >> to keep em around if we can cache the manifest info or something.) >> >> On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson >> wrote: >>> I assume you mean the top-level plugins/ folder in the CLI? >>> >>> That is where plugins are cached when you cordova plugin add them. >> Whether >>> they're coming from local directories or git or wherever, they get copied >>> here. Then on a prepare this is where the plugin's assets are copied >> from. >>> >>> Braden >>> >>> >>> On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux wrote: >>> ... >>
Re: [cordova-cli] versioning
I don't have much to add except that I really like this about Grunt. However, it would get "interesting" with Cordova since the global is what creates a project in the first place. I still think it could work and have the global only responsible for creating dirs and setting up package.json stuff etc... +1 for looking into this. On 23/03/2013, at 4:53, Brian LeRoux wrote: > Right now the global executable is version locked to a Cordova > release. If you have a project running 2.5 you are required to have > Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to > downgrade (not really but you would to be safe). > > In Grunt .4 the global executable is dumb. It just shells to locally > installed ./node_module version of Grunt. This enables project level > versioning of Grunt. Nice feature. We can do the same thing: with the > caveat that you would then require a package.json and ./node_modules > folder in our Cordova projects. > > Discuss.
Re: [plugman] universe and plugin version support needed
Should the universe just keep a copy of a plugin.xml so that it can have a list of plugin dependancies and everything? plugin.xml will already have a list of compatible cordova versions, right? Then the universe can manage a reverse mapping if it wants fast access. -Michal On Fri, Mar 22, 2013 at 2:00 PM, Brian LeRoux wrote: > A plugin should specify the Cordova versions it supports too. > > On Fri, Mar 22, 2013 at 10:59 AM, Brian LeRoux wrote: > > I am sure we all agree to this. Want to get a sense of how it will > > happen. Anis you mentioned you need Braden to commit the JS stuff > > first? >
Re: request focus
-1 I don't want anything public until we have a process to decide on what we should or should not support. We've been burned in the past by making certain things public, and then not being able to change those methods because someone somewhere depends on it for their app. Architectural flexibility be isn't useful if it removes our flexibility to change things! This is something that has driven us nuts in the past, and that's why we by default try to make things private. If it's private and undocumented, we should reserve the right to change it without having to go through the pain of the deprecation policy. You're free to maintain your local copy and make it public, but it's private right now because we may want to change this in the future, and did not plan for it to be a public api call. On Fri, Mar 22, 2013 at 11:21 AM, Lorin Beer wrote: > I've messed around with programmatic view manipulation in native apps, on > droid and iOS primarily. There's no reason that I'm aware of that these > methods need to be private, and making sure that plugins/native code can > change the view layout is important for overall architecture flexibility. > It may not be the most common use case, but it's certainly an important one. > > +1 from me > > > On Fri, Mar 22, 2013 at 7:38 AM, Andrew Grieve wrote: > >> Sounds good to me! >> >> >> On Thu, Mar 21, 2013 at 9:09 PM, wrote: >> >> > Hi all, >> > >> > >> > >> > We have an android application mixing native views and a CordovaWebView. >> > The problem is the CordovaWebView request the focus when launching the >> > application even in our case it should not be the view selected by >> > default. Unfortunately there is no easy way to override this behavior >> > because inside CordovaWebView constructors a call to a private method >> > setup is done where the focus is requested by calling >> > requestFocusFromTouch which is also final. I would like to submit a pull >> > request for at least change the visibility of setup to protected in >> > order to override this behavior. How does it sound? Did I miss something >> > about why setup is private? >> > >> > >> > >> > BR >> > >> > >> > >> > Denis >> > >> > >>
Re: cordova-cli and plugman overview march 22nd 9am Pacific
Here are the meeting notes: Meeting Notes 1. Fil describing the tools - command line tools, readme from github - application assets are platform agnostic - platform, plugin, prepare, compile, build, emulate, serve - www/config.xml description - prepare command: - check_platforms command - aside: perhaps it should be a script called out to each platform - update_from_config command - platform specific magic, config formats - update_www - copy your app over platform www - destroys the platform’s www each time - update_project - project specific magic - quick note: update_project simply calls update_from_config, update_www, and update_overrides (and lets each parser add more magic if it needs to here). - platform command: - ls, remove obvious - add, calls check_requirements, then massages based on target platform - libs folder contains cached versions of the platforms at the last release - Braden dislikes this: feature request: flag like `cordova platform add android --target=../../cordova-android` so that I can install an arbitrary version of the platform code, potentially with local patches. - compile command: - shell_out_to_debug - emulate command: - shell_out_to_emulate - plugin command: - lots of error checking right now - shells out to plugman to do its thing - most of the error checking will move into plugman - will look more like emulate/compile - serve command: - serves up the platform www content - Possible future update to use Ripple instead - project/module level hooks - merges folder - project parsers 2. Michael Brooks discusses phonegap-cli - https://github.com/mwbrooks/phonegap-cli - uses cordova-cli under the hook, plus a phonegap-build command - phonegap-* commands have cloud backups, if it fails to work locally - Aside: app-harness work. Michael has plans, but little/no dev work, Shravan may start this soon, will sync up. 3. Anis discusses plugman - Examples of plugin add, remove, updates to config.xml - plugin.xml specifies changes needed to project files, config.xml - lookup by name 4. Tests as plugins - The team approves in general. - Generic test suite, install as many test plugins as you like, it runs them all. - Some common framework for registering tests and reporting results, ideally independent of test harness. - Part of the motivation for multiple plugins in one repo, since now tests and sample apps can live in the same repo. Reduces logistical pain for us and others. 5. Apps as plugins - Michal presented the various ideas we had, arguments in both directions. - No conclusions today, just something to think about. - Considerations: - plugins are getting awesome treatment: - universe - dependencies - versioning - add/remove/upgrade - access to native - multiple plugins in one repo - apps are getting some treatment: - the app manifest has access to platform properties - merges folder - So the observation is, if we merge the two concepts, we could potentially share the benefits, with some changes to the tools required (and certain confusion). 6. www to be moved into a named app folder - currently www/ has to have config.xml inside it, docs inside it, README etc - merges folder is already a sibling of www/ but its logically part of the app. - So, move everything out of www that isn't the actual assets of the app. - Option 1: move everything to root, but then cordova files (platforms, plugins) clutter you app repo. - Option 2: move our current merges/ and www/ folder into a named folder (ie. "app") - Open question: should we support multiple named app folders? On Fri, Mar 22, 2013 at 11:55 AM, Andrew Grieve wrote: > Let's use this gdoc as an agenda / place to take notes:
Re: tag 2.6.0rc1 soon?
Hi Fil, Since cordova-osx is functional now -- how do I add JIRA tasks to the script (not sure where it is exactly) you used to add subtasks for a release? I want to add "Update www/ application for OS X" and "Update JavaScript for OS X" sub-tasks. On Thu, Mar 21, 2013 at 10:09 AM, Filip Maj wrote: > Alright folks, mobile-spec and cordova-js are tagged 2.6.0rc1, and the > 2.6.x branches on both those repos are now pushed up. Gogo release mode! > > On 3/21/13 9:12 AM, "James Jong" wrote: > > >Nice. Thanks Michal. > > > >-James Jong > > > >On Mar 21, 2013, at 11:57 AM, Michal Mocny wrote: > > > >> Yes, the intent is to have living branches. We may also cherry-pick > >> regressions back to more than just the current release. > >> > >> > >> On Thu, Mar 21, 2013 at 11:50 AM, James Jong > >>wrote: > >> > >>> Thanks Braden. Is the intent to have 'living' branches for each major > >>> release (e.g. 2.6, 3.0) which contain tags for release candidates and > >>>minor > >>> revisions? So going forward we would have 2.6.x , 3.0.x, ... branches? > >>> > >>> -James Jong > >>> > >>> On Mar 21, 2013, at 10:36 AM, Braden Shepherdson > >>> wrote: > >>> > I meant to send an email about this last night. Here's the > (high-level) > process we'll need to follow for each of the repos. > > Step 0: This time only, delete the 'next' branch. We're not using them > anymore, and they'll just add confusion. > Step 1: Checkout and pull master. > Step 2: git checkout -b 2.6.x (now you're on the new branch 2.6.x) > Step 3: tag 2.6.0.rc1 (on the 2.6.x branch) > Step 4: Push the branch and tag. > > NB: The branch is for the minor revision (ie. 2.6.x) not the point > >>> release > (2.6.0). The branch will have tags called 2.6.0rc1, 2.6.0rc2, etc. and > >>> then > 2.6.0. Any 2.6.1 that we do will be on this 2.6.x branch as well, just > adding more tags. > > Remember that commits always land in master first. Regression fixes > >>> should > be cherry-picked to 2.6.x after being committed to master. > > Braden > > > > > On Thu, Mar 21, 2013 at 10:17 AM, James Jong > >>> wrote: > > > Is the new release branching process for 2.6 posted somewhere? I > >didn't > > see it searching through the emails. > > > > -James Jong > > > > On Mar 20, 2013, at 1:37 PM, Braden Shepherdson > > > wrote: > > > >> My changes are in. > >> > >> > >> On Wed, Mar 20, 2013 at 1:24 PM, Filip Maj wrote: > >> > >>> Alright sounds like we need to wait on those pull reqs. > >>> > >>> Braden, if you get it in time, great, otherwise, not a big deal. > >>> > >>> Related: can someone recap the newer release/branching/tagging > >>> approach > > we > >>> talked about at the face-to-face (and let's decide if we want to > >>>use > >>> it > > or > >>> not)? > >>> > >>> On 3/20/13 9:20 AM, "Shazron" wrote: > >>> > I'm trying to get CB-52 for FileTransfer upload/download and the > keyboardformaccessorybar re-fix in as well - also seeing if the > FileTransfer mobile-spec stuff works to test. Was planning on > pulling > > in > the iOS pull requests but may not have time, but it seems Andrew > is > >>> on > > it > already :) > > > On Wed, Mar 20, 2013 at 8:50 AM, Braden Shepherdson > wrote: > > > I'm working on rolling some of the plugin JS loading logic into > > cordova-js. > > If that makes this release then it will be possible to play with > > plugman > > without also needing bleeding-edge JS. Note that this logic > >won't be > > active > > if there are no plugins, so it shouldn't be a high-risk change to > > slide > > in > > before a release. > > > > > > On Wed, Mar 20, 2013 at 11:20 AM, Andrew Grieve < > >>> agri...@chromium.org > >> wrote: > > > >> Time's feeling right for a release. > >> > >> I'm planning on going through pull requests today. Makes sense > >>to > >>> get > > those > >> all in before starting the release. > >> > >> > >> On Wed, Mar 20, 2013 at 6:49 AM, James Jong > >> > > wrote: > >> > >>> A couple of items I'd like to see get into 2.6: > >>> 1) Lorin's EXIF camera implementation > >>> > >>> 2) adding prompt dialog to the Notification API (completed, > >>>just > > needs > > to > >>> be merged in) > >>> https://github.com/apache/cordova-docs/pull/24 > >>> https://github.com/apache/cordova-js/pull/21 > >>> https://github.com/apache/cordova-ios/pull/35 > >>> https://github.com/apache/cordova-android/pull/
Re: archiving older platforms
I don't think we can put unused platforms in the Apache Attic - I think its for complete projects AFAIK http://attic.apache.org/ On Fri, Mar 22, 2013 at 11:22 AM, Lorin Beer wrote: > +1 > > @Jesse > >The attic sounds like its where you put code you're ashamed of. > > I prefer to look at it as the place to put code that you don't want getting > in the way, or biting guests to your home. > > > On Thu, Mar 21, 2013 at 11:49 PM, Jesse MacFadyen > wrote: > > > +1 to negligence, or might it be ignorance? > > > > The attic sounds like its where you put code you're ashamed of. > > > > Cheers, > > Jesse > > > > Sent from my iPhone5.5 > > > > On 2013-03-21, at 3:41 PM, Brian LeRoux wrote: > > > > Attic seems like more work than outright neglect. Might be for > > conceptual purity we want to move Bada there but I could see Qt and > > webOS rising from their slumber. > > > > > > On Thu, Mar 21, 2013 at 3:30 PM, Anis KADRI > wrote: > > > and no apache attic [1] ? > > > > > > [1] http://attic.apache.org/ > > > > > > > > > On Thu, Mar 21, 2013 at 3:28 PM, Brian LeRoux wrote: > > > > > >> This means we're going to leave Bada, Qt, webOS at their latest tags, > > >> and not dist. (Code still accessible, etc.) > > >> > > >> We'll continue as normal for BB, for now. > > >> > > >> > > >> > > >> On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner > wrote: > > >>> I am confused, who are the stewards and what platforms are being > > >> stewarded? > > >>> > > >>> Sent from my iPhone > > >>> > > >>> On 2013-03-21, at 6:00 PM, Filip Maj wrote: > > >>> > > +1 > > > > On 3/21/13 2:12 PM, "Shazron" wrote: > > > > > +1 > > > > > > > > > On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny > > > >> wrote: > > > > > >> +1 > > >> > > >> > > >> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > > >> > > >>> Ok, I think we have agreement that we'll put these guys on hold > > until > > >>> they find a steward. This means: > > >>> > > >>> - we won't be taggin them further > > >>> - we won't be including them in a release > > >>> > > >>> This does not mean: > > >>> > > >>> - deletion or archiving or attic for the src > > >>> > > >>> (Think of it as a pause button!) > > >>> > > >>> Agree/disagree? > > >>> > > >>> On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve < > > agri...@chromium.org > > >>> > > >>> wrote: > > If there are no fixes going into these platforms, then there is > no > > >>> benefit > > in their users updating them to newer versions of Cordova. > > > > There's going to be more refactoring required when moving > plugins > > to > > >>> their > > own repos. We'll really need owners for all platforms that will > > make > > >> the > > transition, or else we won't have any way to test that the > > >> refactoring > > hasn't broken a platform. On specific example is that > blackberry's > > >> JS > > >>> repo > > is really 4-in-1 currently, and our plugin spec doesn't have > > support > > >> for > > this. They will need to be split out into 4 separate platforms, > at > > >> least > > >>> as > > far as the JS is concerned. > > > > So... I guess my +1 is just for any platform that doesn't have a > > >> someone > > willing to focus on it. E.g. I'm fine with keeping WebOS around > if > > >> Markus > > wants to do the work to support it through this transition. > > > > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > > >> > > >>> wrote: > > > > > > > > We will try to provide relevant stats on platform adoption as > we > > >> are > > >>> able. > > > I am anxiously awaiting that information myself. ;) > > > > > > While lacking this information, I still feel that BBOS will be > > >> with us > > >>> for > > > a deal of time, particularly in the enterprise where we are > > seeing > > >> a > > > significant trend towards Cordova/PhoneGap/WebWorks as the > > primary > > >>> platform > > > of choice for apps. This is, frustratingly, a difficult market > to > > >> get > > > adequate metrics out of, as they will typically not use > PhoneGap > > >> Build > > >>> IMO, > > > and they don't deploy to commercial application stores. A bit > of > > a > > >> black > > > box, but our enterprise support teams continually support the > > >> notion > > >>> that > > > enterprise looks at HTML5 apps first. > > > > > > In this regard, we would like to see support for BBOS be > > >> maintained in > > >>> the > > > short term. Our team is focused on bringing up BlackBerry 10 > > built > > >> on > > > Cordova, and once that has gotten to a stable point
Re: [plugman] logic to support a repo that has more than one plugin
This has all of my +1s. Especially if our testing story is a dependent
plugin, this is way more convenient than two repos.
Braden
On Fri, Mar 22, 2013 at 2:19 PM, Brian LeRoux wrote:
> I'm into it.
>
> On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren wrote:
> > The main technical ask here is the ability to specify a plugin as { git
> > repo, commit hash, subdirectory } instead of just { git repo, commit
> hash }.
> >
> > On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux wrote:
> >
> >> Would have the benefit of enabling a plugin, and plugin-test existence
> >> in a single repo. Consolidates a lot of tooling. Lets discuss more
> >> herein
> >>
>
Re: [cordova-cli] - what does the plugins folder do?
We want this to stick around. One of my goals for the CLI is to make the platforms/foo subdirectories completely build artifacts. Native code, web assets, JS code, all get copied on every prepare. That's not currently true for native code, but it is for the rest. Since we're doing that, we need the full content of the plugins to stick around. Is there a problem with keeping this around? Braden On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux wrote: > Cool. So, is this interim or necessary to exist for all of time? > (Would assume you need some sort of staging area but not sure you need > to keep em around if we can cache the manifest info or something.) > > On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson > wrote: > > I assume you mean the top-level plugins/ folder in the CLI? > > > > That is where plugins are cached when you cordova plugin add them. > Whether > > they're coming from local directories or git or wherever, they get copied > > here. Then on a prepare this is where the plugin's assets are copied > from. > > > > Braden > > > > > > On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux wrote: > > > >> ... > >> >
Re: archiving older platforms
+1 @Jesse >The attic sounds like its where you put code you're ashamed of. I prefer to look at it as the place to put code that you don't want getting in the way, or biting guests to your home. On Thu, Mar 21, 2013 at 11:49 PM, Jesse MacFadyen wrote: > +1 to negligence, or might it be ignorance? > > The attic sounds like its where you put code you're ashamed of. > > Cheers, > Jesse > > Sent from my iPhone5.5 > > On 2013-03-21, at 3:41 PM, Brian LeRoux wrote: > > Attic seems like more work than outright neglect. Might be for > conceptual purity we want to move Bada there but I could see Qt and > webOS rising from their slumber. > > > On Thu, Mar 21, 2013 at 3:30 PM, Anis KADRI wrote: > > and no apache attic [1] ? > > > > [1] http://attic.apache.org/ > > > > > > On Thu, Mar 21, 2013 at 3:28 PM, Brian LeRoux wrote: > > > >> This means we're going to leave Bada, Qt, webOS at their latest tags, > >> and not dist. (Code still accessible, etc.) > >> > >> We'll continue as normal for BB, for now. > >> > >> > >> > >> On Thu, Mar 21, 2013 at 3:09 PM, Gord Tanner wrote: > >>> I am confused, who are the stewards and what platforms are being > >> stewarded? > >>> > >>> Sent from my iPhone > >>> > >>> On 2013-03-21, at 6:00 PM, Filip Maj wrote: > >>> > +1 > > On 3/21/13 2:12 PM, "Shazron" wrote: > > > +1 > > > > > > On Thu, Mar 21, 2013 at 1:46 PM, Michal Mocny > >> wrote: > > > >> +1 > >> > >> > >> On Thu, Mar 21, 2013 at 4:38 PM, Brian LeRoux wrote: > >> > >>> Ok, I think we have agreement that we'll put these guys on hold > until > >>> they find a steward. This means: > >>> > >>> - we won't be taggin them further > >>> - we won't be including them in a release > >>> > >>> This does not mean: > >>> > >>> - deletion or archiving or attic for the src > >>> > >>> (Think of it as a pause button!) > >>> > >>> Agree/disagree? > >>> > >>> On Wed, Mar 20, 2013 at 7:47 AM, Andrew Grieve < > agri...@chromium.org > >>> > >>> wrote: > If there are no fixes going into these platforms, then there is no > >>> benefit > in their users updating them to newer versions of Cordova. > > There's going to be more refactoring required when moving plugins > to > >>> their > own repos. We'll really need owners for all platforms that will > make > >> the > transition, or else we won't have any way to test that the > >> refactoring > hasn't broken a platform. On specific example is that blackberry's > >> JS > >>> repo > is really 4-in-1 currently, and our plugin spec doesn't have > support > >> for > this. They will need to be split out into 4 separate platforms, at > >> least > >>> as > far as the JS is concerned. > > So... I guess my +1 is just for any platform that doesn't have a > >> someone > willing to focus on it. E.g. I'm fine with keeping WebOS around if > >> Markus > wants to do the work to support it through this transition. > > > On Tue, Mar 19, 2013 at 10:52 PM, Ken Wallis > >> > >>> wrote: > > > > > We will try to provide relevant stats on platform adoption as we > >> are > >>> able. > > I am anxiously awaiting that information myself. ;) > > > > While lacking this information, I still feel that BBOS will be > >> with us > >>> for > > a deal of time, particularly in the enterprise where we are > seeing > >> a > > significant trend towards Cordova/PhoneGap/WebWorks as the > primary > >>> platform > > of choice for apps. This is, frustratingly, a difficult market to > >> get > > adequate metrics out of, as they will typically not use PhoneGap > >> Build > >>> IMO, > > and they don't deploy to commercial application stores. A bit of > a > >> black > > box, but our enterprise support teams continually support the > >> notion > >>> that > > enterprise looks at HTML5 apps first. > > > > In this regard, we would like to see support for BBOS be > >> maintained in > >>> the > > short term. Our team is focused on bringing up BlackBerry 10 > built > >> on > > Cordova, and once that has gotten to a stable point we will then > be > >>> able to > > look at resources and determine if BBOS is still a valuable > >> platform > >> to > > support and if we can port BBOS to the new structures. > > > > Hope that makes sense. > > > > Sent from my BlackBerry Z10 smartphone. > > From: Anis KADRI > > Sent: Monday, March 18, 2013 1:00 PM > > To: dev@cordova.apache.org > > Reply To: dev@cordova.apache.org > > Subject: Re: archivin
Re: request focus
I've messed around with programmatic view manipulation in native apps, on droid and iOS primarily. There's no reason that I'm aware of that these methods need to be private, and making sure that plugins/native code can change the view layout is important for overall architecture flexibility. It may not be the most common use case, but it's certainly an important one. +1 from me On Fri, Mar 22, 2013 at 7:38 AM, Andrew Grieve wrote: > Sounds good to me! > > > On Thu, Mar 21, 2013 at 9:09 PM, wrote: > > > Hi all, > > > > > > > > We have an android application mixing native views and a CordovaWebView. > > The problem is the CordovaWebView request the focus when launching the > > application even in our case it should not be the view selected by > > default. Unfortunately there is no easy way to override this behavior > > because inside CordovaWebView constructors a call to a private method > > setup is done where the focus is requested by calling > > requestFocusFromTouch which is also final. I would like to submit a pull > > request for at least change the visibility of setup to protected in > > order to override this behavior. How does it sound? Did I miss something > > about why setup is private? > > > > > > > > BR > > > > > > > > Denis > > > > >
Re: [plugman] logic to support a repo that has more than one plugin
I'm into it.
On Fri, Mar 22, 2013 at 11:11 AM, Max Woghiren wrote:
> The main technical ask here is the ability to specify a plugin as { git
> repo, commit hash, subdirectory } instead of just { git repo, commit hash }.
>
> On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux wrote:
>
>> Would have the benefit of enabling a plugin, and plugin-test existence
>> in a single repo. Consolidates a lot of tooling. Lets discuss more
>> herein
>>
Re: [cordova-cli] ripple instead of serve
omg I just realized this would fulfill offline use case vs lazy load vendoring caching could be a future thing might be a really nice path On Fri, Mar 22, 2013 at 11:06 AM, Gord Tanner wrote: > +1 > > With this I would want to add the ability to add a platform to a project even > if we don't have the build dependencies. > > Emulate would just default to ripple so is still usable if we can't > build/deploy > > Sent from my iPhone > > On 2013-03-22, at 1:55 PM, Brian LeRoux wrote: > >> I think this bleeds back into other discussions. It was mentioned in >> the call earlier. I think some tacit agreement that ./serve goes away >> and Ripple is the default ./emulate command. But lets discuss. (Just >> this. Lets keep thread focused.)
Re: [plugman] logic to support a repo that has more than one plugin
That is, specify a *version* of a plugin that way.
On Fri, Mar 22, 2013 at 2:11 PM, Max Woghiren wrote:
> The main technical ask here is the ability to specify a plugin as { git
> repo, commit hash, subdirectory } instead of just { git repo, commit hash }.
>
> On Fri, Mar 22, 2013 at 2:05 PM, Brian LeRoux wrote:
>
>> Would have the benefit of enabling a plugin, and plugin-test existence
>> in a single repo. Consolidates a lot of tooling. Lets discuss more
>> herein
>>
>
>
Re: [cordova-cli] vendoring the platforms instead of lazy download
It big. Certainly would be more efficient to lazy load, and cache so offline works. On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner wrote: > There was some issues over download size for our cli, any idea what the size > of all the platforms are? > > Sent from my iPhone > > On 2013-03-22, at 1:42 PM, Braden Shepherdson wrote: > >> I'm content to have the vendoring, it has some advantages as you wrote. >> >> However, I would also very much like to add a platform that's running from >> somewhere on my local disk, as I described in my feature request in the doc. >> >> So I propose a flag like cordova platform add android >> --target=../../cordova-android where that local directory can have >> whatever locally patched code I want. >> >> Braden >> >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux wrote: >> >>> Right now we put the release of Cordova into the npm package for >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x === >>> Cordova/Platform 2.5.latest). >>> >>> We did this because: >>> >>> - has to work offline >>> - cannot have a Git dep to do development >>> - issue tracking locked to the real version of Cordova >>> >>> We can solve all these issues. The code to do that isn't really a huge >>> deal. But to add it we gain very little that isn't already achieved by >>> vendoring. I'd like for us to be aware the current can be improved but >>> its low priority compared to, say, ripple and plugin integration. >>>
