Re: cordova platfor update DOA for cordova-android@4.1.0
Good catch! +1 on 4.1.1 > On Jul 30, 2015, at 6:41 PM, Steven Gill wrote: > > +1. I can get a vote out for it tomorrow >> On Jul 30, 2015 6:20 PM, "Carlos Santana" wrote: >> >> I think we need to fix and release a 4.1.1 this CB-9428 fixed before new >> cordova-cli get's released. >> >> the update logic lives in the platform update script, not the cordova cli >> >> https://issues.apache.org/jira/browse/CB-9428 >> >> basically doing an upgrade today like "cordova platform update >> android@4.1.0" >> is DOA when trying to build because the minSDK for CordovaLib get's updated >> to 14, but the minSDK for the App remains untouched to 10 >> >> if a new cordova-cli get's released with android 4.1.0 pinned, then the >> default platform update "cordova platform update" problem will be more >> prevalent and spread >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: JSHint breaks the build again
Yeah this rule is more of a style rule and doesn't check for language correctness. I'm ok with removing it but I'm also wondering if we should separately have some sort of a style checker (which will not block CI but give out warnings). -Original Message- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Tuesday, July 21, 2015 11:12 AM To: dev@cordova.apache.org Subject: RE: JSHint breaks the build again I agree with your disagreement. :) +1 to relaxing the condition. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Monday, July 20, 2015 6:00 PM To: dev@cordova.apache.org Subject: JSHint breaks the build again I am sick of seeing my commits cause build CI failures because of single vs double quote use. Can we relax this condition? I absolutely disagree with this being an error! Cheers, Jesse My team is hiring! @purplecabbage risingj.com - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Release Cordova Plugin npm Search
There's no such thing as dumb questions! npmjs sadly doesn't give out much information about packages.. >From what I recall, they didnt have author name and license information.. >which are important for us. > On Jul 15, 2015, at 9:06 PM, Carlos Santana wrote: > > dumb question why we are using npmsearch? and not a direct api to npmjs, > like I said it might be a dumb question > >> On Mon, Jul 13, 2015 at 6:39 PM Steven Gill wrote: >> >> Murat and I are going to meet tomorrow to try and launch this to >> plugins.cordova.io. Once it is out there, we can collect more feedback and >> make improvements. >> >> On Mon, Jul 13, 2015 at 3:21 PM, Murat Sutunc >> wrote: >> >>> There were two issues: >>> - Npmsearch uses npm2es on backend (https://www.npmjs.com/package/npm2es >> ). >>> The process running npm2es was hung. >>> - Elijah (owner of npmsearch) also changed the mappings in elasticsearch, >>> but never pointed the http server at the new index. >>> >>> He fixed both issues and npmsearch is now in sync with npm. Gulp also >>> relies on npmsearch for its plugin discovery so I'm hoping it will remain >>> stable. >>> >>> -Original Message- >>> From: Homer, Tony [mailto:tony.ho...@intel.com] >>> Sent: Monday, July 13, 2015 2:59 PM >>> To: dev@cordova.apache.org >>> Subject: Re: [DISCUSS] Release Cordova Plugin npm Search >>> >>> Great, looks much better now - thanks Murat! >>> >>> Can you shed some light on why this happened (and if it might happen >>> again)? >>> If the data is stale, it will hamper discovery of newly published >> plugins. >>> >>> Thanks! >>> Tony >>> >>>> On 7/13/15, 5:43 PM, "Murat Sutunc" wrote: >>>> >>>> Ok, we've managed to resolve the result set issues. It should be now in >>>> sync with npm. Woo! >>>> >>>> -Original Message- >>>> From: Murat Sutunc [mailto:mura...@microsoft.com] >>>> Sent: Friday, July 10, 2015 12:50 PM >>>> To: >>>> Subject: Re: [DISCUSS] Release Cordova Plugin npm Search >>>> >>>> I've reached out to npmsearch.com - trying to figure out why it's not >>>> updating. Will keep you guys updated. :/ >>>> >>>>> On Jul 10, 2015, at 12:46 PM, Homer, Tony >> wrote: >>>>> >>>>> That's true, but that doesn't account for the difference in the size >>>>> of the result set. >>>>> The query to both npmsearch.com and npmjs.com/search is >>>>> "ecosystem:cordova". >>>>> >>>>> Tony >>>>> >>>>>> On 7/10/15, 2:26 PM, "Jesse" wrote: >>>>>> >>>>>> The 370 results include lots of non-plugins. >>>>>> >>>>>> cordova-app-hello-world, cordova-wp8-testtest >>>>>> >>>>>> >>>>>> My team is hiring! >>>>>> @purplecabbage >>>>>> risingj.com >>>>>> >>>>>> On Fri, Jul 10, 2015 at 10:57 AM, Homer, Tony >>>>>> wrote: >>>>>> >>>>>>> I was just checking out the page - nice work, thanks for doing this! >>>>>>> >>>>>>> I had a question about the number of results. >>>>>>> There are 191 results listed on Cordova Plugin NPM search [1]. >>>>>>> I also get 191 if I visit (a slightly modified version of) the >>>>>>> search URL directly [2]. >>>>>>> But if I visit npmjs and search there for ecosystem:cordova [3], I >>>>>>> get >>>>>>> 370 >>>>>>> results. >>>>>>> >>>>>>> Is the large difference in results valid? >>>>>>> >>>>>>> 1. http://people.apache.org/~muratsu/?q= >>>>>>> 2. >>>>>>> >>>>>>> http://npmsearch.com/query?fields=name&q=keywords:%22ecosystem:cord >>>>>>> o >>>>>>> va%22 >>>>>>> &s >>>>>>> ize=500&start=0 >>>>>>> 3. https://www.npmjs.com/search?q=ecosystem%3Acordova >>>>>>> >>>>>>> Thanks! >>>>>&
RE: [DISCUSS] Release Cordova Plugin npm Search
There were two issues: - Npmsearch uses npm2es on backend (https://www.npmjs.com/package/npm2es). The process running npm2es was hung. - Elijah (owner of npmsearch) also changed the mappings in elasticsearch, but never pointed the http server at the new index. He fixed both issues and npmsearch is now in sync with npm. Gulp also relies on npmsearch for its plugin discovery so I'm hoping it will remain stable. -Original Message- From: Homer, Tony [mailto:tony.ho...@intel.com] Sent: Monday, July 13, 2015 2:59 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Release Cordova Plugin npm Search Great, looks much better now - thanks Murat! Can you shed some light on why this happened (and if it might happen again)? If the data is stale, it will hamper discovery of newly published plugins. Thanks! Tony On 7/13/15, 5:43 PM, "Murat Sutunc" wrote: >Ok, we've managed to resolve the result set issues. It should be now in >sync with npm. Woo! > >-----Original Message- >From: Murat Sutunc [mailto:mura...@microsoft.com] >Sent: Friday, July 10, 2015 12:50 PM >To: >Subject: Re: [DISCUSS] Release Cordova Plugin npm Search > >I've reached out to npmsearch.com - trying to figure out why it's not >updating. Will keep you guys updated. :/ > >> On Jul 10, 2015, at 12:46 PM, Homer, Tony wrote: >> >> That's true, but that doesn't account for the difference in the size >> of the result set. >> The query to both npmsearch.com and npmjs.com/search is >> "ecosystem:cordova". >> >> Tony >> >>> On 7/10/15, 2:26 PM, "Jesse" wrote: >>> >>> The 370 results include lots of non-plugins. >>> >>> cordova-app-hello-world, cordova-wp8-testtest >>> >>> >>> My team is hiring! >>> @purplecabbage >>> risingj.com >>> >>> On Fri, Jul 10, 2015 at 10:57 AM, Homer, Tony >>> wrote: >>> >>>> I was just checking out the page - nice work, thanks for doing this! >>>> >>>> I had a question about the number of results. >>>> There are 191 results listed on Cordova Plugin NPM search [1]. >>>> I also get 191 if I visit (a slightly modified version of) the >>>> search URL directly [2]. >>>> But if I visit npmjs and search there for ecosystem:cordova [3], I >>>> get >>>> 370 >>>> results. >>>> >>>> Is the large difference in results valid? >>>> >>>> 1. http://people.apache.org/~muratsu/?q= >>>> 2. >>>> >>>> http://npmsearch.com/query?fields=name&q=keywords:%22ecosystem:cord >>>> o >>>> va%22 >>>> &s >>>> ize=500&start=0 >>>> 3. https://www.npmjs.com/search?q=ecosystem%3Acordova >>>> >>>> Thanks! >>>> Tony >>>> >>>>> On 7/10/15, 1:32 PM, "Jesse" wrote: >>>>> >>>>> Sorting/filtering would be nice. >>>>> Resist the urge to duplicate the data shown on npm! >>>>> >>>>> >>>>> My team is hiring! >>>>> @purplecabbage >>>>> risingj.com >>>>> >>>>> On Fri, Jul 10, 2015 at 10:30 AM, Murat Sutunc >>>>> >>>>> wrote: >>>>> >>>>>> Can I also get access to remote couchdb? It would be great to go >>>>>> live today. >>>>>> >>>>>> -Original Message- >>>>>> From: Murat Sutunc >>>>>> Sent: Friday, July 10, 2015 10:29 AM >>>>>> To: dev@cordova.apache.org >>>>>> Subject: RE: [DISCUSS] Release Cordova Plugin npm Search >>>>>> >>>>>> Nikhil just profiled the website to identify bottlenecks. It's >>>>>> definitely something I'll be improving. >>>>>> >>>>>> I think giving more detailed information about plugins (eg >>>>>> rendering README.md or showing GH issue count) and sorting is >>>>>> future work. I >>>> want >>>>>> to >>>>>> ship a MVP to customers and get as much feedback as possible >>>>>> before >>>> we >>>>>> start working on such features. >>>>>> >>>>>> -Original Message- >>>>>> From: Carlos Santana [mailto:csantan...@gmail.com] >>>>>> Se
RE: [DISCUSS] Release Cordova Plugin npm Search
Ok, we've managed to resolve the result set issues. It should be now in sync with npm. Woo! -Original Message- From: Murat Sutunc [mailto:mura...@microsoft.com] Sent: Friday, July 10, 2015 12:50 PM To: Subject: Re: [DISCUSS] Release Cordova Plugin npm Search I've reached out to npmsearch.com - trying to figure out why it's not updating. Will keep you guys updated. :/ > On Jul 10, 2015, at 12:46 PM, Homer, Tony wrote: > > That's true, but that doesn't account for the difference in the size > of the result set. > The query to both npmsearch.com and npmjs.com/search is > "ecosystem:cordova". > > Tony > >> On 7/10/15, 2:26 PM, "Jesse" wrote: >> >> The 370 results include lots of non-plugins. >> >> cordova-app-hello-world, cordova-wp8-testtest >> >> >> My team is hiring! >> @purplecabbage >> risingj.com >> >> On Fri, Jul 10, 2015 at 10:57 AM, Homer, Tony >> wrote: >> >>> I was just checking out the page - nice work, thanks for doing this! >>> >>> I had a question about the number of results. >>> There are 191 results listed on Cordova Plugin NPM search [1]. >>> I also get 191 if I visit (a slightly modified version of) the >>> search URL directly [2]. >>> But if I visit npmjs and search there for ecosystem:cordova [3], I >>> get >>> 370 >>> results. >>> >>> Is the large difference in results valid? >>> >>> 1. http://people.apache.org/~muratsu/?q= >>> 2. >>> >>> http://npmsearch.com/query?fields=name&q=keywords:%22ecosystem:cordo >>> va%22 >>> &s >>> ize=500&start=0 >>> 3. https://www.npmjs.com/search?q=ecosystem%3Acordova >>> >>> Thanks! >>> Tony >>> >>>> On 7/10/15, 1:32 PM, "Jesse" wrote: >>>> >>>> Sorting/filtering would be nice. >>>> Resist the urge to duplicate the data shown on npm! >>>> >>>> >>>> My team is hiring! >>>> @purplecabbage >>>> risingj.com >>>> >>>> On Fri, Jul 10, 2015 at 10:30 AM, Murat Sutunc >>>> >>>> wrote: >>>> >>>>> Can I also get access to remote couchdb? It would be great to go >>>>> live today. >>>>> >>>>> -Original Message- >>>>> From: Murat Sutunc >>>>> Sent: Friday, July 10, 2015 10:29 AM >>>>> To: dev@cordova.apache.org >>>>> Subject: RE: [DISCUSS] Release Cordova Plugin npm Search >>>>> >>>>> Nikhil just profiled the website to identify bottlenecks. It's >>>>> definitely something I'll be improving. >>>>> >>>>> I think giving more detailed information about plugins (eg >>>>> rendering README.md or showing GH issue count) and sorting is >>>>> future work. I >>> want >>>>> to >>>>> ship a MVP to customers and get as much feedback as possible >>>>> before >>> we >>>>> start working on such features. >>>>> >>>>> -Original Message- >>>>> From: Carlos Santana [mailto:csantan...@gmail.com] >>>>> Sent: Thursday, July 9, 2015 3:51 PM >>>>> To: dev@cordova.apache.org >>>>> Subject: Re: [DISCUSS] Release Cordova Plugin npm Search >>>>> >>>>> What about rendering the README.md, I don't want to duplicate >>>>> npmjs, >>> but >>>>> it would might be better UX to have the readme rendered on the >>>>> same >>> page >>>>> instead opening a new window to npmjs >>>>> >>>>> what are you using for sorting results, can we sort by most >>>>> recent, plugins that get updated frequently tend to be more >>>>> healthy, option >>> to >>>>> sort >>>>> by download stat it's nice, but I guess that's on npmjs realm and >>> they >>>>> don't have that type of sorting in place. >>>>> >>>>>> On Thu, Jul 9, 2015 at 6:38 PM Shazron wrote: >>>>>> >>>>>> Plan looks good to me. >>>>>> One problem (not a blocker) is the performance of the search field. >>>>>> Try typing "cordova", it stutters as you type (tested on Safari 9 &
Re: [DISCUSS] Release Cordova Plugin npm Search
I've reached out to npmsearch.com - trying to figure out why it's not updating. Will keep you guys updated. :/ > On Jul 10, 2015, at 12:46 PM, Homer, Tony wrote: > > That's true, but that doesn't account for the difference in the size of > the result set. > The query to both npmsearch.com and npmjs.com/search is > "ecosystem:cordova". > > Tony > >> On 7/10/15, 2:26 PM, "Jesse" wrote: >> >> The 370 results include lots of non-plugins. >> >> cordova-app-hello-world, cordova-wp8-testtest >> >> >> My team is hiring! >> @purplecabbage >> risingj.com >> >> On Fri, Jul 10, 2015 at 10:57 AM, Homer, Tony >> wrote: >> >>> I was just checking out the page - nice work, thanks for doing this! >>> >>> I had a question about the number of results. >>> There are 191 results listed on Cordova Plugin NPM search [1]. >>> I also get 191 if I visit (a slightly modified version of) the search >>> URL >>> directly [2]. >>> But if I visit npmjs and search there for ecosystem:cordova [3], I get >>> 370 >>> results. >>> >>> Is the large difference in results valid? >>> >>> 1. http://people.apache.org/~muratsu/?q= >>> 2. >>> >>> http://npmsearch.com/query?fields=name&q=keywords:%22ecosystem:cordova%22 >>> &s >>> ize=500&start=0 >>> 3. https://www.npmjs.com/search?q=ecosystem%3Acordova >>> >>> Thanks! >>> Tony >>> >>>> On 7/10/15, 1:32 PM, "Jesse" wrote: >>>> >>>> Sorting/filtering would be nice. >>>> Resist the urge to duplicate the data shown on npm! >>>> >>>> >>>> My team is hiring! >>>> @purplecabbage >>>> risingj.com >>>> >>>> On Fri, Jul 10, 2015 at 10:30 AM, Murat Sutunc >>>> wrote: >>>> >>>>> Can I also get access to remote couchdb? It would be great to go live >>>>> today. >>>>> >>>>> -Original Message- >>>>> From: Murat Sutunc >>>>> Sent: Friday, July 10, 2015 10:29 AM >>>>> To: dev@cordova.apache.org >>>>> Subject: RE: [DISCUSS] Release Cordova Plugin npm Search >>>>> >>>>> Nikhil just profiled the website to identify bottlenecks. It's >>>>> definitely >>>>> something I'll be improving. >>>>> >>>>> I think giving more detailed information about plugins (eg rendering >>>>> README.md or showing GH issue count) and sorting is future work. I >>> want >>>>> to >>>>> ship a MVP to customers and get as much feedback as possible before >>> we >>>>> start working on such features. >>>>> >>>>> -Original Message- >>>>> From: Carlos Santana [mailto:csantan...@gmail.com] >>>>> Sent: Thursday, July 9, 2015 3:51 PM >>>>> To: dev@cordova.apache.org >>>>> Subject: Re: [DISCUSS] Release Cordova Plugin npm Search >>>>> >>>>> What about rendering the README.md, I don't want to duplicate npmjs, >>> but >>>>> it would might be better UX to have the readme rendered on the same >>> page >>>>> instead opening a new window to npmjs >>>>> >>>>> what are you using for sorting results, can we sort by most recent, >>>>> plugins that get updated frequently tend to be more healthy, option >>> to >>>>> sort >>>>> by download stat it's nice, but I guess that's on npmjs realm and >>> they >>>>> don't have that type of sorting in place. >>>>> >>>>>> On Thu, Jul 9, 2015 at 6:38 PM Shazron wrote: >>>>>> >>>>>> Plan looks good to me. >>>>>> One problem (not a blocker) is the performance of the search field. >>>>>> Try typing "cordova", it stutters as you type (tested on Safari 9 >>> and >>>>>> Chrome 43 >>>>>> Mac) >>>>>> >>>>>> On Thu, Jul 9, 2015 at 3:09 PM, Murat Sutunc >>> >>>>>> wrote: >>>>>> >>>>>>> Bump :) >>>>>>> >>>>>>> -Original Message- >>>>>>>
RE: [DISCUSS] Release Cordova Plugin npm Search
Can I also get access to remote couchdb? It would be great to go live today. -Original Message- From: Murat Sutunc Sent: Friday, July 10, 2015 10:29 AM To: dev@cordova.apache.org Subject: RE: [DISCUSS] Release Cordova Plugin npm Search Nikhil just profiled the website to identify bottlenecks. It's definitely something I'll be improving. I think giving more detailed information about plugins (eg rendering README.md or showing GH issue count) and sorting is future work. I want to ship a MVP to customers and get as much feedback as possible before we start working on such features. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, July 9, 2015 3:51 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Release Cordova Plugin npm Search What about rendering the README.md, I don't want to duplicate npmjs, but it would might be better UX to have the readme rendered on the same page instead opening a new window to npmjs what are you using for sorting results, can we sort by most recent, plugins that get updated frequently tend to be more healthy, option to sort by download stat it's nice, but I guess that's on npmjs realm and they don't have that type of sorting in place. On Thu, Jul 9, 2015 at 6:38 PM Shazron wrote: > Plan looks good to me. > One problem (not a blocker) is the performance of the search field. > Try typing "cordova", it stutters as you type (tested on Safari 9 and > Chrome 43 > Mac) > > On Thu, Jul 9, 2015 at 3:09 PM, Murat Sutunc > wrote: > > > Bump :) > > > > -Original Message- > > From: Murat Sutunc [mailto:mura...@microsoft.com] > > Sent: Tuesday, July 7, 2015 3:19 PM > > To: dev@cordova.apache.org > > Subject: [DISCUSS] Release Cordova Plugin npm Search > > > > Hey Everyone, > > > > I've been working on Cordova Plugin npm Search over the last few > > weeks. I feel we're now in a good shape to get this released. > > > > Please give it a spin: http://people.apache.org/~muratsu/ and use > > this thread to bring up any release blocking issues. > > > > My current thinking is that we handle the migration in two phases: > > > > Phase 1: > > > > - Create a new URL for the npm search - > > http://plugins.cordova.io/npm > > > > - Add a banner to the current CPR search re-directing traffic > use > > the new npm search - > > https://github.com/apache/cordova-registry-web/pull/17 > > > > - Continue making improvements based on feedback to npm search > > > > Phase 2: (NPM search is default) - July 20th > > > > - Move http://plugins.cordova.io URL to the npm plugin search > > page. > > > > - Move current CPR search http://plugins.cordova.io/lecacy/ > > > > PS: > > A special thank you to all who provided feedback on > > https://github.com/cordova/cordova-discuss/issues/7 and sent PRs > > > > Thanks, > > Murat > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
RE: [DISCUSS] Release Cordova Plugin npm Search
Nikhil just profiled the website to identify bottlenecks. It's definitely something I'll be improving. I think giving more detailed information about plugins (eg rendering README.md or showing GH issue count) and sorting is future work. I want to ship a MVP to customers and get as much feedback as possible before we start working on such features. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, July 9, 2015 3:51 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Release Cordova Plugin npm Search What about rendering the README.md, I don't want to duplicate npmjs, but it would might be better UX to have the readme rendered on the same page instead opening a new window to npmjs what are you using for sorting results, can we sort by most recent, plugins that get updated frequently tend to be more healthy, option to sort by download stat it's nice, but I guess that's on npmjs realm and they don't have that type of sorting in place. On Thu, Jul 9, 2015 at 6:38 PM Shazron wrote: > Plan looks good to me. > One problem (not a blocker) is the performance of the search field. > Try typing "cordova", it stutters as you type (tested on Safari 9 and > Chrome 43 > Mac) > > On Thu, Jul 9, 2015 at 3:09 PM, Murat Sutunc > wrote: > > > Bump :) > > > > -Original Message- > > From: Murat Sutunc [mailto:mura...@microsoft.com] > > Sent: Tuesday, July 7, 2015 3:19 PM > > To: dev@cordova.apache.org > > Subject: [DISCUSS] Release Cordova Plugin npm Search > > > > Hey Everyone, > > > > I've been working on Cordova Plugin npm Search over the last few > > weeks. I feel we're now in a good shape to get this released. > > > > Please give it a spin: http://people.apache.org/~muratsu/ and use > > this thread to bring up any release blocking issues. > > > > My current thinking is that we handle the migration in two phases: > > > > Phase 1: > > > > - Create a new URL for the npm search - > > http://plugins.cordova.io/npm > > > > - Add a banner to the current CPR search re-directing traffic > use > > the new npm search - > > https://github.com/apache/cordova-registry-web/pull/17 > > > > - Continue making improvements based on feedback to npm search > > > > Phase 2: (NPM search is default) - July 20th > > > > - Move http://plugins.cordova.io URL to the npm plugin search > > page. > > > > - Move current CPR search http://plugins.cordova.io/lecacy/ > > > > PS: > > A special thank you to all who provided feedback on > > https://github.com/cordova/cordova-discuss/issues/7 and sent PRs > > > > Thanks, > > Murat > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
RE: [DISCUSS] Release Cordova Plugin npm Search
Bump :) -Original Message- From: Murat Sutunc [mailto:mura...@microsoft.com] Sent: Tuesday, July 7, 2015 3:19 PM To: dev@cordova.apache.org Subject: [DISCUSS] Release Cordova Plugin npm Search Hey Everyone, I've been working on Cordova Plugin npm Search over the last few weeks. I feel we're now in a good shape to get this released. Please give it a spin: http://people.apache.org/~muratsu/ and use this thread to bring up any release blocking issues. My current thinking is that we handle the migration in two phases: Phase 1: - Create a new URL for the npm search - http://plugins.cordova.io/npm - Add a banner to the current CPR search re-directing traffic use the new npm search - https://github.com/apache/cordova-registry-web/pull/17 - Continue making improvements based on feedback to npm search Phase 2: (NPM search is default) - July 20th - Move http://plugins.cordova.io URL to the npm plugin search page. - Move current CPR search http://plugins.cordova.io/lecacy/ PS: A special thank you to all who provided feedback on https://github.com/cordova/cordova-discuss/issues/7 and sent PRs Thanks, Murat - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [VOTE] Plugins release - cordova-plugin-file-transfer
+1 * unpacked and tested/verified the changes * ran coho verify-archive -Original Message- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Tuesday, July 7, 2015 11:25 AM To: dev@cordova.apache.org Subject: [VOTE] Plugins release - cordova-plugin-file-transfer Please review and vote on the release of this plugins release by replying to this email (and keep discussion on the DISCUSS thread) Release issue: https://issues.apache.org/jira/browse/CB-9312 The plugins have been published to dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-9312 Upon a successful vote I will upload the archives to dist/ and npm. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md Voting will go on for a minimum of 48 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ran coho check-license to ensure all dependencies and subdependencies have Apache-compatible licenses Thanks, Nikhil - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
[DISCUSS] Release Cordova Plugin npm Search
Hey Everyone, I've been working on Cordova Plugin npm Search over the last few weeks. I feel we're now in a good shape to get this released. Please give it a spin: http://people.apache.org/~muratsu/ and use this thread to bring up any release blocking issues. My current thinking is that we handle the migration in two phases: Phase 1: - Create a new URL for the npm search - http://plugins.cordova.io/npm - Add a banner to the current CPR search re-directing traffic use the new npm search - https://github.com/apache/cordova-registry-web/pull/17 - Continue making improvements based on feedback to npm search Phase 2: (NPM search is default) - July 20th - Move http://plugins.cordova.io URL to the npm plugin search page. - Move current CPR search http://plugins.cordova.io/lecacy/ PS: A special thank you to all who provided feedback on https://github.com/cordova/cordova-discuss/issues/7 and sent PRs Thanks, Murat
RE: Introduction
Hey Paul, Welcome to Cordova! I've looked at your changes on github and have some early feedback. 1) As per spec you return a Promise on battery.js but to my knowledge we don't have a fallback for ES6 Promises on platforms that don't support it yet. I would like to know what other committers think about this problem. 2) I think the old API and the new API can co-exist for a while before we deprecate and remove the old one. I see that the new spec uses a different method name so we should be fine here. Thanks, Murat -Original Message- From: Paul Contat [mailto:contat.p...@gmail.com] Sent: Wednesday, July 1, 2015 12:38 AM To: dev@cordova.apache.org Subject: Introduction Hello everyone, My name is Paul Contat, and I'm an engineering student and currently doing an internship at W3C focusing on aligning cordova API with W3C ones where applicable, as part of the HTML5Apps EU project ( http://html5apps-project.eu/2014/08/27/aligning-cordova-and-w3c-device-apis/ ) For my internship, I’m planning to contribute to the cordova project, starting by the BatteryStatus API ( https://issues.apache.org/jira/browse/CB-6065) if it’s possible. I've just signed the ICLA, created an account on Apache JIRA so I’m ready to start and submitted my first pull request: https://github.com/apache/cordova-plugin-battery-status/pull/24 I’m looking forward to feedback on whether I’m on the right path for updating the Battery plugin API; I’m in particular interested to understand if and how the current API should be deprecated once we get to a stage where the new API is deemed in a good enough shape. Best regards, Paul
RE: Update plugin's package.json git url to github mirrors.
Yes +1 ! Now if only we could move our bugs as well :P -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, June 17, 2015 11:57 AM To: dev@cordova.apache.org Subject: Re: Update plugin's package.json git url to github mirrors. +1 easier onboarding of contributors My team is hiring! @purplecabbage risingj.com On Wed, Jun 17, 2015 at 11:54 AM, Shazron wrote: > +1 this will drive more contribution. > Keeping it to Apache git doesn't help the project -- since the > committers already know where the main repo is, but this would confuse others. > > Not sure about multiple repository fields, I suppose it's possible... > > On Wed, Jun 17, 2015 at 11:37 AM, Steven Gill > wrote: > > > How do people feel about changing the repo field in the package.json > > for our plugins to point to the github mirror instead of apache git repo? > > > > The url gets listed at > https://www.npmjs.com/package/cordova-plugin-camera > > on the left. The github mirror is much nicer looking and we receive > > all > of > > our PRs on github too. > > > > Thoughts? > > >
RE: Proposal: Cordova Plugin Search
Before I went ahead with the new page I've spent some time thinking about ways to improve our current search page (http://plugins.cordova.io/#/search?search=camera). The new site (http://people.apache.org/~muratsu/) isn't that big of a departure from the old one but has couple new UEX ideas. I must tell - I'm a huge fan of cards paradigm. Compared to tables it takes a bit more screen real estate but is much more elegant, expressive and easy to customize. Also below are some additional reasons why I preferred a new design: 1) In the old design we didn't have to display author as plugin names included the orgs. E.g. com.phonegap.plugins.barcodescanner. With npm, we need to grab the author name and display it next to plugin name. 2) I like the old filter by platform and got plans to add filtering in the future. But I also think we should be displaying platforms as small badges next to plugins. This helps with discoverability and encourages plugins with no tags to add them. 3) Bunch of extra information, such as last updated and license is also useful to see before going to details of a plugin. I personally find them useful but that's just me. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Friday, June 12, 2015 9:39 PM To: dev@cordova.apache.org Subject: Re: Proposal: Cordova Plugin Search Why we can't re-use some of the web app code that currently uses the cpr I like the UI, just change how to query the data logic to npm On Thu, Jun 11, 2015 at 1:12 PM Steven Gill wrote: > Nice list of tasks. I'll try to find some time to look at the PR in > the next few days. > > It might be nice to turn this search functionality (with the > blacklist) into a module others can incorporate into their tools. We > could potentially use it in the cordova cli (cordova plugin search) > and maybe some of the IDE developers here could use it as well. > > > > On Wed, Jun 10, 2015 at 2:19 PM, Victor Sosa > wrote: > > > Thanks for your prompt answer. Great to see the community will get a > > good search mechanism :-D > > > > On Wed, Jun 10, 2015 at 3:14 PM Murat Sutunc > > wrote: > > > > > I've updated the cordova-discussion with tasks and bugs, so it's > > > more clear what's planned for search page: > > > > > > https://github.com/cordova/cordova-discuss/issues/7#issuecomment-11089 > 3889 > > > > > > 1 - Yes, the goal for this page is to eventually replace current > > > plugin search page. CPR will be read-only on july 15th and > > > everyone here > agreed > > > that using npmjs.com isn't the best experience when it comes to > > > plugin searching. The idea is to offer a better user experience > > > from our > cordova > > > domain. > > > 2- The website is a static page. At this point, I don't think we > > > want > to > > > host a backend service. For now, you can use the same api that I'm > using > > ( > > > npmsearch.com :) ) > > > > > > -Original Message- > > > From: Victor Sosa [mailto:sosah.vic...@gmail.com] > > > Sent: Wednesday, June 10, 2015 10:54 AM > > > To: dev@cordova.apache.org > > > Subject: Re: Proposal: Cordova Plugin Search > > > > > > Hi Murat. > > > Two questions > > > > > > 1. This is for the community, is this going to be the official > > > search > > page > > > for cordova plugins in NPM? > > > 2. Do you plan to open a REST API so others can query this search page? > > > This would be awesome if others like me just want to receive a > > > JSON > with > > > the info. > > > > > > Thanks Murat, looks great! > > > > > > On Tue, Jun 9, 2015 at 7:44 PM Murat Sutunc > > > > > wrote: > > > > > > > I’ve created a PR for the first iteration of plugin search page. > > > > You can find the PR at > > > > https://github.com/apache/cordova-registry-web/pull/11 > > > > > > > > Current known issues: > > > > - Search should lowercase queries > > > > - Platform tags don't look good on ipad/iphone > > > > > > > > -Original Message- > > > > From: Joerg Holz [mailto:h...@hamburg.de] > > > > Sent: Saturday, June 6, 2015 1:26 PM > > > > To: dev@cordova.apache.org > > > > Subject: Re: Proposal: Cordova Plugin Search > > > > > > > > Thx, great job! > > > > > > > > If you need some help with CSS, … drop me a note.
npm Search Page FAQ
Hey everyone, I've been preparing a FAQ page to go with the new search page to help developers. Below is the first iteration I've prepared. If you have any feedback, I would greatly appreciate it!! https://gist.github.com/muratsu/3b90f963810a62f0b660 Thanks!!! Murat
Re: The Apache Cordova Community Slack channel is up!
Yeah retrying couple times worked for me earlier :) Sent from my iPhone > On Jun 12, 2015, at 12:15 PM, Shazron wrote: > > We're using a free heroku instance, might be starved. Try again in a bit. > > On Fri, Jun 12, 2015 at 12:07 PM, Dmitry Blotsky > wrote: > >> I’m getting a “something went wrong” error. ): >> >> - Dmitry >> On Jun 12, 2015, at 11:52 AM, Michael Brooks >>> wrote: >>> >>> Similar to our other supporting services, I've stored our Slackin >>> implementation on "cordova-labs" under the branch "slack-cordova-io". >>> >>> Repository: >>> https://github.com/apache/cordova-labs/tree/slack-cordova-io >>> >>> Full deployment instructions: >>> https://github.com/apache/cordova-labs/blob/slack-cordova-io/DEPLOY.md >>> >>> I used DEPLOY.md instead of README.md so that we can easily upgrade >> Slackin >>> in the future without destroying our deployment instructions. >>> >>> Cheers, >>> Michael >>> >>> On Fri, Jun 12, 2015 at 11:46 AM, Shazron wrote: All are welcome. Get your invite: http://slack.cordova.io This is a replacement for IRC, but not a replacement for decisions and voting, that still needs to be on the list. >> >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Proposal: Cordova Plugin Search
I've updated the cordova-discussion with tasks and bugs, so it's more clear what's planned for search page: https://github.com/cordova/cordova-discuss/issues/7#issuecomment-110893889 1 - Yes, the goal for this page is to eventually replace current plugin search page. CPR will be read-only on july 15th and everyone here agreed that using npmjs.com isn't the best experience when it comes to plugin searching. The idea is to offer a better user experience from our cordova domain. 2- The website is a static page. At this point, I don't think we want to host a backend service. For now, you can use the same api that I'm using (npmsearch.com :) ) -Original Message- From: Victor Sosa [mailto:sosah.vic...@gmail.com] Sent: Wednesday, June 10, 2015 10:54 AM To: dev@cordova.apache.org Subject: Re: Proposal: Cordova Plugin Search Hi Murat. Two questions 1. This is for the community, is this going to be the official search page for cordova plugins in NPM? 2. Do you plan to open a REST API so others can query this search page? This would be awesome if others like me just want to receive a JSON with the info. Thanks Murat, looks great! On Tue, Jun 9, 2015 at 7:44 PM Murat Sutunc wrote: > I’ve created a PR for the first iteration of plugin search page. > You can find the PR at > https://github.com/apache/cordova-registry-web/pull/11 > > Current known issues: > - Search should lowercase queries > - Platform tags don't look good on ipad/iphone > > -Original Message- > From: Joerg Holz [mailto:h...@hamburg.de] > Sent: Saturday, June 6, 2015 1:26 PM > To: dev@cordova.apache.org > Subject: Re: Proposal: Cordova Plugin Search > > Thx, great job! > > If you need some help with CSS, … drop me a note. > > > Joerg > > > > Am 06.06.2015 um 02:09 schrieb Murat Sutunc : > > > > Got some updates on this proposal! > > I've prepared a live demo on: http://people.apache.org/~muratsu/ > > Please visit the webpage and let me know what you think! > > > > Thanks, > > Murat > > > > -Original Message- > > From: Murat Sutunc [mailto:mura...@microsoft.com] > > Sent: Wednesday, June 3, 2015 11:41 AM > > To: dev@cordova.apache.org > > Subject: Proposal: Cordova Plugin Search > > > > Hey everyone, > > I've seen couple folks mention the idea of turning > > plugins.cordova.io > into a Gulp & Yeoman style search page on dev mailing list. I've gone > ahead and created a proposal for how we might potentially tackle this problem. > Please see the extended discussion at GH: > https://github.com/cordova/cordova-discuss/issues/7 > > > > I'm looking forward to hear your ideas about this new search page! > Please feel free to comment on gh issue! > > > > Thanks, > > Murat > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > Jörg Holz | +49-175-640 35 80 > h...@hamburg.de > > NEU: doreport - die Reportingsoftware: > http://www.doreport.de > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
RE: Proposal: Cordova Plugin Search
I’ve created a PR for the first iteration of plugin search page. You can find the PR at https://github.com/apache/cordova-registry-web/pull/11 Current known issues: - Search should lowercase queries - Platform tags don't look good on ipad/iphone -Original Message- From: Joerg Holz [mailto:h...@hamburg.de] Sent: Saturday, June 6, 2015 1:26 PM To: dev@cordova.apache.org Subject: Re: Proposal: Cordova Plugin Search Thx, great job! If you need some help with CSS, … drop me a note. Joerg > Am 06.06.2015 um 02:09 schrieb Murat Sutunc : > > Got some updates on this proposal! > I've prepared a live demo on: http://people.apache.org/~muratsu/ > Please visit the webpage and let me know what you think! > > Thanks, > Murat > > -Original Message- > From: Murat Sutunc [mailto:mura...@microsoft.com] > Sent: Wednesday, June 3, 2015 11:41 AM > To: dev@cordova.apache.org > Subject: Proposal: Cordova Plugin Search > > Hey everyone, > I've seen couple folks mention the idea of turning plugins.cordova.io into a > Gulp & Yeoman style search page on dev mailing list. I've gone ahead and > created a proposal for how we might potentially tackle this problem. Please > see the extended discussion at GH: > https://github.com/cordova/cordova-discuss/issues/7 > > I'm looking forward to hear your ideas about this new search page! Please > feel free to comment on gh issue! > > Thanks, > Murat > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > Jörg Holz | +49-175-640 35 80 h...@hamburg.de NEU: doreport - die Reportingsoftware: http://www.doreport.de - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Proposal: Cordova Plugin Search
Got some updates on this proposal! I've prepared a live demo on: http://people.apache.org/~muratsu/ Please visit the webpage and let me know what you think! Thanks, Murat -Original Message- From: Murat Sutunc [mailto:mura...@microsoft.com] Sent: Wednesday, June 3, 2015 11:41 AM To: dev@cordova.apache.org Subject: Proposal: Cordova Plugin Search Hey everyone, I've seen couple folks mention the idea of turning plugins.cordova.io into a Gulp & Yeoman style search page on dev mailing list. I've gone ahead and created a proposal for how we might potentially tackle this problem. Please see the extended discussion at GH: https://github.com/cordova/cordova-discuss/issues/7 I'm looking forward to hear your ideas about this new search page! Please feel free to comment on gh issue! Thanks, Murat - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [VOTE] Partial Tools Release June 1, 2015
+1 I've verified the following: * coho verify-archive * versions displayed correctly * installed android correctly -Original Message- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Wednesday, June 3, 2015 5:03 PM To: dev@cordova.apache.org Subject: RE: [VOTE] Partial Tools Release June 1, 2015 +1. I verified the following: * Confirmed signature with `coho verify-archive` * Manually verified tags * Verified it picks up the 3.7.2 version of Android. Thanks, Nikhil -Original Message- From: Tim Barham [mailto:tim.bar...@microsoft.com] Sent: Tuesday, June 2, 2015 9:41 AM To: 'dev@cordova.apache.org' Subject: [VOTE] Partial Tools Release June 1, 2015 Please review and vote on this partial Tools Release (lib and cli only) by replying to this email (and keep discussion on the DISCUSS thread) This release is to provide a 4.3.1 patch that pins Android 3.7.2 (a security release). Release issue: https://issues.apache.org/jira/browse/CB-9103 The packages have been published to dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-9103/ The packages were published from their corresponding git tags: cordova-lib: 4.3.1 (0f244f6dca) cordova-cli: 4.3.1 (327357a560) Upon a successful vote I will upload the archives to dist/, publish them to NPM, and post the corresponding blog post. Voting guidelines: https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md Voting will go on for a minimum of 48 hours. I vote +1: * Ran coho audit-license-headers over the relevant repos * Ran coho check-license to ensure all dependencies and subdependencies have Apache-compatible licenses * Verified install from npm * Added and built for android and windows platforms (verified patched version of android platform was installed) Thanks! Tim - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Proposal: Cordova Plugin Search
Hey everyone, I've seen couple folks mention the idea of turning plugins.cordova.io into a Gulp & Yeoman style search page on dev mailing list. I've gone ahead and created a proposal for how we might potentially tackle this problem. Please see the extended discussion at GH: https://github.com/cordova/cordova-discuss/issues/7 I'm looking forward to hear your ideas about this new search page! Please feel free to comment on gh issue! Thanks, Murat
RE: Hello
Welcome Vishal !! Happy to have another contributor :) -Original Message- From: Vishal Mishra [mailto:vismi...@adobe.com] Sent: Thursday, May 28, 2015 11:30 AM To: dev@cordova.apache.org Subject: Hello Hi, I am Vishal and have joined the Adobe team that works on Cordova. I will be working on making Cordova work better with the new devices and platforms. Regards, Vishal - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: "Best" place to browse plugins
I had some free time today and started working on a plugin search prototype. Currently it doesn't offer much but it's very similar to what Gulp has. GH: https://github.com/muratsu/cordova-plugin-search Imgur (can't add images to mails :( ): http://imgur.com/sX8oFcJ One problem I've run into is discoverability. Currently we're using the keyword `ecosystem:cordova` with all of the plugins. Ecosystem is a wider term than plugins and will most likely contain irrelevant search results. I was hoping that we switch to using `cordova-plugin` or `cordovaplugin` keyword going forward for better discoverability. Also for comparison, yeoman uses `yeoman-generator`, gulp uses `gulpplugin` and grunt uses `gruntplugin`. Thoughts? -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, May 28, 2015 3:35 PM To: dev@cordova.apache.org Cc: Tommy-Carlos Williams Subject: Re: "Best" place to browse plugins npm does have a plan to improve their ecosystem + communities later this year. We will essentially get a portal for cordova on npmjs. I also agree in turning plugins.cordova.io into a Gulp & Yeoman style search page. Probably won't be doing that until our current registry is shut down I imagine. On Wed, May 27, 2015 at 7:42 AM, Kerri Shotts wrote: > +1 > > I've used both Gulp & Yeoman's search, and prefer both to NPM > (although it's not difficult to be better than NPM's search). > > I also think close association with the brand and site are important. > For those users who don't know about Node & NPM yet, it's quickly > apparent that there's a large community creating plugins for Cordova, > and for everyone else, we have a URL that helps reinforce the Cordova > name. NPM would still be canonical, of course. > > (Now if NPM improved their search and did some nice work around > ecosystems, perhaps the above wouldn't be necessary. But I'm not going > to hold my breath...) > > > > > On May 27, 2015 at 8:19:35 AM, Tommy-Carlos Williams > (to...@devgeeks.org) > wrote: > > +1 > > > > > On 26 May 2015, at 21:44, Carlos Santana wrote: > > > > I would like to see plugin.cordova.io be a page easy to search and > filter > > cordova plugins just like gulp [1], grunt [2], yeoman [3] and bower > > [4] > > > > [1]: http://gulpjs.com/plugins > > [2]: http://gruntjs.com/plugins > > [3]: http://yeoman.io/generators > > [4]: http://bower.io/search > > > > > > > > On Sat, May 2, 2015 at 3:57 PM Michael Brooks > > > > wrote: > > > >>> > >>> The mirroring may not help for search, but my worry is that a lot > >>> of > >> folks > >>> would still be on 4.3.0 and when cordova plugins registry becomes > >>> read only, they would not get bug fixes and other plugin updates. > >> > >> > >> My experience is this: > >> > >> - A developer who is willing to upgrade a platform is also willing > >> to upgrading a plugin. > >> - A developer who is *not* willing to upgrade a platform is also > >> *not* willing in upgrading a plugin. > >> > >> I think it's reasonable to offer a read-only state for the legacy > >> plugin registry. However, it would be helpful for the registry to > >> explain the minimum Cordova version required to support the npm registry. > >> > >> Michael > >> > >> On Fri, May 1, 2015 at 9:01 AM, Parashuram N (MS OPEN TECH) < > >> panar...@microsoft.com> wrote: > >> > >>> The mirroring may not help for search, but my worry is that a lot > >>> of > >> folks > >>> would still be on 4.3.0 and when cordova plugins registry becomes > >>> read only, they would not get bug fixes and other plugin updates. > >>> > >>> -Original Message- > >>> From: Victor Sosa [mailto:sosah.vic...@gmail.com] > >>> Sent: Friday, May 1, 2015 8:59 AM > >>> To: dev@cordova.apache.org > >>> Subject: Re: "Best" place to browse plugins > >>> > >>> I don't see a value on mirroring either. Instead I'd like to see a > >>> good querying mechanism in NPM, but for that we have to wait :/ > >>> > >>> 2015-05-01 10:55 GMT-05:00 Raymond Camden : > >>> > I don't know - if npm is the place, then having a mirror just > seems like noise. I'd say close it down and put a nice text > message up on the site explaining where it is at NPM and how to > search. (Link to npm with the search params included.) > > Is there a benefit of having it mirrored? > > > > On Fri, May 1, 2015 at 10:49 AM, Parashuram N (MS OPEN TECH) > wrote: > > It would be even better (for backward compatibility reasons) if > > we could > simply publish on npm, but keep plugins.cordova.io as a > mirror/redirector, based on the Cordova registry mapper. > > > > -Original Message- > > From: Gorkem Ercan [mailto:gorkem.er...@gmail.com] > > Sent: Friday, May 1, 2015 8:31 AM > > To: dev@cordova.apache.org > > Subject: Re: "Best" place to browse plugins > > > > > > What is the plan for plugins.cordova.io for after the CPR is c
Couple questions
Hey everyone, I've two simple questions: 1) How do we close github issues? There are PRs that are older than a year and there's no need for having them around. In fact having them around for so long can be discouraging to new contributors. 2) If we want to add pictures to plugin documentation, where should we store the pictures? Currently the English doc lives under plugin\README.md, translations live under plugin\doc\language\index.md. Should I go ahead and create an images folder under docs or will it break some automation we have? Sorry for the noise :) Thanks, Murat
RE: Building cordova.js on first build
I think this would be a valuable addition to coho. +1 -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Tuesday, May 26, 2015 5:40 PM To: dev@cordova.apache.org Subject: Re: Building cordova.js on first build npm linking is suggested when testing platform specific JS changes. cordova-coho's prepare-release-branch command will generate cordova.js and move it over to the platform, as well as other things, when doing a release. It might be worth breaking out the generating and moving JS part of that step in coho to make that command standalone so platform developers could do cordova-coho update-js -r windows to generate + copy cordova.js into cordova-windows (sibling to cordova-coho). On Tue, May 26, 2015 at 5:25 PM, Murat Sutunc wrote: > Thanks Steven for clarifying this for me. > > For now I'll update the www\cordova.js manually for the windows platform. > Windows cordova.js is outdated and I'm hitting a bug. > > Personally, I'm +1 with auto generating cordova.js but it's not as > easy as I originally thought because of the dependencies. > > Currently, updating cordova.js is also not so trivial. We have a > folder structure like this: > > Cordova Project > ├─┬ cordova-js @ Dev (local) Version > │ └── cordova-windows @ NPM Version > └── cordova-windows @ Dev (local) Version > > For platform developers the easiest workflow is to npm-link > cordova-js\cordova-windows to cordova-windows. Once linked you have to > grunt compile cordova-js and manually move file over cordova-windows. > > On second thought, regenerating cordova.js from cordova-cli is not a > great idea. For browserify workflow it makes a lot of sense because we > don't know which plugins the user has but otherwise the file is static. > > -Original Message- > From: Steven Gill [mailto:stevengil...@gmail.com] > Sent: Tuesday, May 26, 2015 5:10 PM > To: dev@cordova.apache.org > Subject: Re: Building cordova.js on first build > > If people are into it, I can handle this one as I am very familiar > with the code base since I just did it for the browserify workflow. > > On Tue, May 26, 2015 at 4:15 PM, Steven Gill > wrote: > > > Hey Murat, > > > > By two files you mean cordova-js-src and www\cordova.js I assume. > > The www\cordova.js file is generated and updated on each release of > > the platform. It will use cordova-js-src to build it when available > > (instead of legacy-exe version) > > > > Problem with removing www\cordova.js and building it on runtime is > > that we loose support of platforms being able to build cordova > > projects independently of cordova-cli. We would have to have > > cordova.js as a dependency for each platform to be able to keep the > > ./bin/create scripts still having access to a cordova.js file. > > > > Right now, the browserify way builds cordova.js at runtime with the > > CLI by grabbing cordova-js-src from platform_www of added platforms > > or from cordovajs/src/legacy-exec if cordova-js-src doesn't exist > > (older > > platforms) . Because of this, we already have cordovajs as a > > dependency of cordova-lib. So theoretically, we could build > > cordova.js at runtime for non-browserify use case using a similar workflow. > > > > I think we should keep the www\cordova.js for now, and add > > non-browserify runtime cordova.js generation behind a flag so we can > > test it out. I see the value in it because we have use cases where > > we update the platform specific JS (in cordova-js-src) but can't > > test without generating a new cordova.js and moving it over to our > > platforms. > > > > Obviously using the --browserify flag will also work for you to be > > able to test those platform specific changes. > > > > On Tue, May 26, 2015 at 3:31 PM, Murat Sutunc > > > > wrote: > > > >> Hey there, > >> I've a quick question. Now that every platform comes with > >> cordova-js-src should we remove the www\cordova.js from platform repos? > >> I think it's a better idea to compile cordova.js on first build if > >> it's missing. This way we don't have to update two files when > >> working on platform js. > >> Thoughts? > >> > >> Thanks, > >> Murat > >> > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
RE: Building cordova.js on first build
Thanks Steven for clarifying this for me. For now I'll update the www\cordova.js manually for the windows platform. Windows cordova.js is outdated and I'm hitting a bug. Personally, I'm +1 with auto generating cordova.js but it's not as easy as I originally thought because of the dependencies. Currently, updating cordova.js is also not so trivial. We have a folder structure like this: Cordova Project ├─┬ cordova-js @ Dev (local) Version │ └── cordova-windows @ NPM Version └── cordova-windows @ Dev (local) Version For platform developers the easiest workflow is to npm-link cordova-js\cordova-windows to cordova-windows. Once linked you have to grunt compile cordova-js and manually move file over cordova-windows. On second thought, regenerating cordova.js from cordova-cli is not a great idea. For browserify workflow it makes a lot of sense because we don't know which plugins the user has but otherwise the file is static. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Tuesday, May 26, 2015 5:10 PM To: dev@cordova.apache.org Subject: Re: Building cordova.js on first build If people are into it, I can handle this one as I am very familiar with the code base since I just did it for the browserify workflow. On Tue, May 26, 2015 at 4:15 PM, Steven Gill wrote: > Hey Murat, > > By two files you mean cordova-js-src and www\cordova.js I assume. The > www\cordova.js file is generated and updated on each release of the > platform. It will use cordova-js-src to build it when available > (instead of legacy-exe version) > > Problem with removing www\cordova.js and building it on runtime is > that we loose support of platforms being able to build cordova > projects independently of cordova-cli. We would have to have > cordova.js as a dependency for each platform to be able to keep the > ./bin/create scripts still having access to a cordova.js file. > > Right now, the browserify way builds cordova.js at runtime with the > CLI by grabbing cordova-js-src from platform_www of added platforms or > from cordovajs/src/legacy-exec if cordova-js-src doesn't exist (older > platforms) . Because of this, we already have cordovajs as a > dependency of cordova-lib. So theoretically, we could build cordova.js > at runtime for non-browserify use case using a similar workflow. > > I think we should keep the www\cordova.js for now, and add > non-browserify runtime cordova.js generation behind a flag so we can > test it out. I see the value in it because we have use cases where we > update the platform specific JS (in cordova-js-src) but can't test > without generating a new cordova.js and moving it over to our platforms. > > Obviously using the --browserify flag will also work for you to be > able to test those platform specific changes. > > On Tue, May 26, 2015 at 3:31 PM, Murat Sutunc > wrote: > >> Hey there, >> I've a quick question. Now that every platform comes with >> cordova-js-src should we remove the www\cordova.js from platform repos? >> I think it's a better idea to compile cordova.js on first build if >> it's missing. This way we don't have to update two files when working >> on platform js. >> Thoughts? >> >> Thanks, >> Murat >> > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Building cordova.js on first build
Hey there, I've a quick question. Now that every platform comes with cordova-js-src should we remove the www\cordova.js from platform repos? I think it's a better idea to compile cordova.js on first build if it's missing. This way we don't have to update two files when working on platform js. Thoughts? Thanks, Murat
RE: [VOTE] cordova-plugin-vibration release
Sorry to hijack this thread but this is my first time verifying a release and I've some questions before signing off.. 1) I was looking at the coho docs but wasn't able to figure out how to download a release from dist/dev. Any tips? 2) For now I've manually copied the tgz files from the dist.apache and ran my validation. I've ran into the following issue, is it expected? C:\Users\muratsu\Desktop\plugin>coho verify-archive cordova-plugin-vibration-1.1.0.tgz Running from c:\dev ./ = Executing: gpg --verify C:\Users\muratsu\Desktop\plugin\cordova-plugin-vibration-1.1.0.tgz.asc C:\Users\muratsu\Desktop\plugin\cordova-plugin-vibration-1.1.0.tgz gpg: Signature made 05/07/15 17:24:14 Pacific Daylight Time using RSA key ID FFCA68BE gpg: Good signature from "Steve Gill (code signing key) " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: EBAC 6409 FA2F 2FCF A42C 1080 3843 B8F9 FFCA 68BE ./ = Computing MD5 for: C:\Users\muratsu\Desktop\plugin\cordova-plugin-vibration-1.1.0.tgz ./ = Computing SHA512 for: C:\Users\muratsu\Desktop\plugin\cordova-plugin-vibration-1.1.0.tgz SHA512 does not match. Other than this issue, changes look good to me. +1 -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, May 11, 2015 4:45 PM To: dev@cordova.apache.org Subject: Re: [VOTE] cordova-plugin-vibration release +1 On Mon, May 11, 2015 at 11:53 AM, Jesse wrote: > +1 > verify-archive > checked that my most recent changes were present > > @purplecabbage > risingj.com > > On Mon, May 11, 2015 at 10:46 AM, Steven Gill > wrote: > >> Bump >> >> On Thu, May 7, 2015 at 5:31 PM, Steven Gill >> wrote: >> >> > Please review and vote on the release of cordova-plugin-vibration >> > release by replying to this email (and keep discussion on the >> > DISCUSS thread) >> > >> > Release issue: https://issues.apache.org/jira/browse/CB-8959 >> > >> > The plugins have been published to dist/dev: >> https://dist.apache.org/repos/dist/dev/cordova/CB-8959/ >> > >> > The packages were published from their corresponding git tags: >> > cordova-plugin-vibration: 1.1.0 (81729f0f5c) >> > >> > Upon a successful vote I will upload the archives to dist/ and >> > upload it >> to npm. >> > >> > Voting guidelines: >> https://github.com/apache/cordova-coho/blob/master/docs/release-votin >> g.md >> > >> > Voting will go on for a minimum of 48 hours. >> > >> > I vote +1: >> > >> > >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [VOTE] Plugins Release (camera, file-transfer, dialogs, vibration, device-motion)
We seem to have some files missing the Apache license: cordova-plugin-camera/tests/ios/CDVCameraTest/CDVCameraLibTests/Info.plist cordova-plugin-vibration/src/blackberry10/native/.cproject cordova-plugin-vibration/src/blackberry10/native/.project cordova-plugin-vibration/src/windows/Vibration/Vibration.cs cordova-plugin-vibration/src/windows/Vibration/Vibration.csproj cordova-plugin-vibration/src/windows/Vibration/Properties/AssemblyInfo.cs -Original Message- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Thursday, May 7, 2015 1:20 PM To: dev@cordova.apache.org Subject: RE: [VOTE] Plugins Release (camera, file-transfer, dialogs, vibration, device-motion) * Verified signatures and hashes * Verified tags * Verified plugins added correctly to blank app * Verified blank app can be successfully ran and built * Ran smoke testing of mobilespec app * Performed manual ad-hoc testing * Verified Release Notes I vote +1. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Thursday, May 7, 2015 12:57 PM To: dev@cordova.apache.org Subject: Re: [VOTE] Plugins Release (camera, file-transfer, dialogs, vibration, device-motion) +1 * coho verify-archive * unpacked and verified each plugin could be installed, and run on ios * manually verified version numbers throughout all package.json and plugin.xml files @purplecabbage risingj.com On Wed, May 6, 2015 at 5:42 PM, Steven Gill wrote: > Please review and vote on the release of this plugins release by > replying to this email (and keep discussion on the DISCUSS thread) > > Release issue: https://issues.apache.org/jira/browse/CB-8959 > > The plugins have been published to > dist/dev:https://dist.apache.org/repos/dist/dev/cordova/CB-8959/ > > The packages were published from their corresponding git tags: > cordova-plugin-camera: 1.1.0 (19feee9cb0) > cordova-plugin-file-transfer: 1.1.0 (e251db5cac) > cordova-plugin-device-motion: 1.1.0 (7d52b8457d) > cordova-plugin-dialogs: 1.1.0 (439372988b) > cordova-plugin-vibration: 1.1.0 (4d316e2555) > > Upon a successful vote I will upload the archives to dist/, upload > them to npm, and post the corresponding blog post. > > Voting guidelines: > https://github.com/apache/cordova-coho/blob/master/docs/release-voting > .md > > Voting will go on for a minimum of 48 hours. > > I vote +1: > * Ran coho audit-license-headers over the relevant repos > * Ran coho check-license to ensure all dependencies and > subdependencies have Apache-compatible licenses > B CB [ X ܚX KK[XZ[ ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ ܙݘK \X K ܙ B
RE: [DISCUSS] Rapid release of tools
Ahh, thanks Steven for all the work! Glad to see Cordova working again! -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, May 7, 2015 1:19 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Rapid release of tools I have already published cordova-js@3.9.1 and cordova-lib@5.0.1 under the RC flag before I saw your message. I will unpublish them, delete tags, revert commits, etc. :( On Thu, May 7, 2015 at 1:16 PM, Steven Gill wrote: > Looks like they just fixed the issue by using an older version of npm > to publish JSONStream 1.0.2 and 1.0.3. No need for a release! Woot! > > FTR, I don't think the hotfix would have caused any issues for us as > long as they kept browserify 10.1.2 around. > > > > On Thu, May 7, 2015 at 1:01 PM, Murat Sutunc > wrote: > >> Wait guys. I think we should hold on for a sec. >> >> There are 3 possible scenarios: >> 1- We bump up our dependencies, latest version of Cordova is fixed >> but older ones remain broken. >> 2- Browserify and/or module-deps can roll back (unpublish perhaps). >> Which will fix the issue for all cordova until npm makes the fix. >> 3- NPM makes a quick fix. >> >> If we bump Cordova and browserify and module-deps decides to roll >> back, we'll be in trouble. I think the correct approach here is to >> talk with NPM and see what they suggest. If they commit on fixing >> this issue asap, browserify and module-deps can rollback and >> republish once everything is fixed. If you look at browserify and >> module-deps, using lowercase repos is a pretty recent change and >> there's probably less dependencies out there than Cordova. >> >> -Original Message- >> From: Steven Gill [mailto:stevengil...@gmail.com] >> Sent: Thursday, May 7, 2015 12:47 PM >> To: dev@cordova.apache.org >> Subject: Re: [DISCUSS] Rapid release of tools >> >> i'm working on getting the release ready >> >> On Thu, May 7, 2015 at 12:37 PM, Shazron wrote: >> >> > +1 release off previous, with this one change only. >> > >> > On Thu, May 7, 2015 at 12:07 PM, Steven Gill >> > >> > wrote: >> > > I am thinking we release off our previous release branches with >> > > this one change. This needs to get out asap. I'm all for an >> > > accelerated >> vote. >> > > >> > > >> > > >> > > On Thu, May 7, 2015 at 12:05 PM, Jesse >> wrote: >> > > >> > >> Given that all downstream distributions are broken currently, >> > >> can we do >> > an >> > >> accelerated vote? >> > >> Are we introducing any other code that would slow us down? or >> > >> can we >> > simply >> > >> update+republish package.json files? >> > >> >> > >> @purplecabbage >> > >> risingj.com >> > >> >> > >> On Thu, May 7, 2015 at 12:01 PM, Steven Gill >> > >> >> > >> wrote: >> > >> >> > >> > I think we should do a quick release to get npm install >> > >> > cordova >> > working >> > >> > again asap. >> > >> > >> > >> > I have updated the browserify dependency on cordova-js which >> > >> > fixes the problem. >> > >> > >> > >> > Need to release cordova-js@3.9.1, cordova-lib@5.0.1, >> > cordova-cli@5.0.1 >> > >> and >> > >> > plugman@0.23.2 with the new dependency. >> > >> > >> > >> >> > >> > --- >> > -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > For additional commands, e-mail: dev-h...@cordova.apache.org >> > >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [DISCUSS] Rapid release of tools
Wait guys. I think we should hold on for a sec. There are 3 possible scenarios: 1- We bump up our dependencies, latest version of Cordova is fixed but older ones remain broken. 2- Browserify and/or module-deps can roll back (unpublish perhaps). Which will fix the issue for all cordova until npm makes the fix. 3- NPM makes a quick fix. If we bump Cordova and browserify and module-deps decides to roll back, we'll be in trouble. I think the correct approach here is to talk with NPM and see what they suggest. If they commit on fixing this issue asap, browserify and module-deps can rollback and republish once everything is fixed. If you look at browserify and module-deps, using lowercase repos is a pretty recent change and there's probably less dependencies out there than Cordova. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, May 7, 2015 12:47 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Rapid release of tools i'm working on getting the release ready On Thu, May 7, 2015 at 12:37 PM, Shazron wrote: > +1 release off previous, with this one change only. > > On Thu, May 7, 2015 at 12:07 PM, Steven Gill > wrote: > > I am thinking we release off our previous release branches with this > > one change. This needs to get out asap. I'm all for an accelerated vote. > > > > > > > > On Thu, May 7, 2015 at 12:05 PM, Jesse wrote: > > > >> Given that all downstream distributions are broken currently, can > >> we do > an > >> accelerated vote? > >> Are we introducing any other code that would slow us down? or can > >> we > simply > >> update+republish package.json files? > >> > >> @purplecabbage > >> risingj.com > >> > >> On Thu, May 7, 2015 at 12:01 PM, Steven Gill > >> > >> wrote: > >> > >> > I think we should do a quick release to get npm install cordova > working > >> > again asap. > >> > > >> > I have updated the browserify dependency on cordova-js which > >> > fixes the problem. > >> > > >> > Need to release cordova-js@3.9.1, cordova-lib@5.0.1, > cordova-cli@5.0.1 > >> and > >> > plugman@0.23.2 with the new dependency. > >> > > >> > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: npm install cordova fails due to JSONStream dependency
This is a major issue in NPM !!
There is a thread going on at github: https://github.com/npm/npm/issues/7195
"browserify versions 5.0.0 - 10.1.1 (10.1.2 is the latest) can't be installed
because of JSONStream vs jsonstream on OS X and windows"
The real issue is browserify has a dependency on module-deps and JSONStream:
- browserify 7.1.0 has dependency on JSONStream 0.8.4
- browserify 7.1.0 has dependency on module-deps ^3.6.3
- module-deps 3.7.11 has dependency on jsonstream ^1.0.3
JSONStream and jsonstream are two separate repos. Lowercase jsonstream starts
at version 1.0.0 and mixed case doesn't have any 1.0.0 version. npm install
gets confused fails to install because it can't find both versions of the
package in the same repo.
All the Cordova versions which depend on this version of browserify is
currently broken!
-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Thursday, May 7, 2015 10:45 AM
To: dev@cordova.apache.org
Subject: Re: npm install cordova fails due to JSONStream dependency
Nikhil, what version of npm are you using?
On May 7, 2015 10:21 AM, "Jesse" wrote:
> Yeah, it is browserify's dependency on JSONStream and a recent change
> to npm that does not like package names with capital letters.
>
> browserify has fixed it by changing their use from JSONStream to
> jsonstream, however we are on a much older version of browserify, and
> can't simply update to the most recent.
>
> Probably we just need to give npm an hour or two to work it out.
>
>
> @purplecabbage
> risingj.com
>
> On Thu, May 7, 2015 at 9:59 AM, Nikhil Khandelwal
>
> wrote:
>
> > This is breaking npm install of all recent versions of cordova:
> >
> > λ npm install cordova
> > npm WARN engine cordova-js@3.9.0: wanted: {"node":"~0.10.x"} (current:
> > {"node":"0.12.0","npm":"2.5.1"})
> > npm WARN engine npm@1.3.4: wanted: {"node":">=0.6","npm":"1"} (current:
> > {"node":"0.12.0","npm":"2.5.1"})
> > npm WARN engine xmlbuilder@2.2.1: wanted: {"node":"0.8.x || 0.10.x"}
> > (current: {"node":"0.12.0","npm":"2.5.1"}) npm ERR! Windows_NT
> > 6.3.9600 npm ERR! argv "C:\\Program Files (x86)\\nodejsnode.exe"
> > "C:\\Program Files
> > (x86)\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "install"
> "cordova"
> > npm ERR! node v0.12.0
> > npm ERR! npm v2.5.1
> > npm ERR! code ETARGET
> >
> > npm ERR! notarget No compatible version found: JSONStream@'>=1.0.3
> <2.0.0'
> > npm ERR! notarget Valid install targets:
> > npm ERR! notarget
> >
> ["0.0.0","0.1.0","0.1.1","0.1.2","0.1.3","0.2.0","0.2.1","0.2.2","0.2.
> 3","0.3.0","0.3.1","0.3.2","0.3.3","0.4.0","0.4.1","0.4.2","0.4.3","0.
> 4.4","0.5.0","0.6.0","0.6.1","0.6.2","0.6.3","0.6.4","0.7.0","0.7.1","
> 0.8.0","0.7.2","0.7.3","0.7.4","0.8.1","0.8.2","0.8.3","0.8.4","0.9.0"
> ,"0.10.0"]
> > npm ERR! notarget
> > npm ERR! notarget This is most likely not a problem with npm itself.
> > npm ERR! notarget In most cases you or one of your dependencies are
> > requesting npm ERR! notarget a package version that doesn't exist.
> >
> > npm ERR! Please include the following file with any support request:
> > npm ERR! d:\apps\test\npm-debug.log
> >
> > Our browserify dependency is at the heart of the problem:
> > https://github.com/substack/node-browserify/issues/1249 but I don't
> > understand enough of npm dependency management to figure out how
> > this can be resolved. I'm still digging into this.
> >
> > Thanks,
> > Nikhil
> >
> >
> >
>
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Plugins release prep: Cherry-picking plugin updates
Hey, took me a while but we're good to go with: Camera, device-motion, dialogs and vibration. Thanks! -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, May 6, 2015 12:16 PM To: dev@cordova.apache.org Subject: Re: Plugins release prep: Cherry-picking plugin updates Sounds good. Thanks Rob On Wed, May 6, 2015 at 12:04 PM, Rob Paveza wrote: > Murat is still working on the merge to master for the Camera plugin. > I'll let you know when we're all squared away. > > -Original Message- > From: Steven Gill [mailto:stevengil...@gmail.com] > Sent: Wednesday, May 6, 2015 11:57 AM > To: dev@cordova.apache.org > Subject: Re: Plugins release prep: Cherry-picking plugin updates > > I haven't heard back. Should I move forward with those 5 plugins? > > file-transfer, device-motion, dialogs, vibration, and camera. > > I will update the process to support specific plugins release (instead > of all plugins) as I work through it. > > > On Tue, May 5, 2015 at 12:29 PM, Jesse wrote: > > > + file-transfer so we can resolve CB-8951 > > > > > > @purplecabbage > > risingj.com > > > > On Tue, May 5, 2015 at 12:19 PM, Steven Gill > > > > wrote: > > > > > Hey guys, > > > > > > I can help you out. The process is designed for all plugins but it > > > is pretty easy to do it for just a few. I've done it many times. > > > > > > If changes are on master, they shouldn't be incomplete. Any known > > > problem with release the master branch of those plugins? > > > > > > We could cherry-pick, but it is just more work than probably required. > > > Since we don't have release branches for plugins, just tags. > > > > > > If you guys merge changes into master, I can take over the release > > > or at least tell you the parts to modify in the release process to > > > make it > > work. > > > > > > -Steve > > > > > > On Tue, May 5, 2015 at 11:44 AM, Rob Paveza > > > > > > wrote: > > > > > > > Hi all - > > > > > > > > I started a [discuss] thread about plugin updates last week, > > effectively > > > > saying that we wanted to take four JIRA items which are causing > > problems > > > > for Windows 10: CB-8926, CB-8928, CB-8930, and CB-8943. Since > > > > Murat > > is a > > > > committer, he's actually trying to do the release. We're > > > > looking at device-motion, dialogs, vibration, and camera. > > > > > > > > However, as we go through the [release process]( > > > > > > > > > https://github.com/apache/cordova-coho/blob/master/docs/plugins-rele > > as > > e-process.md > > > ), > > > > there are a lot of things that give us pause, specifically that > > > > we're > > > going > > > > to end up tagging each plugin rather than just the four. We're > > > > also concerned that we'll bring in unstable or not-yet-completed > > > > changes > > from > > > > 'master' in some of the plugins. Instead, we're trying to > cherry-pick. > > > > > > > > So, we know that where the final state is supposed to be: > > > > - Each plugin that we're updating gets a new tag with a > > > > build-version > > > bump > > > > - The branch that we submitted as the PR should become the new > > > > tag > > (since > > > > it was based on the previous release tag) > > > > - Then we'll go on with the rest of the publish-to-NPM work, etc. > > > > > > > > Since all of the steps are automated, is there a straightforward > > > > way to cherry-pick the individual pieces that is known and has > > > > been used > > before? > > > > Or are we in new territory? > > > > > > > > Thanks! > > > > -Rob and Murat > > > > > > > > > > > > -- > > > > --- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Also moving to a new team
Best of luck on your new team Andrew! It's been a pleasure working with you. -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, May 5, 2015 8:16 AM To: dev Subject: Also moving to a new team As with Michal, you'll be seeing less of me around. My new full-time project will be on the Android port of Chrome. Just want to make it clear that us moving to new teams has nothing to do with a lack of faith in the project, but rather is due to needing a change of scenery and exciting new projects becoming available here. I'm super excited to see a new wave of committers joining the project! The momentum has certainly picked up: - Cordova-android 4.0.0 was huge - Plugins to npm was huge - Win10 and wkwebview will be massive launches as well! Great time for Cordova! (or a bad one... you know... if you're measuring against the goal of becoming obsolete :P) - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Two small tools for Cordova
Hey everyone, I've been working on two side projects that I think others might also find useful. Cordova Travis (https://www.npmjs.com/package/cordova-travis) Prints out the latest travis build result on console; for all Apache Cordova repos. Whenever there's something red, it's time to fix something :) Cordova Stale (https://www.npmjs.com/package/cordova-stale) This is more to help with our personal repos. Once a PR is merged we often forget to delete our own local branch. This tool helps to identify stale branches. Hope these would be useful. Thanks! Murat
RE: Scoped package names for npm?
From what I read so far, scopes are like namespaces for npm modules. So each npm user has their own scope. In our case we'll have one cordova user who will have modules like: .. @cordova/platform-ios @cordova/plugin-camera .. Unless you're the user cordova (or a collaborator), you can't publish new modules. In this case all our modules will be under cordova and 3rd party modules have to be under some other namespace (if they choose to use any). -Original Message- From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Monday, April 20, 2015 2:13 PM To: dev@cordova.apache.org Subject: RE: Scoped package names for npm? Scopes are like namespaces. In the reverse domain name world, org.apache.cordova was considered a namespace, right ? We did not want non core packages to publish to that namespace, so does the same argument apply ? Alternatively, we can think of scope as packages that apply to a particular environment - for example, all cordova packages would be @cordova scope. -Original Message- From: Michal Mocny [mailto:mmo...@google.com] Sent: Monday, April 20, 2015 2:03 PM To: dev Subject: Re: Scoped package names for npm? Other questions to answer: - Can 3rd-parties publish to this scope? - Do we want them to? - Do we want to default to @cordova scope if none is provided, such that you could do `cordova plugin add device`? -Michal On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny wrote: > https://docs.npmjs.com/getting-started/scoped-packages > > Should we be @cordova/plugin-device instead of cordova-plugin-device? > > -Michal >
RE: Cleaning up Jira?
Should we close resolved bugs such as https://issues.apache.org/jira/browse/CB-3452 after a week or so? People seem to report the bugs and don't reply back. If they decide to revisit after a long period we can re-open bugs. -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Wednesday, April 15, 2015 9:51 AM To: dev@cordova.apache.org Subject: Re: Cleaning up Jira? Depends on the platform. I'd say to delete the Android ones since I just fixed it and tested it, but keep the one where I talk about refactoring it to clean up the nasty nested threading thing that's going on here. (It's bad, I had to do bad, bad things to get that to work again.) Also, any time Cordova gets killed due to the camera using too much memory on Android, mark that as Won't Fix. It's the nature of Intents on earlier versions of Android, and I haven't seen it happen on 4.4 or 5.x yet. That said, I have to try and get some super low-end 5.x devices. (I'm looking at you Moto E) On Wed, Apr 15, 2015 at 9:48 AM Murat Sutunc wrote: > Hey, > I was looking at the camera bugs (201 of them atm!) and some of them > look pretty stale. Is it ok to close the bugs that no longer repro on > the latest version of platform/plugin? Or close bugs which are > resolved as can't repro? I think it would be much better to have few > but actionable bugs than 10s of stale ones :) Thoughts?? > > Thanks, > Murat >
Cleaning up Jira?
Hey, I was looking at the camera bugs (201 of them atm!) and some of them look pretty stale. Is it ok to close the bugs that no longer repro on the latest version of platform/plugin? Or close bugs which are resolved as can't repro? I think it would be much better to have few but actionable bugs than 10s of stale ones :) Thoughts?? Thanks, Murat
RE: Tools for Cordova Commits Presentation Slides
Looks pretty good to me! -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Monday, April 13, 2015 1:14 PM To: dev Subject: Tools for Cordova Commits Presentation Slides Created the slides to be readable without me talking over them in hopes to be a form of documentation for the project :) Mainly: - how to use some of coho, - how to do a pull request - picture guides to visual debugging for node, android, ios http://goo.gl/ciGnaR
Plugin-doc standards
Hey folks, I've forgot to mention this on the hangout today but I was thinking maybe we can have some guidelines on how we write plugin docs. Below is a modified version of doc that I've made (mostly borrowed from globalization plugin). https://github.com/muratsu/cordova-doc Should we apply this style to all of the docs? What are your thoughts? Sample: # plugin-name Some description ## Installation Steps ## API - API - Methods - Class: And others ## plugin-name.firstMethod Method params and short description Description Detailed explanation Supported Platforms Pass/Fail for platforms Example Small example how to use Plat1 Quirks Quirk list Plat2 Quirks ... Thanks, Murat
Re: Wiki access request
My wiki username is "MuratSutunc". Thanks for helping out. On 3/23/15, 11:36 AM, "Shazron" wrote: >Hmm I seem to be locked out of the wiki. In case I get it back or some >other admin can, what is your exact wiki user name? >(we just update a wiki page and put a username in it) > >On Mon, Mar 23, 2015 at 9:42 AM, Murat Sutunc wrote: >> I would like to add some documentation about the jshint rules at >> http://wiki.apache.org/cordova/IssueWorkflow. If someone can grant me access >> I would appreciate it. The page is immutable for me now. >> >> Thanks, >> Murat >> > >- >To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >For additional commands, e-mail: dev-h...@cordova.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Wiki access request
I would like to add some documentation about the jshint rules at http://wiki.apache.org/cordova/IssueWorkflow. If someone can grant me access I would appreciate it. The page is immutable for me now. Thanks, Murat
Wiki access request
I would like to add some documentation about the jshint rules at http://wiki.apache.org/cordova/IssueWorkflow. If someone can grant me access I would appreciate it. Thanks, Murat
cordova-plugin-camera hi-pri bugfix
Hey everyone, A hi-pri camera issue for iOS has been fixed today: Jira: https://issues.apache.org/jira/browse/CB-8599 PR: https://github.com/apache/cordova-plugin-camera/commit/bca73e6ee95c005dea59f6f05ff0b3f50917de33 Once `navigator.camera.getPicture` was called iPhone wasn't displaying anything whereas Camera view is expected. I would like to suggest we make a vote to rev the plugin. Thoughts? Thanks, Murat
RE: jquery plugins move to npm
Seems like it. According to their docs (http://blog.jquery.com/2013/01/16/announcing-the-jquery-plugin-registry/) the only way to install plugins was to download from the website. -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Wednesday, February 18, 2015 1:56 PM To: dev Subject: Re: jquery plugins move to npm Indeed. May be worth discussing how they are doing a migration (Anyone have a contact at jQuery foundation?), though I believe their registry only supported manual downloads and they didn't have a cli tool or dependencies to worry about (am I right?). -Michal On Wed, Feb 18, 2015 at 3:40 PM, Murat Sutunc wrote: > Oh wow, this is big news. I would have expected them to move to bower > but npm works just fine. > > -Original Message- > From: Steven Gill [mailto:stevengil...@gmail.com] > Sent: Wednesday, February 18, 2015 12:14 PM > To: dev@cordova.apache.org > Subject: jquery plugins move to npm > > Relevant to us! > > http://blog.npmjs.org/post/111385956875/welcome-jquery-developers > http://plugins.jquery.com/ > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
RE: jquery plugins move to npm
Oh wow, this is big news. I would have expected them to move to bower but npm works just fine. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, February 18, 2015 12:14 PM To: dev@cordova.apache.org Subject: jquery plugins move to npm Relevant to us! http://blog.npmjs.org/post/111385956875/welcome-jquery-developers http://plugins.jquery.com/ - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Adding unit tests to travis for Android/iOS
Looks like some code in Android was checked-in without running jshint :) Please, please, please run tests locally (in case you have to checkin really fast) or just make a PR and let travis do the job. Once master is failing, all the PRs made against master fail too and it makes CR really hard. PR-fix: https://github.com/apache/cordova-android/pull/157 -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Friday, February 13, 2015 5:07 PM To: dev@cordova.apache.org Subject: Re: Adding unit tests to travis for Android/iOS Fair enough. That said, this feels like we're trying to avoid testing. On Fri, 13 Feb 2015 5:01 pm Andrew Grieve wrote: > True. You can also use bin/create --link to avoid CLI though > > On Fri, Feb 13, 2015 at 5:41 PM, Joe Bowser wrote: > > > Right, but then I have to rely on the CLI to work. That means if > > there's something wrong with the CLI, I'm blocked because I'm stuck > > being yet another cook on something that has too many cooks. > > > > On Thu Feb 12 2015 at 6:04:55 PM Andrew Grieve > > > > wrote: > > > > > Woo! All sounds great! Paramedic sounds awesome for sure. > > > Basically > > moving > > > from buildbot to travis/appveyor, and isolating plugins, sounds > > > like > win! > > > > > > Joe - FYI, if you use cordova-lib@master, you can "cordova > > > platform > add > > > android --link", and then you don't need to copy changes back > > > (plugin > add > > > --link works as well for plugin .java code) > > > > > > On Thu, Feb 12, 2015 at 8:12 PM, Murat Sutunc > > > > > > wrote: > > > > > > > Thanks for updating the unit tests Shazron! > > > > > > > > I've added an extra commit to the jshint PR for travis to > > > > install > > ios-sim > > > > & ios-deploy. The failing test in question should be passing > > > > now but > > I'm > > > > waiting on travis to pick up the latest commit just to be safe: > > > > https://github.com/apache/cordova-ios/pull/129 > > > > > > > > -Original Message- > > > > From: Jesse [mailto:purplecabb...@gmail.com] > > > > Sent: Thursday, February 12, 2015 5:05 PM > > > > To: dev@cordova.apache.org > > > > Subject: Re: Adding unit tests to travis for Android/iOS > > > > > > > > Okay, back to your original thread ... > > > > What platforms have failing tests, and where are they? > > > > > > > > And I am +1 on a) b) and c) but to my knowledge, we should > > > > already be doing this. > > > > > > > > > > > > > > > > > > > > @purplecabbage > > > > risingj.com > > > > > > > > On Thu, Feb 12, 2015 at 4:54 PM, Shazron wrote: > > > > > > > > > cordova-ios' travis integration runs project creation tests as > > > > > well > > as > > > > > the Objective-C unit tests. So far I've been updating the unit > tests > > > > > if there is a change in any platform code that can be unit tested. > > > > > > > > > > Right now iOS is failing on Travis because ios-sim is not > > > > > found (although this should be better when ios-sim 4.0 is > > > > > released) > because > > > > > of this test: > > > > > > > https://github.com/apache/cordova-ios/blob/master/tests/spec/create. > > sp > > > > > ec.js#L108-L120 > > > > > > > > > > On Thu, Feb 12, 2015 at 4:39 PM, Murat Sutunc < > mura...@microsoft.com > > > > > > > > wrote: > > > > > > Before moving on to plugins, I would like to get full > > > > > > consensus > on > > > > > > CI > > > > > unit-tests for android & ios. If we all agree on it, let's > > > > > create > > JIRA > > > > > items and start working on it. > > > > > > > > > > > > For plugin testing we can create a separate thread and > > > > > > discuss in more > > > > > detail. There has been a lot of work going on with medic. > > > > > Instead > of > > > > > introducing another test tool perhaps we can improve on > > > > > existing > code > > > > > and make it more configurable/modular. > > &g
RE: Adding unit tests to travis for Android/iOS
Thanks for updating the unit tests Shazron!
I've added an extra commit to the jshint PR for travis to install ios-sim &
ios-deploy. The failing test in question should be passing now but I'm waiting
on travis to pick up the latest commit just to be safe:
https://github.com/apache/cordova-ios/pull/129
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Thursday, February 12, 2015 5:05 PM
To: dev@cordova.apache.org
Subject: Re: Adding unit tests to travis for Android/iOS
Okay, back to your original thread ...
What platforms have failing tests, and where are they?
And I am +1 on a) b) and c) but to my knowledge, we should already be doing
this.
@purplecabbage
risingj.com
On Thu, Feb 12, 2015 at 4:54 PM, Shazron wrote:
> cordova-ios' travis integration runs project creation tests as well as
> the Objective-C unit tests. So far I've been updating the unit tests
> if there is a change in any platform code that can be unit tested.
>
> Right now iOS is failing on Travis because ios-sim is not found
> (although this should be better when ios-sim 4.0 is released) because
> of this test:
> https://github.com/apache/cordova-ios/blob/master/tests/spec/create.sp
> ec.js#L108-L120
>
> On Thu, Feb 12, 2015 at 4:39 PM, Murat Sutunc
> wrote:
> > Before moving on to plugins, I would like to get full consensus on
> > CI
> unit-tests for android & ios. If we all agree on it, let's create JIRA
> items and start working on it.
> >
> > For plugin testing we can create a separate thread and discuss in
> > more
> detail. There has been a lot of work going on with medic. Instead of
> introducing another test tool perhaps we can improve on existing code
> and make it more configurable/modular.
> >
> > -Original Message-
> > From: Shazron [mailto:shaz...@gmail.com]
> > Sent: Thursday, February 12, 2015 4:23 PM
> > To: dev@cordova.apache.org
> > Subject: Re: Adding unit tests to travis for Android/iOS
> >
> > I've been trying out cordova-paramedic, and it's great. Being able
> > to
> quickly run the tests for a plugin (to test pull requests) is a big
> time saver vs having to run createmobilespec, and if we get the
> travis/appveyor integration this will be even more seamless
> >
> > On Thu, Feb 12, 2015 at 1:57 PM, Jesse wrote:
> >> Currently cordova-ios, cordova-android, cordova-windows,
> >> cordova-wp8 all have travis||appveyor integration in their github mirrors.
> >>
> >> These tests should definitely be extended to include much much more.
> >> For the most part they are currently just testing project creation,
> >> but ios and android can run on travisCI emulators so we can include
> >> runtime platform tests also.
> >>
> >> On a similar note, I have been working on plugin tests via what I
> >> have been calling cordova-paramedic [1]
> >>
> >> Essentially cordova-paramedic takes a platform and a plugin,
> >> creates the project, installs the plugin, installs the plugin
> >> tests, installs cordova-plugin-test-framework and runs the tests.
> >> There is also a local server started, and the medic.json file
> >> points back to it, so the command line running the tests via the emulator
> >> can see the results.
> >>
> >> I have this working for the device && file plugins on ios[2] via my
> >> own forks. We are going to need INFRA to setup the github
> >> appveyor+travis integration for EVERY core plugin. I will be
> >> appveyor+writing
> >> considerably more about this in the next couple weeks, I am
> >> currently working through some issues with wp8 emulator (a vm)
> >> being run on a vm in appveyor land, as the emulator and servers are
> >> on different virtual
> networks.
> >>
> >>
> >> [1] ... provides advanced levels of care at the point of illness or
> >> injury https://github.com/purplecabbage/cordova-paramedic
> >>
> >> [2]
> >> https://travis-ci.org/purplecabbage/cordova-plugin-device/builds/48
> >> 971
> >> 021
> >> {
> >>"mobilespec":{
> >> "specs":8,
> >> "failures":0,
> >> "results":[
> >>
> >> ]
> >>},
> >>"platform":"ios",
> >>"version":"8.1",
> >>"timestamp":1422667864,
> >>"model":"x86_64"
> >> }
> >> Results:: ran 8 specs with 0 fail
RE: Adding unit tests to travis for Android/iOS
Before moving on to plugins, I would like to get full consensus on CI
unit-tests for android & ios. If we all agree on it, let's create JIRA items
and start working on it.
For plugin testing we can create a separate thread and discuss in more detail.
There has been a lot of work going on with medic. Instead of introducing
another test tool perhaps we can improve on existing code and make it more
configurable/modular.
-Original Message-
From: Shazron [mailto:shaz...@gmail.com]
Sent: Thursday, February 12, 2015 4:23 PM
To: dev@cordova.apache.org
Subject: Re: Adding unit tests to travis for Android/iOS
I've been trying out cordova-paramedic, and it's great. Being able to quickly
run the tests for a plugin (to test pull requests) is a big time saver vs
having to run createmobilespec, and if we get the travis/appveyor integration
this will be even more seamless
On Thu, Feb 12, 2015 at 1:57 PM, Jesse wrote:
> Currently cordova-ios, cordova-android, cordova-windows, cordova-wp8
> all have travis||appveyor integration in their github mirrors.
>
> These tests should definitely be extended to include much much more.
> For the most part they are currently just testing project creation,
> but ios and android can run on travisCI emulators so we can include
> runtime platform tests also.
>
> On a similar note, I have been working on plugin tests via what I have
> been calling cordova-paramedic [1]
>
> Essentially cordova-paramedic takes a platform and a plugin, creates
> the project, installs the plugin, installs the plugin tests, installs
> cordova-plugin-test-framework and runs the tests. There is also a
> local server started, and the medic.json file points back to it, so
> the command line running the tests via the emulator can see the results.
>
> I have this working for the device && file plugins on ios[2] via my
> own forks. We are going to need INFRA to setup the github
> appveyor+travis integration for EVERY core plugin. I will be writing
> considerably more about this in the next couple weeks, I am currently
> working through some issues with wp8 emulator (a vm) being run on a vm
> in appveyor land, as the emulator and servers are on different virtual
> networks.
>
>
> [1] ... provides advanced levels of care at the point of illness or
> injury https://github.com/purplecabbage/cordova-paramedic
>
> [2]
> https://travis-ci.org/purplecabbage/cordova-plugin-device/builds/48971
> 021
> {
>"mobilespec":{
> "specs":8,
> "failures":0,
> "results":[
>
> ]
>},
>"platform":"ios",
>"version":"8.1",
>"timestamp":1422667864,
>"model":"x86_64"
> }
> Results:: ran 8 specs with 0 failures
>
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Thu, Feb 12, 2015 at 1:34 PM, Joe Bowser wrote:
>
>> +1. I know Travis has JUnit integration and thanks to Android
>> +Studio, the
>> only easy way to debug Cordova without copying and pasting code out
>> of a generated project is to open the test project. There should be
>> no excuse to not write tests since it's harder/more annoying to use
>> the CLI when working on platforms, since you need to make sure you
>> copy everything you changed.
>>
>> On Thu, Feb 12, 2015, 1:22 PM Murat Sutunc wrote:
>>
>> > There has been a lot of discussion about tests lately and I feel
>> > the urge to jump in and make some suggestions regarding the way we test
>> > things.
>> I'm
>> > still fairly new in the community and sometimes don't have the
>> > whole background story, so please if I'm missing something let me know.
>> >
>> > Currently we have bunch of platforms with failing tests. I'm
>> > assuming that, when these tests were first added, they were all
>> > passing. My theory is that over time platforms moved forward but
>> > tests remain stagnant and
>> now
>> > bunch of them are failing. I think we should consider running these
>> > tests automatically to ensure:
>> >
>> > a) We keep maintaining unit-tests tests regularly
>> >
>> > b) We run all unit tests before checking in code
>> >
>> > c) Reduce the friction for new developers
>> > For unit tests, I think it's a good idea to integrate them into CI
>> builds.
>> > This will probably add some extra time on travis/appveyor but it
>> shouldn't
>> > take more than 1hr. I think it's a fair trade off to wait some more
Adding unit tests to travis for Android/iOS
There has been a lot of discussion about tests lately and I feel the urge to jump in and make some suggestions regarding the way we test things. I'm still fairly new in the community and sometimes don't have the whole background story, so please if I'm missing something let me know. Currently we have bunch of platforms with failing tests. I'm assuming that, when these tests were first added, they were all passing. My theory is that over time platforms moved forward but tests remain stagnant and now bunch of them are failing. I think we should consider running these tests automatically to ensure: a) We keep maintaining unit-tests tests regularly b) We run all unit tests before checking in code c) Reduce the friction for new developers For unit tests, I think it's a good idea to integrate them into CI builds. This will probably add some extra time on travis/appveyor but it shouldn't take more than 1hr. I think it's a fair trade off to wait some more and have an overall more stable Cordova. We can always skip the CI build step if it's an urgent fix (security, critical bug, etc). I've checked travis and both iOS and Android configs come with SDK tools preinstalled, so there are no blockers to going forward with this. Thoughts?
RE: Closing jira items
Thanks, Jesse! -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, February 11, 2015 2:06 PM To: dev@cordova.apache.org Subject: Re: Closing jira items Done, and done'r @purplecabbage risingj.com On Wed, Feb 11, 2015 at 12:13 PM, Murat Sutunc wrote: > Hey everyone, > Can someone give me access to close the following jiras? > https://issues.apache.org/jira/browse/CB-8412 > https://issues.apache.org/jira/browse/CB-8410 > https://issues.apache.org/jira/browse/CB-8400 > https://issues.apache.org/jira/browse/CB-8168 > > Thanks, > Murat >
Closing jira items
Hey everyone, Can someone give me access to close the following jiras? https://issues.apache.org/jira/browse/CB-8412 https://issues.apache.org/jira/browse/CB-8410 https://issues.apache.org/jira/browse/CB-8400 https://issues.apache.org/jira/browse/CB-8168 Thanks, Murat
RE: Android JUnit Tests Now Pass
This is great news! I've finally got the android travis enabled too. We have jshint and jasmine test coverage on every commit now. (https://travis-ci.org/apache/cordova-android/builds/50295748) Now that we're passing all junit tests, I think the next step for us should be to integrate junit tests with travis. What do you think? -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, February 10, 2015 7:14 PM To: dev Subject: Android JUnit Tests Now Pass Spent some time cleaning up the tests. Certainly they could be made even better & made to test more things, but at least they pass now :) Much of the change was deleting copy & paste, and deleting commented out tests: 53 files changed, 941 insertions(+), 2610 deletions(-) - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [DISCUSS] cordova-ios 3.8.0 release
Before migration there were a lot of nodejs dependencies already: Depends on nodejs : install-device, install-emulator, list-emulator-images, emulate, run, update Doesn’t depend on nodejs: list-devices, list-started-emulators, start-emulator, build, clean, log, create I believe create and build are the important ones here. To better understand the problem, what are the key scenarios for non-nodejs users? Is it just for builders? -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Wednesday, February 4, 2015 12:19 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] cordova-ios 3.8.0 release Normally I would say yes, except for this change: http://issues.apache.org/jira/browse/CB-8197 where all the bash scripts have been converted to nodejs. One could say that for CLI users, this is no big deal, but for users using bin/create this creates a dependency on nodejs now (although this is not new, there were partial changes to require nodejs in the the previous releases). On Wed, Feb 4, 2015 at 7:30 AM, Ian Clelland wrote: > +1 for a new release to fix these. > > Question: Should a no-new-features-bug-fix-only release be 3.7.1, > rather than 3.8.0? > > On Tue Feb 03 2015 at 9:20:53 PM Andrew Grieve wrote: > >> I know you've been single-handing iOS lately, so thanks for your hard >> work Shaz! >> >> Your list sounds well thought-out, and I've not got anything to add >> other than +1! >> >> On Tue, Feb 3, 2015 at 8:42 PM, Shazron wrote: >> >> > Bug fix release. >> > >> > The two major fixes that are already in are: >> > >> > 1. https://issues.apache.org/jira/browse/CB-8002 >> > 2.https://issues.apache.org/jira/browse/CB-8036 >> > >> > Others are here (post Oct 30th 2014): >> > https://github.com/apache/cordova-ios/commits/master >> > I've triaged all the iOS issues in JIRA, nothing else seemed critical. >> > >> > I'm looking at these other small issues that I can add in also if >> possible: >> > >> > https://issues.apache.org/jira/browse/CB-7606 (I caused this, >> > probably) >> > https://issues.apache.org/jira/browse/CB-8028 (I caused this, >> > probably) >> > https://issues.apache.org/jira/browse/CB-8336 (quick fix) >> > https://issues.apache.org/jira/browse/CB-8254 (quick fix) >> > >> > Any other issues that need to get in for the release? >> > (no new features - new features should eventually go in the 4.0.0 >> > branch) >> > >> > --- >> > -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > For additional commands, e-mail: dev-h...@cordova.apache.org >> > >> > >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Travis config for cordova-android
Hi, Does anyone know what's required to make travis pick up PRs from cordova-android master branch? The travis.yml file seems to be in place but looks like it's currently not in use. It would like to fix this. Thanks, Murat
RE: Found a regression in cordova-android@3.7.0
Looks like this fix broke `cordova build` for windows: :CordovaLib:compileDebugJava C:\dev\test\platforms\android\CordovaLib\src\org\apache\cordova\CordovaActivity.java:151: error: method init in interface CordovaWebView cannot be applied to given types; appView.init(this, pluginEntries, internalWhitelist, externalWhitelist, preferences); ^ required: CordovaInterface,List,Whitelist,Whitelist,CordovaPreferences found: CordovaActivity,ArrayList,Whitelist,Whitelist,CordovaPreferences reason: actual argument CordovaActivity cannot be converted to CordovaInterface by method invocation conversion C:\dev\test\platforms\android\CordovaLib\src\org\apache\cordova\CordovaActivity.java:217: error: cannot find symbol return ret; ^ symbol: variable ret location: class CordovaActivity Note: Some input files use or override a deprecated API. Note: Recompile with -Xlint:deprecation for details. 2 errors :CordovaLib:compileDebugJava FAILED FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':CordovaLib:compileDebugJava'. > Compilation failed; see the compiler error output for details. > > * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 3.117 secs
RE: [GitHub] cordova-coho pull request: CB-8375 Improve windows support for for...
Can someone take a look at this PR? Thanks, Murat -Original Message- From: muratsu [mailto:g...@git.apache.org] Sent: Wednesday, January 28, 2015 3:57 PM To: dev@cordova.apache.org Subject: [GitHub] cordova-coho pull request: CB-8375 Improve windows support for for... GitHub user muratsu opened a pull request: https://github.com/apache/cordova-coho/pull/62 CB-8375 Improve windows support for for-each This improvement makes coho for-each work on Windows without issues. You can merge this pull request into a Git repository by running: $ git pull https://github.com/MSOpenTech/cordova-coho CB-8375 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cordova-coho/pull/62.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #62 commit d1d8d687430292afd85e79a584f618cd28e265a8 Author: Murat Sutunc Date: 2015-01-28T23:56:09Z CB-8375 Improve windows support for for-each --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Usage of jscs & JSHint in Cordova
Now that cordova-lib is done, I'm considering extending the jshint support to individual platforms. Any concerns or thoughts? > On Jan 21, 2015, at 5:23 PM, Mark Koudritsky wrote: > >> On Wed, Jan 21, 2015 at 5:47 PM, Murat Sutunc wrote: >> >> I can take a look at applying current rules in all subfolders soon if time >> constraints were the reason. > Will be greatly appreciated. Though I would advise to start from something > other than then specs folder for your own sanity :) > > >> I suspected that real time jshinting was the reason for having jshint >> rules in individual files but by doing so we lose track of un-hinted files >> and hint standardization. It would be nice to have a standard set of rules >> for the folder/project and have exception rules in individual files. If >> spec-cordova, spec-plugman and src should all have one base ruleset than it >> makes sense to put that base rule in package.json, otherwise we can have >> different base rules with jshintrc files at folder roots. >> >> When invoked from cli `jshint filename` will walk all the way up to the >> filesystem root until it finds a config file (unless you set configurations >> differently). Given that it's incredibly hard to get consensus on different >> IDE preferences, I would shy away from any IDE specific benefits/problems. > > +1 > > > -Original Message- >> From: Mark Koudritsky [mailto:kam...@google.com] >> Sent: Wednesday, January 21, 2015 1:01 PM >> To: dev@cordova.apache.org >> Subject: Re: Usage of jscs & JSHint in Cordova >> >> I added he jscs file in cordova-lib some time ago but didn't enforce it in >> npm test because that required more work in the code to get rid of the >> remaining style errors. Would be glad if someone invests the effort to make >> the code comply with the current (or modified) rules. >> >> Similar story for the spec files, they were excluded from the JShint check >> because we didn't have the time/motivation to make them compliant with any >> reasonable jshint settings. >> >> I don't have a strong opinion about what is better for jshint, a config >> file or individual config lines in js files. One benefit of config comments >> is that it works in editors that do real time jshinting, but ignore the >> config files in parent dirs (I think Brackets jshint plugin was doing this >> some time ago). >> >> I'm not sure if it's worth it moving the config file(s) up the dir, they >> probably should live as siblings of the package.json >> >> >> On Wed, Jan 21, 2015 at 3:16 PM, Murat Sutunc >> wrote: >> >>> Hi, >>> I was curious about the jscs and jshint usage in cordova repos. Seems >>> like in cordova-lib we currently have: >>> >>> - jscs rules in cordova-lib\cordova-lib >>> >>> - individual jshint rules on some js files under >>> cordova-lib\cordova-lib >>> >>> - >>> While jscs rules are set, it's currently not plugged into `npm test`. >>> Do we have a policy in place to enforce these rules? If so I should >>> add it to packages.json or just remove the config file. >>> >>> Regarding individual jshint rules on files, should we migrate to >>> having one .jshintrc file on the base folder (and exclude >>> node_modules). We can then add individual flags on files if they are >>> necessary to do so and catch any potentially non-hinted files (ex. >>> many files are non-hinted >>> spec-cordova\*) According to CB-6973 the following jshint config can >>> be the master rule: >>> /* jshint node:true, bitwise:true, undef:true, trailing:true, >>> quotmark:true, indent:4, unused:vars, latedef:nofunc */ >>> >>> Any thoughts? >>> >>> Thanks, >>> Murat >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: [DISCUSS] Cordova-Android 4.0.0 Release
Just give some data point, running mobile spec I'm getting:
- 11 failures in 4.4.2
- 6 failures in 4.0.4
Ideally we should bring those numbers to 0 to ensure a stable release.
-Original Message-
From: Joe Bowser [mailto:bows...@gmail.com]
Sent: Wednesday, January 28, 2015 10:45 AM
To: dev@cordova.apache.org
Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release
On Wed Jan 28 2015 at 10:38:07 AM Andrew Grieve
wrote:
>
> - Make CordovaActivity not implement CordovaInterface, but instead
> provide CordovaInterface via an inner class (to solidify that you
> can't cast the activity to CordovaInterface and expect that to work -
> some used to do this but I think we've cleaned it all up now)
>
> This literally came out of nowhere. Why are you trying so hard to
> remove
the embedded view use case? What if someone is implementing an activity that
inherits from another activity like MapActivity? This API change came without
any discussion.
All of this can be done in a few days, but I'd also like to see the dust
> settle a bit before going forward with 4.0.0 release. E.g. At least
> wait until we do a blog post for 3.7.0 (are you doing this?), and have
> done a tools release that updates the pinned version to 3.7.0
>
>
If someone else wants to do the blog post on that, that's fine. And I agree
that there should be a tools release with 3.7.0 pinned, even though
3.7.0 is really just a technicality so we can get 4.0.0 out IMO.
>
> On Wed, Jan 28, 2015 at 12:52 PM, Joe Bowser wrote:
>
> > Reminder: failures with plugins are not blockers. I've run into
> > that contact issue numerous times when testing with my personal
> > device. I recommend making sure that your contacts are completely
> > clean so that you don't get these weird results.
> >
> > The file failures have been happening for quite a while, and those
> > are
> not
> > blockers for the platform release either. Do these failures happen
> > on a platform other than ICS?
> >
> > On Wed, Jan 28, 2015, 9:06 AM Murat Sutunc
> wrote:
> >
> > > I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and
> > > there
> are
> > > some failures. I’ve searched the jira for issues but wasn’t able
> > > to
> find
> > > any. Has anyone else ran into these issues before?
> > >
> > > org.apache.cordova.contacts.tests.tests >> Contacts
> (navigator.contacts)
> > > Round trip Contact tests (creating + save + delete + find).
> > > Contacts.spec.24 Creating, saving, finding a contact should work,
> > > after which we should not be able to find it, and we should not be
> > > able to
> > delete
> > > it again.
> > > • Expected 2 to be 1
> > > • Expected 1 to be 0
> > > it("contacts.spec.24 Creating, saving, finding a contact
> should
> > > work, removing it should work, after which we should not be able
> > > to
> find
> > > it, and we should not be able to delete it again.", function (done) {
> > > // Save method is not supported on Windows platform
> > > if (isWindows) {
> > > pending();
> > > return;
> > > }
> > > if (isWindowsPhone8) {
> > > done();
> > > return;
> > > }
> > > gContactObj = new Contact();
> > > gContactObj.name = new ContactName();
> > > gContactObj.name.familyName = "DeleteMe";
> > > gContactObj.save(function(c_obj) {
> > > var findWin = function(cs) {
> > > expect(cs.length).toBe(1);
> > > // update to have proper saved id
> > > gContactObj = cs[0];
> > > gContactObj.remove(function() {
> > > var findWinAgain = function(seas) {
> > > expect(seas.length).toBe(0);
> > > gContactObj.remove(function() {
> > > throw("success callback called
> > > after non-existent Contact object called remove(). Test failed.");
> > > }, function(e) {
> > > expect(e.code).toBe(ContactErr
> > > or.UNKNOWN_ERROR);
> > > done();
> > >
RE: [DISCUSS] Cordova-Android 4.0.0 Release
I’ve ran the mobile-spec tests on android 4.0.3 with 4.0.x and there are some
failures. I’ve searched the jira for issues but wasn’t able to find any. Has
anyone else ran into these issues before?
org.apache.cordova.contacts.tests.tests >> Contacts (navigator.contacts) Round
trip Contact tests (creating + save + delete + find). Contacts.spec.24
Creating, saving, finding a contact should work, after which we should not be
able to find it, and we should not be able to delete it again.
• Expected 2 to be 1
• Expected 1 to be 0
it("contacts.spec.24 Creating, saving, finding a contact should work,
removing it should work, after which we should not be able to find it, and we
should not be able to delete it again.", function (done) {
// Save method is not supported on Windows platform
if (isWindows) {
pending();
return;
}
if (isWindowsPhone8) {
done();
return;
}
gContactObj = new Contact();
gContactObj.name = new ContactName();
gContactObj.name.familyName = "DeleteMe";
gContactObj.save(function(c_obj) {
var findWin = function(cs) {
expect(cs.length).toBe(1);
// update to have proper saved id
gContactObj = cs[0];
gContactObj.remove(function() {
var findWinAgain = function(seas) {
expect(seas.length).toBe(0);
gContactObj.remove(function() {
throw("success callback called after
non-existent Contact object called remove(). Test failed.");
}, function(e) {
expect(e.code).toBe(ContactError.UNKNOWN_ERROR);
done();
});
};
var findFailAgain = function(e) {
throw("find error callback invoked after delete,
test failed.");
};
var obj = new ContactFindOptions();
obj.filter="DeleteMe";
obj.multiple=true;
navigator.contacts.find(["displayName", "name",
"phoneNumbers", "emails"], findWinAgain, findFailAgain, obj);
}, function(e) {
throw("Newly created contact's remove function
invoked error callback. Test failed.");
});
};
var findFail = fail;
var obj = new ContactFindOptions();
obj.filter="DeleteMe";
obj.multiple=true;
navigator.contacts.find(["displayName", "name",
"phoneNumbers", "emails"], findWin, findFail, obj);
}, fail);
});
org.apache.cordova.file.tests.test >> file api filereader file.spec.81
(couldn’t find a JIRA issue)
• Expected `` to be null
describe('FileReader', function () {
it("file.spec.81 should have correct methods", function () {
var reader = new FileReader();
expect(reader).toBeDefined();
expect(typeof reader.readAsBinaryString).toBe('function');
expect(typeof reader.readAsDataURL).toBe('function');
expect(typeof reader.readAsText).toBe('function');
expect(typeof reader.readAsArrayBuffer).toBe('function');
expect(typeof reader.abort).toBe('function');
test below fails
'' !== null
expect(reader.result).toBe(null);
});
});
org.apache.cordova.file.tests.tests >> file api parent references file.spec.111
(couldn’t find a fire issue):
• root.getFile succeeds, it is expected to fail.
var fileName = "traverse.file.uri";
// create a new file entry
createFile(fileName, function (entry) {
// lookup file system entry
root.getFile('../' + fileName, {
create : false
}, succeed.bind(null, done, "root.getFile('../"+fileName+
"')- Unexpected success callback, it should not traverse abvoe the root
directory"),
function (error) { //.
org.apache.cordova.file-transfer.tests.tests >> FileTransfer methods download
filetransfer.spec.6 should get 401 status on http basic auth failure
• Expected null to be 401
it('filetransfer.spec.6 should get 401 status on http basic
auth failure', function (done) {
// NOTE:
// using server without credentials
var fil
Re: File Transfer plugin and Crosswalk engine cookies
What exactly would this flag do underneath? I suppose it will add the crosswalk plugin and run it's tests. Am I missing anything else? > On Jan 27, 2015, at 12:29 PM, Jesse wrote: > > If you know there will be more, wouldn't it be simpler to just do something > like : > --webview=crosswalk // ? > > Just a small thing. > > @purplecabbage > risingj.com > > On Tue, Jan 27, 2015 at 12:23 PM, Andrew Grieve > wrote: > >> I think that would be manageable. Especially since right now there is only >> 1. >> >>> On Tue, Jan 27, 2015 at 2:16 PM, Joe Bowser wrote: >>> >>> I don't know if we want to do that, then we'd have to create flags for >>> every potential third party webview. >>> >>> On Tue Jan 27 2015 at 7:03:28 AM Andrew Grieve >>> wrote: >>> Sounds good. We should add a --crosswalk flag to createmobilespec.sh :) > On Tue, Jan 27, 2015 at 2:07 AM, Hu, Ningxin wrote: > Hi Joe, > >> >> Crosswalk has its own release schedule, so it should have its own >>> test > project >> somewhere that tests the interfaces that it implements. Of course, this >> would be similar to the ones that we still need to write for the >> AndroidWebView. That said, I think for now we should proceed with >>> the >> current tests and write the tests for 4.1.x >> >> This means that even if Crosswalk doesn't pass the JUnit tests, it still > won't >> hold up the Cordova 4.0 release, because it's Crosswalk failing the > tests, not >> Cordova itself. Being independent and interoperable is good, >> since I >> anticipate Crosswalk to release much more quickly than Cordova. > > It makes sense. > > From crosswalk-engine testing perspective, let's: > 1. focus on mobile-spec integration test for Cordova 4.0 release > 2. maintain the JUnit test project independently and align with 4.1.x > development > > Please let us know if there are anything missed. > > Thanks, > -ningxin > >> >>> On Mon Jan 26 2015 at 10:14:11 PM Fu, Junwei >> wrote: >> >>> Crosswalk engine have been tested with mobile-spec and owned >>> functionality test, but there are no JUnit test for Crosswalk >>> engine, >>> and the JUnit test in cordova-anroid 4.0 were being re-wrote. >> Does the >>> Crosswalk engine need pass JUnit test before voting on releases? >>> What's plan about making JUnit test cases to test pluggable >>> webView. >>> >>> Thanks, >>> Junwei. >>> >>> -Original Message- >>> From: Joe Bowser [mailto:bows...@gmail.com] >>> Sent: Tuesday, January 27, 2015 7:55 AM >>> To: dev >>> Subject: Re: File Transfer plugin and Crosswalk engine cookies >>> >>> As far as I'm aware, we're basically waiting for this to be done >>> before starting the vote thread. Does this code exist yet? >>> >>> On Tue Jan 20 2015 at 12:12:22 PM Andrew Grieve < agri...@chromium.org> >>> wrote: >>> I was planning on doing exactly what Darryl described. Would >> love such a PR! Note that we've just used this approach for the new WebView security hooks: https://github.com/apache/cordova-android/commit/ 623b394c830b8a83b5c2f16624d8013b6f851cd9 https://github.com/apache/cordova-android/commit/ 11002d4a56a4901087f514e2d01f8db392d0abe1 CookieManager has been exposed to plugins for a long time, and >> it would be crippling if FileTransfer could not set cookies. On Tue, Jan 20, 2015 at 1:48 PM, Joe Bowser >> >> wrote: > I think we should make the File Transfer plugin not need a >>> CookieManager. > It sounds like that's the bigger problem than it having to be tied > to a particular implementation of Cookies. > > On Tue Jan 20 2015 at 10:32:25 AM Darryl Pogue > > wrote: > >> With the idea of preparing Cordova Android 4.0.x for >> release >> starting to come up in discussions, I thought it was worth >> raising this as a potential blocker. >> >> The file transfer plugin uses the Android webview cookie manager. >> When you're using a Crosswalk webview (or GeckoView presumably), >> in the best case there are no cookies with file transfer >> requests and in the worst case it will cause the app to >> crash on >> Android >>> 4.2.x. >> >> There are a few existing bug reports and PRs related to >> this, >> but none of them propose a general solution for different > webviews. >> [1] [2] [3] [4] >> >> I was looking at this problem last week and the only >> general >> solution I could think of would involve adding a >>
RE: FYI: Created a plugin to help with local plugin development
I've some concerns about linking workflow in Windows.
Having admin rights in a cmd prompt is not desirable - there are many cases
where a user might not have the rights. I'm currently investigating `Junctions`
to see if it will work for this scenario. Alternatively we can do the trick
Jesse suggested earlier for Windows. I'll follow up with a PR later to enable
this for Windows devs.
-Original Message-
From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve
Sent: Monday, January 26, 2015 8:50 AM
To: Andrew Grieve
Cc: dev
Subject: Re: FYI: Created a plugin to help with local plugin development
And... now:
createmobilespec.sh --linkplatforms
and
createmobilespec.sh --link
is and alias for
createmobilespec.sh --linkplugins --linkplatforms
So, for iOS and Android, this will create a project where you can edit native
files in both plugins and platform and the changes will be reflected in
cordova-ios, cordova-android, cordova-plugin-foo* repos!
Also - looks like I had accidentally hardcoded --browserify to be on on
Thursday.
Fixed now, but if you noticed mobilespec being funny, it's because --browserify
was on.
On Thu, Jan 22, 2015 at 10:30 PM, Andrew Grieve
wrote:
> Implemented the iOS approach:
> https://issues.apache.org/jira/browse/CB-8354
>
> createmobilespec.sh --linkplugins --android --ios
>
> This lets you (after command-line building once in Android's case):
> 1. open the project in Android Studio or Xcode 2. edit plugin .java /
> .m / .h 3. see the change reflected in your local cordova-plugin-foo
> directories
>
> Also added:
>
> createmobilespec.sh --browserify
>
> which does what you think it does.
>
>
> On Mon, Jan 5, 2015 at 9:49 PM, Andrew Grieve
> wrote:
>
>> Thought about Windows, but didn't test on it. Figured since --link
>> was a hot-off-the-press flag, that if there were bugs with it we
>> could keep iterating.
>>
>> iOS approach makes sense to me. I've added it to the JIRA.
>>
>> On Mon, Jan 5, 2015 at 6:53 PM, Jesse wrote:
>>
>>> Andrew, did you test your changes in Android Studio for Windows? I
>>> am curious how well symlinks work there.
>>> Visual Studio and XCode both support adding file/folder references,
>>> which would mean that saving a changed plugin native file would save
>>> it to it's original location. This is the way I have typically developed
>>> plugins:
>>> - install once
>>> - change file paths in the IDE to point to the plugin-repo directly
>>> - debug / iterate / add functionality in the IDE
>>> - once satisfied, remove the plugin, and re-install the way a mortal
>>> user would, smoke test
>>> - publish
>>>
>>> essentially, avoiding constant re/un/installing
>>>
>>>
>>> @purplecabbage
>>> risingj.com
>>>
>>> On Mon, Jan 5, 2015 at 12:56 PM, Andrew Grieve
>>>
>>> wrote:
>>>
>>> > Along these lines, I likewise got frustrated with my workflow and
>>> added a
>>> > new feature to "cordova plugin add --link".
>>> >
>>> > Instead of just creating symlink in the plugins/ directory, it now
>>> > also creates symlinks for .java files, so that you can edit plugin
>>> > .java
>>> files
>>> > in Android Studio, and hitting save will cause the original plugin
>>> .java
>>> > file to be updated!
>>> >
>>> > Worth experimenting with for other platforms as well I think, but
>>> > this setup does require the IDE & build tools to play nicely with
>>> > symlinks (which is why I did it for Android only).
>>> >
>>> > https://issues.apache.org/jira/browse/CB-8244.
>>> >
>>> > On Mon, Dec 1, 2014 at 5:13 PM, Michal Mocny
>>> wrote:
>>> >
>>> > > Took the opportunity to use our new plugin hooks and created a
>>> plugin to
>>> > > automate a tedious task I've been doing a lot of recently:
>>> > > plugin re-installation.
>>> > >
>>> > > https://github.com/mmocny/cordova-plugin-plugin-auto-upgrade
>>> > >
>>> > > As per the README:
>>> > >
>>> > >
>>> > > This plugin with automatically upgrade (re-install) a set of
>>> > > plugins (specified by you) before every cordova prepare. This is
>>> > > useful if
>>> you
>>> > are
>>> > > doing plugin development and would like to automatically
>>> > > synchronize
>>> your
>>> > > app with any changes made to your plugin.
>>> > >
>>> > > Install the plugin: cordova plugin add
>>> > > org.apache.cordova.labs.pluginAutoUpgrade
>>> > >
>>> > > At root of your app, create a pluginAutoUpgrade.json file, which
>>> looks
>>> > > like:
>>> > >
>>> > > {
>>> > > "PLUGIN_ID": "PLUGIN_INSTALL_PATH",
>>> > > "PLUGIN_ID2": "PLUGIN_INSTALL_PATH"
>>> > > }
>>> > >
>>> > >
>>> > >
>>> > > This is useful if you are making changes to a plugin inside the
>>> plugin's
>>> > > directory structure.
>>> > >
>>> > > For more meaty plugin work, you are possibly better off making
>>> > > native changes inside platforms/ and js changes inside plugins/,
>>> > > and being
>>> very
>>> > > careful to not clobber your work (or use the build/run scr
RE: Usage of jscs & JSHint in Cordova
I can take a look at applying current rules in all subfolders soon if time constraints were the reason. I suspected that real time jshinting was the reason for having jshint rules in individual files but by doing so we lose track of un-hinted files and hint standardization. It would be nice to have a standard set of rules for the folder/project and have exception rules in individual files. If spec-cordova, spec-plugman and src should all have one base ruleset than it makes sense to put that base rule in package.json, otherwise we can have different base rules with jshintrc files at folder roots. When invoked from cli `jshint filename` will walk all the way up to the filesystem root until it finds a config file (unless you set configurations differently). Given that it's incredibly hard to get consensus on different IDE preferences, I would shy away from any IDE specific benefits/problems. -Original Message- From: Mark Koudritsky [mailto:kam...@google.com] Sent: Wednesday, January 21, 2015 1:01 PM To: dev@cordova.apache.org Subject: Re: Usage of jscs & JSHint in Cordova I added he jscs file in cordova-lib some time ago but didn't enforce it in npm test because that required more work in the code to get rid of the remaining style errors. Would be glad if someone invests the effort to make the code comply with the current (or modified) rules. Similar story for the spec files, they were excluded from the JShint check because we didn't have the time/motivation to make them compliant with any reasonable jshint settings. I don't have a strong opinion about what is better for jshint, a config file or individual config lines in js files. One benefit of config comments is that it works in editors that do real time jshinting, but ignore the config files in parent dirs (I think Brackets jshint plugin was doing this some time ago). I'm not sure if it's worth it moving the config file(s) up the dir, they probably should live as siblings of the package.json On Wed, Jan 21, 2015 at 3:16 PM, Murat Sutunc wrote: > Hi, > I was curious about the jscs and jshint usage in cordova repos. Seems > like in cordova-lib we currently have: > > - jscs rules in cordova-lib\cordova-lib > > - individual jshint rules on some js files under > cordova-lib\cordova-lib > > - > While jscs rules are set, it's currently not plugged into `npm test`. > Do we have a policy in place to enforce these rules? If so I should > add it to packages.json or just remove the config file. > > Regarding individual jshint rules on files, should we migrate to > having one .jshintrc file on the base folder (and exclude > node_modules). We can then add individual flags on files if they are > necessary to do so and catch any potentially non-hinted files (ex. > many files are non-hinted > spec-cordova\*) According to CB-6973 the following jshint config can > be the master rule: > /* jshint node:true, bitwise:true, undef:true, trailing:true, > quotmark:true, indent:4, unused:vars, latedef:nofunc */ > > Any thoughts? > > Thanks, > Murat > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Usage of jscs & JSHint in Cordova
Hi, I was curious about the jscs and jshint usage in cordova repos. Seems like in cordova-lib we currently have: - jscs rules in cordova-lib\cordova-lib - individual jshint rules on some js files under cordova-lib\cordova-lib - While jscs rules are set, it's currently not plugged into `npm test`. Do we have a policy in place to enforce these rules? If so I should add it to packages.json or just remove the config file. Regarding individual jshint rules on files, should we migrate to having one .jshintrc file on the base folder (and exclude node_modules). We can then add individual flags on files if they are necessary to do so and catch any potentially non-hinted files (ex. many files are non-hinted spec-cordova\*) According to CB-6973 the following jshint config can be the master rule: /* jshint node:true, bitwise:true, undef:true, trailing:true, quotmark:true, indent:4, unused:vars, latedef:nofunc */ Any thoughts? Thanks, Murat
Re: Cordova --list option implementation
Im actually doing git --amend now but everytime I push the history is lost due
to force push. github is not able to save/rebase previous comments. Wish there
was a better solution for this.
Sent from my iPhone
> On Jan 16, 2015, at 11:51 AM, Josh Soref wrote:
>
> You should be doing git commit --amend in general.
>
> Rebase is mostly important when someone else committed code and you want to
> have that code too. We want you to rebase your changes onto those changes.
> (It's also helpful for when you want to safely split out changes into
> distinct commits, e.g. if you need to refactor before your changes, or fix
> something that's only tangentially related, but which shouldn't be in your
> main commit.)
>
>> -Original Message-
>> From: Murat Sutunc [mailto:mura...@microsoft.com]
>> Sent: Friday, January 16, 2015 2:42 PM
>> To: dev@cordova.apache.org
>> Subject: RE: Cordova --list option implementation
>>
>> Oh.. I've addressed the issues couple times and I thought you reviewed the
>> previous changes. Didn't mean to be pushy, sorry about that.
>>
>> I have a question regarding the CR process. I've searched up the wiki but
>> couldn't find a good answer for this. When addressing issues, is it ok to
>> create
>> a quick fix commit or do we have to rebase every time?
>>
>> -Original Message-
>> From: Josh Soref [mailto:jso...@blackberry.com]
>> Sent: Friday, January 16, 2015 11:35 AM
>> To: dev@cordova.apache.org
>> Subject: RE: Cordova --list option implementation
>>
>> No. That's not really how it goes.
>>
>> And I'd like people to understand this.
>>
>> Things don't just go in the moment there aren't comments.
>> In general, we give people time to review. And sometimes someone will put
>> a +1 saying "I think it's ready".
>>
>> I'm sorry that I didn't give all my comments at once. I generally have to
>> look
>> at things repeatedly in order to work things through.
>>
>>> -Original Message-
>>> From: Murat Sutunc [mailto:mura...@microsoft.com]
>>> Sent: Friday, January 16, 2015 2:17 PM
>>> To: dev@cordova.apache.org
>>> Subject: RE: Cordova --list option implementation
>>>
>>> All issues addressed, changes can be merged now.
>>>
>>> -Original Message-
>>> From: Murat Sutunc [mailto:mura...@microsoft.com]
>>> Sent: Sunday, January 11, 2015 11:53 PM
>>> To: dev@cordova.apache.org
>>> Subject: RE: Cordova --list option implementation
>>>
>>> I've made the changes wrt what has been discussed:
>>>
>>> https://github.com/apache/cordova-cli/pull/205
>>> https://github.com/apache/cordova-lib/pull/145
>>>
>>> Thanks,
>>> Murat
>>>
>>> -Original Message-
>>> From: Josh Soref [mailto:jso...@blackberry.com]
>>> Sent: Friday, January 9, 2015 11:39 AM
>>> To: dev@cordova.apache.org
>>> Subject: Re: Cordova --list option implementation
>>>
>>> Murat Sutunc wrote:
>>>> At the very least, if you're going to do option 1.b, please make sure
>>>> that list is a function which is independently reachable via the api so
>>>> that js callers can easily get the list of devices for platform[s], and
>>>> can determine if the feature is available (by checking for the presence
>>>> of the api function).
>>>>
>>>> [MS] Can you clarify this a bit more. Do you mean like
>>>> require('./cordova').raw.list(/*args*/)
>>>
>>> Something like this, yes, but it'd need to have some indication it's about
>>> targets in the code portion (which here is just 'raw.list').
>>> B
>> KK
>>> KKCB [ X ܚX KK[XZ[
>>> ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
>>> ] Z[ ܙݘK \X K ܙ B
>> B�KKK
>>> KCB�� [��X��ܚX�KK[XZ[
>> �]�][��X��ܚX�P�ܙݘK�\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
>>>
>>> �]�Z[ �ܙݘK�\X�K�ܙ�B
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Cordova --list option implementation
Oh.. I've addressed the issues couple times and I thought you reviewed the
previous changes. Didn't mean to be pushy, sorry about that.
I have a question regarding the CR process. I've searched up the wiki but
couldn't find a good answer for this. When addressing issues, is it ok to
create a quick fix commit or do we have to rebase every time?
-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Friday, January 16, 2015 11:35 AM
To: dev@cordova.apache.org
Subject: RE: Cordova --list option implementation
No. That's not really how it goes.
And I'd like people to understand this.
Things don't just go in the moment there aren't comments.
In general, we give people time to review. And sometimes someone will put a +1
saying "I think it's ready".
I'm sorry that I didn't give all my comments at once. I generally have to look
at things repeatedly in order to work things through.
> -Original Message-
> From: Murat Sutunc [mailto:mura...@microsoft.com]
> Sent: Friday, January 16, 2015 2:17 PM
> To: dev@cordova.apache.org
> Subject: RE: Cordova --list option implementation
>
> All issues addressed, changes can be merged now.
>
> -Original Message-
> From: Murat Sutunc [mailto:mura...@microsoft.com]
> Sent: Sunday, January 11, 2015 11:53 PM
> To: dev@cordova.apache.org
> Subject: RE: Cordova --list option implementation
>
> I've made the changes wrt what has been discussed:
>
> https://github.com/apache/cordova-cli/pull/205
> https://github.com/apache/cordova-lib/pull/145
>
> Thanks,
> Murat
>
> -Original Message-
> From: Josh Soref [mailto:jso...@blackberry.com]
> Sent: Friday, January 9, 2015 11:39 AM
> To: dev@cordova.apache.org
> Subject: Re: Cordova --list option implementation
>
> Murat Sutunc wrote:
> >At the very least, if you're going to do option 1.b, please make sure
> >that list is a function which is independently reachable via the api so
> >that js callers can easily get the list of devices for platform[s], and
> >can determine if the feature is available (by checking for the presence
> >of the api function).
> >
> >[MS] Can you clarify this a bit more. Do you mean like
> >require('./cordova').raw.list(/*args*/)
>
> Something like this, yes, but it'd need to have some indication it's about
> targets in the code portion (which here is just 'raw.list').
> B
> KK
> KKCB [ X ܚX KK[XZ[
> ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
> ] Z[ ܙݘK \X K ܙ B
> B�KKK
> KCB�� [��X��ܚX�KK[XZ[
>
> �]�][��X��ܚX�P�ܙݘK�\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[
>
> �]�Z[ �ܙݘK�\X�K�ܙ�B
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Cordova --list option implementation
All issues addressed, changes can be merged now.
-Original Message-
From: Murat Sutunc [mailto:mura...@microsoft.com]
Sent: Sunday, January 11, 2015 11:53 PM
To: dev@cordova.apache.org
Subject: RE: Cordova --list option implementation
I've made the changes wrt what has been discussed:
https://github.com/apache/cordova-cli/pull/205
https://github.com/apache/cordova-lib/pull/145
Thanks,
Murat
-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Friday, January 9, 2015 11:39 AM
To: dev@cordova.apache.org
Subject: Re: Cordova --list option implementation
Murat Sutunc wrote:
>At the very least, if you're going to do option 1.b, please make sure
>that list is a function which is independently reachable via the api so
>that js callers can easily get the list of devices for platform[s], and
>can determine if the feature is available (by checking for the presence
>of the api function).
>
>[MS] Can you clarify this a bit more. Do you mean like
>require('./cordova').raw.list(/*args*/)
Something like this, yes, but it'd need to have some indication it's about
targets in the code portion (which here is just 'raw.list').
B CB [
X ܚX KK[XZ[
] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[
] Z[ ܙݘK \X K ܙ B
RE: Cordova --list option implementation
I've made the changes wrt what has been discussed:
https://github.com/apache/cordova-cli/pull/205
https://github.com/apache/cordova-lib/pull/145
Thanks,
Murat
-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Friday, January 9, 2015 11:39 AM
To: dev@cordova.apache.org
Subject: Re: Cordova --list option implementation
Murat Sutunc wrote:
>At the very least, if you're going to do option 1.b, please make sure that
>list is a function which is independently reachable via the api so that js
>callers can easily get the list of devices for platform[s], and can
>determine if the feature is available (by checking for the presence of the
>api function).
>
>[MS] Can you clarify this a bit more. Do you mean like
>require('./cordova').raw.list(/*args*/)
Something like this, yes, but it'd need to have some indication it's about
targets in the code portion (which here is just 'raw.list').
RE: Cordova --list option implementation
-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Friday, January 9, 2015 10:47 AM
To: dev@cordova.apache.org
Subject: Re: Cordova --list option implementation
Murat Sutunc wrote:
>I think we have a couple of options here:
>
>Option 1 - Adding --list as an optional parameter to cordova run
>List is related to run and there’s not that much need to introduce
>another top level command for this . Considering all the previous
>discussions we had I can see two potential implementations for this:
>A) look at the parameters of run call in platform level
>and take action
>B) look at the parameters of run call in lib level and
>take action
>Option 1.A results in errors or unexpected behavior on platforms that do
>not support --list (including older versions).
This is clearly a no-go
>Option 1.B involves parsing arguments in
>cordova-lib\cordova-lib\src\cordova\run.js (along with the cli).
This isn't my preference for where in cordova-lib the code lives
> From this point instead of calling
>project_root/platforms//cordova/run we can call
>project_root/platforms//cordova/lib/list-* and so on.
From a how the code has to work, this is how it has to work.
>Option 2 - Adding ‘list’ as an optional parameter to a new command.
>List can be put under a new top level command such as target. This design
>involves adding a new top level command and corresponding handler in
>cordova-lib. Similar to run, the code with logic will reside somewhere
>like cordova-lib\cordova-lib\src\cordova\target.js.
>
>I would like to get some feedback about these options.
I'd prefer option 2.
At the very least, if you're going to do option 1.b, please make sure that
list is a function which is independently reachable via the api so that js
callers can easily get the list of devices for platform[s], and can
determine if the feature is available (by checking for the presence of the
api function).
[MS] Can you clarify this a bit more. Do you mean like
require('./cordova').raw.list(/*args*/) or something on the platform side?
RE: Cordova --list option implementation
I think we have a couple of options here: Option 1 - Adding --list as an optional parameter to cordova run List is related to run and there’s not that much need to introduce another top level command for this . Considering all the previous discussions we had I can see two potential implementations for this: A) look at the parameters of run call in platform level and take action B) look at the parameters of run call in lib level and take action Option 1.A results in errors or unexpected behavior on platforms that do not support --list (including older versions). Option 1.B involves parsing arguments in cordova-lib\cordova-lib\src\cordova\run.js (along with the cli). From this point instead of calling project_root/platforms//cordova/run we can call project_root/platforms//cordova/lib/list-* and so on. Option 2 - Adding ‘list’ as an optional parameter to a new command. List can be put under a new top level command such as target. This design involves adding a new top level command and corresponding handler in cordova-lib. Similar to run, the code with logic will reside somewhere like cordova-lib\cordova-lib\src\cordova\target.js. I would like to get some feedback about these options. -Original Message- From: Murat Sutunc [mailto:mura...@microsoft.com] Sent: Tuesday, January 6, 2015 5:42 PM To: dev@cordova.apache.org Subject: RE: Cordova --list option implementation The feedback is definitely very valuable. I was trying to understand the issues with the existing design and once the impact is realized all the commits are immediately reversed. I'm currently looking into your suggestions and will try to come up with a better design. -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Tuesday, January 6, 2015 10:40 AM To: dev@cordova.apache.org Subject: Re: Cordova --list option implementation Parashuram wrote: >Josh, is your concern that ‹list throws an error in case of blackberry? No. my concern is that the way this was done was wrong . It doesn't work for *ANY* project that exists today with *ANY* platform. Cordova's design is to be backwards compatible. The code that was written absolutely failed that. I tried to hint at that in my review comments. But that was totally ignored. Note that list threw an error in android (@released) too (as Andrew belatedly noted). >We could fix that by either >1a- Ignoring unknown flags like other platforms - and document the >ignoring part as the default behavior This is too late. You can't really change the behavior because cordova-cli/cordova-lib needs to support old projects with old platforms. >1b - or change other platforms to throw error on unsupported flags. In >this case, ‹list would do the check to see if ‹list is implemented first. You can't do this for the same reason that we can't do 1a. >2. Implement ‹list for blackberry, thereby not having error on any >platform. We could then have a separate discussion about what happens >when a flag is not supported by a platform. It's not specific to blackberry10, it applies to all existing platforms which happen to have the underlying support but which shipped without an imaginary change to run.js >It would be great if we can let users use the ‹list functionality with >minimal disruption to any platform. Correct. And this is trivially done -- put the code into cordova-lib and have it run the scripts from the platforms, instead of requiring changes to platforms — they already did the work they need to do (they are free to replace their existing impls w/ node.js impls if they haven't already, but that's transparent to cordova-lib). B CB [ X ܚX KK[XZ[ ] ][ X ܚX P ܙݘK \X K ܙ B ܈Y][ۘ[ [X[ K[XZ[ ] Z[ ܙݘK \X K ܙ B - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Cordova --list option implementation
The feedback is definitely very valuable. I was trying to understand the issues with the existing design and once the impact is realized all the commits are immediately reversed. I'm currently looking into your suggestions and will try to come up with a better design. -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Tuesday, January 6, 2015 10:40 AM To: dev@cordova.apache.org Subject: Re: Cordova --list option implementation Parashuram wrote: >Josh, is your concern that ‹list throws an error in case of blackberry? No. my concern is that the way this was done was wrong . It doesn't work for *ANY* project that exists today with *ANY* platform. Cordova's design is to be backwards compatible. The code that was written absolutely failed that. I tried to hint at that in my review comments. But that was totally ignored. Note that list threw an error in android (@released) too (as Andrew belatedly noted). >We could fix that by either >1a- Ignoring unknown flags like other platforms - and document the >ignoring part as the default behavior This is too late. You can't really change the behavior because cordova-cli/cordova-lib needs to support old projects with old platforms. >1b - or change other platforms to throw error on unsupported flags. In >this case, ‹list would do the check to see if ‹list is implemented first. You can't do this for the same reason that we can't do 1a. >2. Implement ‹list for blackberry, thereby not having error on any >platform. We could then have a separate discussion about what happens when >a flag is not supported by a platform. It's not specific to blackberry10, it applies to all existing platforms which happen to have the underlying support but which shipped without an imaginary change to run.js >It would be great if we can let users use the ‹list functionality with >minimal disruption to any platform. Correct. And this is trivially done -- put the code into cordova-lib and have it run the scripts from the platforms, instead of requiring changes to platforms — they already did the work they need to do (they are free to replace their existing impls w/ node.js impls if they haven't already, but that's transparent to cordova-lib).
RE: [DISCUSS] Tools Release
Several thoughts, 1) When provided with an unknown extra parameter, such as --list in this case, all the platforms ignore it. This looks like the expected behavior as there are several issues in Jira related to it. (ex. See bug CB-6676 - https://issues.apache.org/jira/browse/CB-6676?jql=project%20%3D%20CB%20AND%20text%20~%20%22ignore%20parameter%22). Exit code 1 on Blackberry seems like a bug. 2) Introducing 'target' as a top level option seems like a new proposal. My thoughts were to avoid having a new top level command for listing devices but I would like to hear others opinions on this as well. I also think 'target' might not be the best choice of keyword here as it's already part of 'run' and it's easy to get confused: cordova run --target=FOO cordova target --list 3) I don’t understand the 'cordova target add' command completely. Is it an alias to 'cordova platform add'? 4) 'Each platform should already support the list-* commands' is currently not true. firefoxos, browser, Ubuntu don’t support it. -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Monday, January 5, 2015 11:57 AM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Tools Release Murat Sutunc wrote: > I've mentioned this compatibility issue with my first feature discussion >mail. > Currently in case a platform doesn't support --list flag, > CLI will ignore the flag and run as if the flag is not provided (due to >current args parsing logic in platforms), > it won't be breaking any platform. > I might be able to help with the compatibility issues if you need any >assistance. $ cordova run --list Running command: /tmp/aa/platforms/android/cordova/run --list Running command: /tmp/aa/platforms/blackberry10/cordova/run --list error: unknown option `--list' ERROR running one or more of the platforms: Error: /tmp/aa/platforms/blackberry10/cordova/run: Command failed with exit code 1 You may not have the required environment or OS to run this project Available Android Devices: Available Android Virtual Devices: This output is really bad. I'm pretty unhappy that the changes were landed as is, and I intend to revert them. Here's the design I'd like to see: cordova target[s] list PLATFORM* [devices|emulators] This shouldn't require any change to any of the platforms, since each platform should already support the list-* commands. It also works in the direction of: cordova target add [PLATFORM] targetname -- … Which would match more or less what webworks uses: webworks target add [ -t device | simulator] [-p ] [--pin ] https://developer.blackberry.com/html5/documentation/v2_2/setting_up_test_t argets.html
RE: [DISCUSS] Tools Release
I've mentioned this compatibility issue with my first feature discussion mail. Currently in case a platform doesn't support --list flag, CLI will ignore the flag and run as if the flag is not provided (due to current args parsing logic in platforms), it won't be breaking any platform. I might be able to help with the compatibility issues if you need any assistance. -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Saturday, January 3, 2015 6:20 PM To: Cordova Dev Subject: Re: [DISCUSS] Tools Release OK. Now I'm -1 on releasing. Merging the --list patch was not fair to the other platforms. I'll have to spend Monday writing compatibility code for them. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: --list argument for CLI
Sorry for the delay on this thread. I've updated the pull requests with the feedback I got earlier. They should be good now. -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Friday, December 19, 2014 8:08 AM To: dev@cordova.apache.org Subject: RE: --list argument for CLI Murat wrote: > I've the initial work available as pull requests here: > cordova-cli: https://github.com/apache/cordova-cli/pull/199 > cordova-android: https://github.com/apache/cordova-android/pull/139 > cordova-ios: https://github.com/apache/cordova-ios/pull/122 > If anyone has time to go through the pull requests and accept, that would be > fantastic! Hi murat, Sorry for not getting around to them sooner. They were on my list of things I am interested in. A colleague asked me about something related, so I just spent the time to give feedback. Before you take the time to read my feedback, I'd like to get you to think back to how you started working on Cordova. Which web pages / documentation did you find/read? What did they take you to? Where there sections that you skipped because "I already know how to do X"? Then, read through the wiki page I mentioned in the feedback. If that wiki page wasn't one of the ones you already read, then please indicate what you read. Because we need to ensure that contributors do see it. Also, if any of the things I've mentioned aren't listed in the pages that you will have read, please let us know so that we can fix them :). If you skipped a section, and it turns out that the section has relevant content, please let us know, in one case, a section's name hinted to someone that it was standard stuff when in fact it had other important Cordova specific details, so we tried to rename the link (I don't know if it worked, you're perhaps the first person who can tell me...). Thanks, and welcome.
RE: --list argument for CLI
Hi Josh, Amazing feedback, thank you for spending the time going through all the changes! I've read the wiki page you mentioned before but looks like I've missed the section of it regarding commit messages, my bad. I have a question about decoupling of feature work and other tasks (such as code style issues and refactoring). Should other tasks also be tagged with the original feature CB tag? Or should I just treat them as a separate item with a separate CB tag and make a new pull request for it? Thanks, Murat -Original Message- From: Josh Soref [mailto:jso...@blackberry.com] Sent: Friday, December 19, 2014 8:08 AM To: dev@cordova.apache.org Subject: RE: --list argument for CLI Murat wrote: > I've the initial work available as pull requests here: > cordova-cli: https://github.com/apache/cordova-cli/pull/199 > cordova-android: https://github.com/apache/cordova-android/pull/139 > cordova-ios: https://github.com/apache/cordova-ios/pull/122 > If anyone has time to go through the pull requests and accept, that would be > fantastic! Hi murat, Sorry for not getting around to them sooner. They were on my list of things I am interested in. A colleague asked me about something related, so I just spent the time to give feedback. Before you take the time to read my feedback, I'd like to get you to think back to how you started working on Cordova. Which web pages / documentation did you find/read? What did they take you to? Where there sections that you skipped because "I already know how to do X"? Then, read through the wiki page I mentioned in the feedback. If that wiki page wasn't one of the ones you already read, then please indicate what you read. Because we need to ensure that contributors do see it. Also, if any of the things I've mentioned aren't listed in the pages that you will have read, please let us know so that we can fix them :). If you skipped a section, and it turns out that the section has relevant content, please let us know, in one case, a section's name hinted to someone that it was standard stuff when in fact it had other important Cordova specific details, so we tried to rename the link (I don't know if it worked, you're perhaps the first person who can tell me...). Thanks, and welcome. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: --list argument for CLI
Thanks everyone for the warm welcome! I've the initial work available as pull requests here: cordova-cli: https://github.com/apache/cordova-cli/pull/199 cordova-android: https://github.com/apache/cordova-android/pull/139 cordova-ios: https://github.com/apache/cordova-ios/pull/122 If anyone has time to go through the pull requests and accept, that would be fantastic! Thanks, Murat -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Tuesday, December 16, 2014 10:10 AM To: dev@cordova.apache.org Subject: Re: --list argument for CLI Welcome, and +1! On Tue, Dec 16, 2014 at 10:23 AM, Andrew Grieve wrote: > Sounds great! > > On Tue, Dec 16, 2014 at 4:55 AM, Jesse wrote: >> >> Yes to all of this, and welcome aboard! >> >> Cheers, >> Jesse >> >> > On Dec 15, 2014, at 3:22 PM, Murat Sutunc wrote: >> > >> > Hi all, >> > My name is Murat Sutunc, I'm part of the Visual Studio team @ >> > Microsoft >> and new to Cordova. >> > >> > I was looking at the Cordova Tooling Wiki at ( >> https://wiki.apache.org/cordova/CommandLineToolingDesign) and thought >> it would be interesting to make some additions to the list-devices feature. >> Currently we have list-devices and list-emulator-images scripts for a >> lot of different platforms. However these scripts are not easily >> accessible from the Cordova CLI. By introducing an additional >> argument to the run or emulate command, we could show a list of >> available emulators or connected devices. (I would like to >> deemphasize the fact that the command is called --list). After >> invoking the command, a user can decide which target to use and run >> the app on the desired target by using cordova run -device devicename >> > >> > Here's how it looks for an Android only project: >> > C:\dev\cordova-projects\hello>cordova run --list Running command: >> C:\dev\cordova-projects\hello\platforms\android\cordova\run.bat >> --list >> > Available Android Virtual Devices: >> >AVD_GalaxyNexus_ToolsForApacheCordova >> > Available Android Devices: >> > >> > (Internally what happens here is, through run.js we will call >> > android >> list and adb devices and pipe that list to the user. Similar process >> with iOS too.) >> > >> > Note that in case a platform doesn't support --list flag, it'll >> > ignore >> the flag and run as if the flag is not provided. This is due to >> current args parsing logic in platforms. Is this ok for the short >> term? I would hope that more platforms would support this option in the >> future. >> > >> > Below are the pull requests for cordova-cli and >> cordova-android/cordova-ios that have this functionality implemented. >> I would like to hear your thoughts on this design, choice of the flag >> and if you think this feature would be a valuable addition to the CLI. >> > >> > cordova-cli: https://github.com/apache/cordova-cli/pull/199 >> > cordova-android: https://github.com/apache/cordova-android/pull/139 >> > cordova-ios: https://github.com/apache/cordova-ios/pull/122 >> > >> > PS: My ICLA just got approved. You can also ping me anytime on >> > #cordova, >> my name on irc is muratsu. >> > >> > Thanks! >> > -Murat >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
--list argument for CLI
Hi all, My name is Murat Sutunc, I'm part of the Visual Studio team @ Microsoft and new to Cordova. I was looking at the Cordova Tooling Wiki at (https://wiki.apache.org/cordova/CommandLineToolingDesign) and thought it would be interesting to make some additions to the list-devices feature. Currently we have list-devices and list-emulator-images scripts for a lot of different platforms. However these scripts are not easily accessible from the Cordova CLI. By introducing an additional argument to the run or emulate command, we could show a list of available emulators or connected devices. (I would like to deemphasize the fact that the command is called --list). After invoking the command, a user can decide which target to use and run the app on the desired target by using cordova run -device devicename Here's how it looks for an Android only project: C:\dev\cordova-projects\hello>cordova run --list Running command: C:\dev\cordova-projects\hello\platforms\android\cordova\run.bat --list Available Android Virtual Devices: AVD_GalaxyNexus_ToolsForApacheCordova Available Android Devices: (Internally what happens here is, through run.js we will call android list and adb devices and pipe that list to the user. Similar process with iOS too.) Note that in case a platform doesn't support --list flag, it'll ignore the flag and run as if the flag is not provided. This is due to current args parsing logic in platforms. Is this ok for the short term? I would hope that more platforms would support this option in the future. Below are the pull requests for cordova-cli and cordova-android/cordova-ios that have this functionality implemented. I would like to hear your thoughts on this design, choice of the flag and if you think this feature would be a valuable addition to the CLI. cordova-cli: https://github.com/apache/cordova-cli/pull/199 cordova-android: https://github.com/apache/cordova-android/pull/139 cordova-ios: https://github.com/apache/cordova-ios/pull/122 PS: My ICLA just got approved. You can also ping me anytime on #cordova, my name on irc is muratsu. Thanks! -Murat
