Re: [DISCUSS] cordova-common release
+1 Release early, release often 😁 Darryl Pogue schrieb am Mi., 30. Mai 2018, 09:20: > Hey folks, > > There have been a number of commits[1] to cordova-common since the previous > release, primarily related to bringing outdated dependencies up to date and > tackling a backlog of bugfix pull requests. > > As you may know, npm 6 has been released and includes an audit feature to > warn about packages using dependencies with known security vulnerabilities. > The current release of cordova-common causes a few of these warnings due to > dependencies relying on old versions of things like request and lodash. > The dependency updates that have been merge on master allow cordova-common > to install with 0 vulnerability warnings. > > We're starting to look at some bigger cleanups[2] and dependency updates > that might need to involve a major version bump, so I think now is a good > time to do a release of cordova-common before any of those larger changes > are merged. > > We've been talking about doing a tools release for a while, but I think > starting with a release of just cordova-common is better than nothing. > > Any thoughts or concerns? > > ~Darryl > > [1] https://github.com/apache/cordova-common/compare/2.2.1...master > [2] https://github.com/apache/cordova-common/pull/21 > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [Discuss] cordova common release
No objection El martes, 21 de noviembre de 2017, Steven Gill escribió: > We need to do a cordova common release in preparation for > cordova-android@7.0.0 release. Any objections? >
Re: [Discuss] Cordova-common release
+1 much better README, and npm angels will bless you with a kiss for versioning it 1.0.0 On Wed, Oct 28, 2015 at 9:11 PM Steven Gill wrote: > Left a bit of feedback. LGTM. Lets get this release rolling. > > -Steve > > On Wed, Oct 28, 2015 at 6:30 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > The vote has failed. I'll bump version to 1.0.0 and start a new vote once > > the documentation for module will be added/updated. > > > > Steve, Carlos, could you please review cordova-common documentation draft > > here: https://github.com/apache/cordova-lib/pull/331 > > > > - > > Best regards, Vladimir. > > > > -Original Message- > > From: Carlos Santana [mailto:csantan...@gmail.com] > > Sent: Saturday, October 24, 2015 4:35 AM > > To: dev@cordova.apache.org > > Subject: Re: [Discuss] Cordova-common release > > > > I'm disappointed Steve, the npm team will remember you as the guy that > > keeps publishing 0.x packages like it was 2013 LOL > > > > > > On Fri, Oct 23, 2015 at 9:24 PM Steven Gill > > wrote: > > > > > Those are good points about the readme. I thought the same thing about > > > the version but was going to let it slide :P. > > > > > > > > > > > > On Fri, Oct 23, 2015 at 6:14 PM, Carlos Santana > > > wrote: > > > > > > > Not excited about putting this on npm, I feel you can just name it > > > > cordova-lib2 > > > > But if we are going to do it let's at least follow the npm way: > > > > The version should be 1.0.0, because shipping 0.x is kind lame this > > > > days What is the API of this first release? I hope there is a good > > > > README that will be display on > > > https://na01.safelinks.protection.outlook.com/?url=npmjs.com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MevYqWuEKkGzlZB0skKnx2iTiUgi6sk57zQoNCMqIZo%3d > > > > cdvCommon = require('cordova-common') > > > > cdvCommon.x does x > > > > cdvCommon.y does y > > > > Since there is no "npm test" or test folder, the README should talk > > > > about how this code in the npm module get's tested from cordova-lib > > > > > > > > > > > > > > > > > > > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill > > > > wrote: > > > > > > > > > DO IT! > > > > > > > > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < > > > > > v-vlk...@microsoft.com> wrote: > > > > > > > > > > > So if there is no -1, I'm going to start VOTE thread tomorrow. > > > > > > > > > > > > - > > > > > > Best regards, Vladimir > > > > > > > > > > > > -Original Message- > > > > > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > > > > > Sent: Thursday, October 22, 2015 2:09 PM > > > > > > To: dev@cordova.apache.org > > > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > > > > > > From what I understand, it's release ready with no known > issues. > > > > > > Vladimir: Is that correct? > > > > > > Confirm. The only one problem is missing license header for > Adb.js. > > > > Added > > > > > > it in 78b7ae7. Right now everything is ready for release. > > > > > > > > > > > > - > > > > > > Best regards, Vladimir > > > > > > > > > > > > -----Original Message- > > > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > > > > > > Sent: Wednesday, October 21, 2015 7:31 PM > > > > > > To: dev@cordova.apache.org > > > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > > > > > It should not - it's a good change for Android 5.0. However, it > > > > > > does represent a big change and we need more testing. From what > > > > > > I > > > > understand, > > > > > > it's release ready with no known issues. Vladimir: Is that > correct? > > > > > > > > > > > > As for the cordova-common dependency, cord
Re: [Discuss] Cordova-common release
Left a bit of feedback. LGTM. Lets get this release rolling. -Steve On Wed, Oct 28, 2015 at 6:30 AM, Vladimir Kotikov (Akvelon) < v-vlk...@microsoft.com> wrote: > The vote has failed. I'll bump version to 1.0.0 and start a new vote once > the documentation for module will be added/updated. > > Steve, Carlos, could you please review cordova-common documentation draft > here: https://github.com/apache/cordova-lib/pull/331 > > - > Best regards, Vladimir. > > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Saturday, October 24, 2015 4:35 AM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > I'm disappointed Steve, the npm team will remember you as the guy that > keeps publishing 0.x packages like it was 2013 LOL > > > On Fri, Oct 23, 2015 at 9:24 PM Steven Gill > wrote: > > > Those are good points about the readme. I thought the same thing about > > the version but was going to let it slide :P. > > > > > > > > On Fri, Oct 23, 2015 at 6:14 PM, Carlos Santana > > wrote: > > > > > Not excited about putting this on npm, I feel you can just name it > > > cordova-lib2 > > > But if we are going to do it let's at least follow the npm way: > > > The version should be 1.0.0, because shipping 0.x is kind lame this > > > days What is the API of this first release? I hope there is a good > > > README that will be display on > https://na01.safelinks.protection.outlook.com/?url=npmjs.com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MevYqWuEKkGzlZB0skKnx2iTiUgi6sk57zQoNCMqIZo%3d > > > cdvCommon = require('cordova-common') > > > cdvCommon.x does x > > > cdvCommon.y does y > > > Since there is no "npm test" or test folder, the README should talk > > > about how this code in the npm module get's tested from cordova-lib > > > > > > > > > > > > > > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill > > > wrote: > > > > > > > DO IT! > > > > > > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < > > > > v-vlk...@microsoft.com> wrote: > > > > > > > > > So if there is no -1, I'm going to start VOTE thread tomorrow. > > > > > > > > > > - > > > > > Best regards, Vladimir > > > > > > > > > > -Original Message- > > > > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > > > > Sent: Thursday, October 22, 2015 2:09 PM > > > > > To: dev@cordova.apache.org > > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > > > > From what I understand, it's release ready with no known issues. > > > > > Vladimir: Is that correct? > > > > > Confirm. The only one problem is missing license header for Adb.js. > > > Added > > > > > it in 78b7ae7. Right now everything is ready for release. > > > > > > > > > > - > > > > > Best regards, Vladimir > > > > > > > > > > -Original Message- > > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > > > > > Sent: Wednesday, October 21, 2015 7:31 PM > > > > > To: dev@cordova.apache.org > > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > > > It should not - it's a good change for Android 5.0. However, it > > > > > does represent a big change and we need more testing. From what > > > > > I > > > understand, > > > > > it's release ready with no known issues. Vladimir: Is that correct? > > > > > > > > > > As for the cordova-common dependency, cordova-android will bundle > it. > > > And > > > > > we don't have to wait for a cordova-common release to release > > > > > cordova-android. > > > > > > > > > > -Nikhil > > > > > > > > > > -Original Message- > > > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > > > Sent: Wednesday, October 21, 2015 9:19 AM > > > > > To: dev > > > > > Subject: Re: [Discuss] Cordova-common release > > > > > > > > > > OK, how will this impact t
RE: [Discuss] Cordova-common release
The vote has failed. I'll bump version to 1.0.0 and start a new vote once the documentation for module will be added/updated. Steve, Carlos, could you please review cordova-common documentation draft here: https://github.com/apache/cordova-lib/pull/331 - Best regards, Vladimir. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Saturday, October 24, 2015 4:35 AM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release I'm disappointed Steve, the npm team will remember you as the guy that keeps publishing 0.x packages like it was 2013 LOL On Fri, Oct 23, 2015 at 9:24 PM Steven Gill wrote: > Those are good points about the readme. I thought the same thing about > the version but was going to let it slide :P. > > > > On Fri, Oct 23, 2015 at 6:14 PM, Carlos Santana > wrote: > > > Not excited about putting this on npm, I feel you can just name it > > cordova-lib2 > > But if we are going to do it let's at least follow the npm way: > > The version should be 1.0.0, because shipping 0.x is kind lame this > > days What is the API of this first release? I hope there is a good > > README that will be display on > > https://na01.safelinks.protection.outlook.com/?url=npmjs.com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MevYqWuEKkGzlZB0skKnx2iTiUgi6sk57zQoNCMqIZo%3d > > cdvCommon = require('cordova-common') > > cdvCommon.x does x > > cdvCommon.y does y > > Since there is no "npm test" or test folder, the README should talk > > about how this code in the npm module get's tested from cordova-lib > > > > > > > > > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill > > wrote: > > > > > DO IT! > > > > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < > > > v-vlk...@microsoft.com> wrote: > > > > > > > So if there is no -1, I'm going to start VOTE thread tomorrow. > > > > > > > > - > > > > Best regards, Vladimir > > > > > > > > -Original Message- > > > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > > > Sent: Thursday, October 22, 2015 2:09 PM > > > > To: dev@cordova.apache.org > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > > From what I understand, it's release ready with no known issues. > > > > Vladimir: Is that correct? > > > > Confirm. The only one problem is missing license header for Adb.js. > > Added > > > > it in 78b7ae7. Right now everything is ready for release. > > > > > > > > - > > > > Best regards, Vladimir > > > > > > > > -Original Message- > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > > > > Sent: Wednesday, October 21, 2015 7:31 PM > > > > To: dev@cordova.apache.org > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > It should not - it's a good change for Android 5.0. However, it > > > > does represent a big change and we need more testing. From what > > > > I > > understand, > > > > it's release ready with no known issues. Vladimir: Is that correct? > > > > > > > > As for the cordova-common dependency, cordova-android will bundle it. > > And > > > > we don't have to wait for a cordova-common release to release > > > > cordova-android. > > > > > > > > -Nikhil > > > > > > > > -Original Message- > > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > > Sent: Wednesday, October 21, 2015 9:19 AM > > > > To: dev > > > > Subject: Re: [Discuss] Cordova-common release > > > > > > > > OK, how will this impact the 5.0 release of Android? > > > > > > > > On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal < > > > nikhi...@microsoft.com > > > > > > > > > wrote: > > > > > > > > > It got checked in earlier this morning. > > > > > > > > > > -Nikhil > > > > > > > > > > -Original Message- > > > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > > > Sent: Tuesday, October 20, 2015 2:34 PM > > > > > To: dev > > > > > Subject: Re:
Re: [Discuss] Cordova-common release
I'm disappointed Steve, the npm team will remember you as the guy that keeps publishing 0.x packages like it was 2013 LOL On Fri, Oct 23, 2015 at 9:24 PM Steven Gill wrote: > Those are good points about the readme. I thought the same thing about the > version but was going to let it slide :P. > > > > On Fri, Oct 23, 2015 at 6:14 PM, Carlos Santana > wrote: > > > Not excited about putting this on npm, I feel you can just name it > > cordova-lib2 > > But if we are going to do it let's at least follow the npm way: > > The version should be 1.0.0, because shipping 0.x is kind lame this days > > What is the API of this first release? I hope there is a good README that > > will be display on npmjs.com > > cdvCommon = require('cordova-common') > > cdvCommon.x does x > > cdvCommon.y does y > > Since there is no "npm test" or test folder, the README should talk about > > how this code in the npm module get's tested from cordova-lib > > > > > > > > > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill > > wrote: > > > > > DO IT! > > > > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < > > > v-vlk...@microsoft.com> wrote: > > > > > > > So if there is no -1, I'm going to start VOTE thread tomorrow. > > > > > > > > - > > > > Best regards, Vladimir > > > > > > > > -Original Message- > > > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > > > Sent: Thursday, October 22, 2015 2:09 PM > > > > To: dev@cordova.apache.org > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > > From what I understand, it's release ready with no known issues. > > > > Vladimir: Is that correct? > > > > Confirm. The only one problem is missing license header for Adb.js. > > Added > > > > it in 78b7ae7. Right now everything is ready for release. > > > > > > > > - > > > > Best regards, Vladimir > > > > > > > > -Original Message- > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > > > > Sent: Wednesday, October 21, 2015 7:31 PM > > > > To: dev@cordova.apache.org > > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > > It should not - it's a good change for Android 5.0. However, it does > > > > represent a big change and we need more testing. From what I > > understand, > > > > it's release ready with no known issues. Vladimir: Is that correct? > > > > > > > > As for the cordova-common dependency, cordova-android will bundle it. > > And > > > > we don't have to wait for a cordova-common release to release > > > > cordova-android. > > > > > > > > -Nikhil > > > > > > > > -Original Message- > > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > > Sent: Wednesday, October 21, 2015 9:19 AM > > > > To: dev > > > > Subject: Re: [Discuss] Cordova-common release > > > > > > > > OK, how will this impact the 5.0 release of Android? > > > > > > > > On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal < > > > nikhi...@microsoft.com > > > > > > > > > wrote: > > > > > > > > > It got checked in earlier this morning. > > > > > > > > > > -Nikhil > > > > > > > > > > -Original Message- > > > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > > > Sent: Tuesday, October 20, 2015 2:34 PM > > > > > To: dev > > > > > Subject: Re: [Discuss] Cordova-common release > > > > > > > > > > So, when did the PlatformAPI change land in Android? > > > > > > > > > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N < > > panar...@microsoft.com> > > > > > wrote: > > > > > > > > > > > +1 - YES please. Requiring cordoba-common for my > > > > > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" < > nikhi...@microsoft.com> > > > > > wrote: > >
Re: [Discuss] Cordova-common release
Those are good points about the readme. I thought the same thing about the version but was going to let it slide :P. On Fri, Oct 23, 2015 at 6:14 PM, Carlos Santana wrote: > Not excited about putting this on npm, I feel you can just name it > cordova-lib2 > But if we are going to do it let's at least follow the npm way: > The version should be 1.0.0, because shipping 0.x is kind lame this days > What is the API of this first release? I hope there is a good README that > will be display on npmjs.com > cdvCommon = require('cordova-common') > cdvCommon.x does x > cdvCommon.y does y > Since there is no "npm test" or test folder, the README should talk about > how this code in the npm module get's tested from cordova-lib > > > > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill > wrote: > > > DO IT! > > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < > > v-vlk...@microsoft.com> wrote: > > > > > So if there is no -1, I'm going to start VOTE thread tomorrow. > > > > > > - > > > Best regards, Vladimir > > > > > > -Original Message- > > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > > Sent: Thursday, October 22, 2015 2:09 PM > > > To: dev@cordova.apache.org > > > Subject: RE: [Discuss] Cordova-common release > > > > > > > From what I understand, it's release ready with no known issues. > > > Vladimir: Is that correct? > > > Confirm. The only one problem is missing license header for Adb.js. > Added > > > it in 78b7ae7. Right now everything is ready for release. > > > > > > - > > > Best regards, Vladimir > > > > > > -Original Message- > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > > > Sent: Wednesday, October 21, 2015 7:31 PM > > > To: dev@cordova.apache.org > > > Subject: RE: [Discuss] Cordova-common release > > > > > > It should not - it's a good change for Android 5.0. However, it does > > > represent a big change and we need more testing. From what I > understand, > > > it's release ready with no known issues. Vladimir: Is that correct? > > > > > > As for the cordova-common dependency, cordova-android will bundle it. > And > > > we don't have to wait for a cordova-common release to release > > > cordova-android. > > > > > > -Nikhil > > > > > > -Original Message- > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > Sent: Wednesday, October 21, 2015 9:19 AM > > > To: dev > > > Subject: Re: [Discuss] Cordova-common release > > > > > > OK, how will this impact the 5.0 release of Android? > > > > > > On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal < > > nikhi...@microsoft.com > > > > > > > wrote: > > > > > > > It got checked in earlier this morning. > > > > > > > > -Nikhil > > > > > > > > -Original Message- > > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > > Sent: Tuesday, October 20, 2015 2:34 PM > > > > To: dev > > > > Subject: Re: [Discuss] Cordova-common release > > > > > > > > So, when did the PlatformAPI change land in Android? > > > > > > > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N < > panar...@microsoft.com> > > > > wrote: > > > > > > > > > +1 - YES please. Requiring cordoba-common for my > > > > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > > > > > > > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > > > > wrote: > > > > > > > > > > >+1 to publishing cordova-common to npm. > > > > > > > > > > > >-Nikhil > > > > > > > > > > > >-Original Message- > > > > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > > > > >Sent: Tuesday, October 20, 2015 2:20 PM > > > > > >To: dev@cordova.apache.org > > > > > >Subject: Re: [Discuss] Cordova-common release > > > > > > > > > > > >I want to revisit this. > > > > > > > > > > > >So cordova-android has a dependency now on cordova-common. It is a
Re: [Discuss] Cordova-common release
Not excited about putting this on npm, I feel you can just name it cordova-lib2 But if we are going to do it let's at least follow the npm way: The version should be 1.0.0, because shipping 0.x is kind lame this days What is the API of this first release? I hope there is a good README that will be display on npmjs.com cdvCommon = require('cordova-common') cdvCommon.x does x cdvCommon.y does y Since there is no "npm test" or test folder, the README should talk about how this code in the npm module get's tested from cordova-lib On Thu, Oct 22, 2015 at 2:46 PM Steven Gill wrote: > DO IT! > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > So if there is no -1, I'm going to start VOTE thread tomorrow. > > > > - > > Best regards, Vladimir > > > > -Original Message- > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > Sent: Thursday, October 22, 2015 2:09 PM > > To: dev@cordova.apache.org > > Subject: RE: [Discuss] Cordova-common release > > > > > From what I understand, it's release ready with no known issues. > > Vladimir: Is that correct? > > Confirm. The only one problem is missing license header for Adb.js. Added > > it in 78b7ae7. Right now everything is ready for release. > > > > - > > Best regards, Vladimir > > > > -Original Message- > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > > Sent: Wednesday, October 21, 2015 7:31 PM > > To: dev@cordova.apache.org > > Subject: RE: [Discuss] Cordova-common release > > > > It should not - it's a good change for Android 5.0. However, it does > > represent a big change and we need more testing. From what I understand, > > it's release ready with no known issues. Vladimir: Is that correct? > > > > As for the cordova-common dependency, cordova-android will bundle it. And > > we don't have to wait for a cordova-common release to release > > cordova-android. > > > > -Nikhil > > > > -Original Message- > > From: Joe Bowser [mailto:bows...@gmail.com] > > Sent: Wednesday, October 21, 2015 9:19 AM > > To: dev > > Subject: Re: [Discuss] Cordova-common release > > > > OK, how will this impact the 5.0 release of Android? > > > > On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal < > nikhi...@microsoft.com > > > > > wrote: > > > > > It got checked in earlier this morning. > > > > > > -Nikhil > > > > > > -Original Message- > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > Sent: Tuesday, October 20, 2015 2:34 PM > > > To: dev > > > Subject: Re: [Discuss] Cordova-common release > > > > > > So, when did the PlatformAPI change land in Android? > > > > > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N > > > wrote: > > > > > > > +1 - YES please. Requiring cordoba-common for my > > > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > > > wrote: > > > > > > > > >+1 to publishing cordova-common to npm. > > > > > > > > > >-Nikhil > > > > > > > > > >-Original Message- > > > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > > > >Sent: Tuesday, October 20, 2015 2:20 PM > > > > >To: dev@cordova.apache.org > > > > >Subject: Re: [Discuss] Cordova-common release > > > > > > > > > >I want to revisit this. > > > > > > > > > >So cordova-android has a dependency now on cordova-common. It is a > > > > bundledDependency so when we generate a tar to release > > > > cordova-android, it will be included. It will also be in the > > > > cordova-android package that gets downloaded with cordova platform > add. > > > > > > > > > >This is fine for released work, but more annoying for development. > > > > >I need > > > > to npm link cordova-common into cordova-android (and soon every > > > > platform which implements common platformAPI). We could check in > > > > cordova-common into cordova-android but that isn't a great solution > > > either. > > > > > > > > > >I agree that we should be going towards smalle
Re: [Discuss] Cordova-common release
DO IT! On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) < v-vlk...@microsoft.com> wrote: > So if there is no -1, I'm going to start VOTE thread tomorrow. > > - > Best regards, Vladimir > > -Original Message- > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > Sent: Thursday, October 22, 2015 2:09 PM > To: dev@cordova.apache.org > Subject: RE: [Discuss] Cordova-common release > > > From what I understand, it's release ready with no known issues. > Vladimir: Is that correct? > Confirm. The only one problem is missing license header for Adb.js. Added > it in 78b7ae7. Right now everything is ready for release. > > - > Best regards, Vladimir > > -Original Message- > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] > Sent: Wednesday, October 21, 2015 7:31 PM > To: dev@cordova.apache.org > Subject: RE: [Discuss] Cordova-common release > > It should not - it's a good change for Android 5.0. However, it does > represent a big change and we need more testing. From what I understand, > it's release ready with no known issues. Vladimir: Is that correct? > > As for the cordova-common dependency, cordova-android will bundle it. And > we don't have to wait for a cordova-common release to release > cordova-android. > > -Nikhil > > -----Original Message- > From: Joe Bowser [mailto:bows...@gmail.com] > Sent: Wednesday, October 21, 2015 9:19 AM > To: dev > Subject: Re: [Discuss] Cordova-common release > > OK, how will this impact the 5.0 release of Android? > > On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal > > wrote: > > > It got checked in earlier this morning. > > > > -Nikhil > > > > -Original Message- > > From: Joe Bowser [mailto:bows...@gmail.com] > > Sent: Tuesday, October 20, 2015 2:34 PM > > To: dev > > Subject: Re: [Discuss] Cordova-common release > > > > So, when did the PlatformAPI change land in Android? > > > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N > > wrote: > > > > > +1 - YES please. Requiring cordoba-common for my > > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > > wrote: > > > > > > >+1 to publishing cordova-common to npm. > > > > > > > >-Nikhil > > > > > > > >-Original Message- > > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > > >Sent: Tuesday, October 20, 2015 2:20 PM > > > >To: dev@cordova.apache.org > > > >Subject: Re: [Discuss] Cordova-common release > > > > > > > >I want to revisit this. > > > > > > > >So cordova-android has a dependency now on cordova-common. It is a > > > bundledDependency so when we generate a tar to release > > > cordova-android, it will be included. It will also be in the > > > cordova-android package that gets downloaded with cordova platform add. > > > > > > > >This is fine for released work, but more annoying for development. > > > >I need > > > to npm link cordova-common into cordova-android (and soon every > > > platform which implements common platformAPI). We could check in > > > cordova-common into cordova-android but that isn't a great solution > > either. > > > > > > > >I agree that we should be going towards smaller modules and not > > > >having a > > > case of cordovaLib1, cordovaLib2, etc. I think this is still going > > > to be a work in progress and will take some time. > > > > > > > >For the interim, I recommend we publish cordova-common. Of course, > > > continue to add it as a bundledDependency so users don't need to npm > > > install it with released packages. > > > > > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > > > v-vlk...@microsoft.com> wrote: > > > > > > > >> > I still do not understand what are you trying to solve by > > > >> > having all > > > >> that content published as big blob. > > > >> Code deduplication is the main reason. All the things from > > > >> 'cordova-common' will be used by platforms intensively, so we > > > >> need to share this code and keep it separately from LIB to share > easily. > > > >> Publishing is basically doesn't required for this, and bundling
RE: [Discuss] Cordova-common release
So if there is no -1, I'm going to start VOTE thread tomorrow. - Best regards, Vladimir -Original Message- From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] Sent: Thursday, October 22, 2015 2:09 PM To: dev@cordova.apache.org Subject: RE: [Discuss] Cordova-common release > From what I understand, it's release ready with no known issues. Vladimir: Is > that correct? Confirm. The only one problem is missing license header for Adb.js. Added it in 78b7ae7. Right now everything is ready for release. - Best regards, Vladimir -Original Message- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Wednesday, October 21, 2015 7:31 PM To: dev@cordova.apache.org Subject: RE: [Discuss] Cordova-common release It should not - it's a good change for Android 5.0. However, it does represent a big change and we need more testing. From what I understand, it's release ready with no known issues. Vladimir: Is that correct? As for the cordova-common dependency, cordova-android will bundle it. And we don't have to wait for a cordova-common release to release cordova-android. -Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Wednesday, October 21, 2015 9:19 AM To: dev Subject: Re: [Discuss] Cordova-common release OK, how will this impact the 5.0 release of Android? On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal wrote: > It got checked in earlier this morning. > > -Nikhil > > -Original Message- > From: Joe Bowser [mailto:bows...@gmail.com] > Sent: Tuesday, October 20, 2015 2:34 PM > To: dev > Subject: Re: [Discuss] Cordova-common release > > So, when did the PlatformAPI change land in Android? > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N > wrote: > > > +1 - YES please. Requiring cordoba-common for my > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > wrote: > > > > >+1 to publishing cordova-common to npm. > > > > > >-Nikhil > > > > > >-----Original Message- > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > >Sent: Tuesday, October 20, 2015 2:20 PM > > >To: dev@cordova.apache.org > > >Subject: Re: [Discuss] Cordova-common release > > > > > >I want to revisit this. > > > > > >So cordova-android has a dependency now on cordova-common. It is a > > bundledDependency so when we generate a tar to release > > cordova-android, it will be included. It will also be in the > > cordova-android package that gets downloaded with cordova platform add. > > > > > >This is fine for released work, but more annoying for development. > > >I need > > to npm link cordova-common into cordova-android (and soon every > > platform which implements common platformAPI). We could check in > > cordova-common into cordova-android but that isn't a great solution > either. > > > > > >I agree that we should be going towards smaller modules and not > > >having a > > case of cordovaLib1, cordovaLib2, etc. I think this is still going > > to be a work in progress and will take some time. > > > > > >For the interim, I recommend we publish cordova-common. Of course, > > continue to add it as a bundledDependency so users don't need to npm > > install it with released packages. > > > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > > v-vlk...@microsoft.com> wrote: > > > > > >> > I still do not understand what are you trying to solve by > > >> > having all > > >> that content published as big blob. > > >> Code deduplication is the main reason. All the things from > > >> 'cordova-common' will be used by platforms intensively, so we > > >> need to share this code and keep it separately from LIB to share easily. > > >> Publishing is basically doesn't required for this, and bundling > > >> 'cordova-common' into LIB is enough for this purpose. > > >> > > >> Another reason was that third-party tool might want to use some > > >> of this functionality (like your example with ConfigParser), so > > >> we need to have this package on NPM to allow them to get it. For > > >> this case I now do agree with you that separate packages for > > >> ConfigParser, PluginInfo and other stuff looks better than > > >> putting it into one big > > package. > > >> > > >> - > > >> Best rega
RE: [Discuss] Cordova-common release
> From what I understand, it's release ready with no known issues. Vladimir: Is > that correct? Confirm. The only one problem is missing license header for Adb.js. Added it in 78b7ae7. Right now everything is ready for release. - Best regards, Vladimir -Original Message- From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] Sent: Wednesday, October 21, 2015 7:31 PM To: dev@cordova.apache.org Subject: RE: [Discuss] Cordova-common release It should not - it's a good change for Android 5.0. However, it does represent a big change and we need more testing. From what I understand, it's release ready with no known issues. Vladimir: Is that correct? As for the cordova-common dependency, cordova-android will bundle it. And we don't have to wait for a cordova-common release to release cordova-android. -Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Wednesday, October 21, 2015 9:19 AM To: dev Subject: Re: [Discuss] Cordova-common release OK, how will this impact the 5.0 release of Android? On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal wrote: > It got checked in earlier this morning. > > -Nikhil > > -Original Message- > From: Joe Bowser [mailto:bows...@gmail.com] > Sent: Tuesday, October 20, 2015 2:34 PM > To: dev > Subject: Re: [Discuss] Cordova-common release > > So, when did the PlatformAPI change land in Android? > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N > wrote: > > > +1 - YES please. Requiring cordoba-common for my > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > wrote: > > > > >+1 to publishing cordova-common to npm. > > > > > >-Nikhil > > > > > >-Original Message----- > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > >Sent: Tuesday, October 20, 2015 2:20 PM > > >To: dev@cordova.apache.org > > >Subject: Re: [Discuss] Cordova-common release > > > > > >I want to revisit this. > > > > > >So cordova-android has a dependency now on cordova-common. It is a > > bundledDependency so when we generate a tar to release > > cordova-android, it will be included. It will also be in the > > cordova-android package that gets downloaded with cordova platform add. > > > > > >This is fine for released work, but more annoying for development. > > >I need > > to npm link cordova-common into cordova-android (and soon every > > platform which implements common platformAPI). We could check in > > cordova-common into cordova-android but that isn't a great solution > either. > > > > > >I agree that we should be going towards smaller modules and not > > >having a > > case of cordovaLib1, cordovaLib2, etc. I think this is still going > > to be a work in progress and will take some time. > > > > > >For the interim, I recommend we publish cordova-common. Of course, > > continue to add it as a bundledDependency so users don't need to npm > > install it with released packages. > > > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > > v-vlk...@microsoft.com> wrote: > > > > > >> > I still do not understand what are you trying to solve by > > >> > having all > > >> that content published as big blob. > > >> Code deduplication is the main reason. All the things from > > >> 'cordova-common' will be used by platforms intensively, so we > > >> need to share this code and keep it separately from LIB to share easily. > > >> Publishing is basically doesn't required for this, and bundling > > >> 'cordova-common' into LIB is enough for this purpose. > > >> > > >> Another reason was that third-party tool might want to use some > > >> of this functionality (like your example with ConfigParser), so > > >> we need to have this package on NPM to allow them to get it. For > > >> this case I now do agree with you that separate packages for > > >> ConfigParser, PluginInfo and other stuff looks better than > > >> putting it into one big > > package. > > >> > > >> - > > >> Best regards, Vladimir > > >> > > >> > > >> -Original Message- > > >> From: Carlos Santana [mailto:csantan...@gmail.com] > > >> Sent: Wednesday, September 30, 2015 2:07 PM > > >> To: dev@cordova.apache.org > > >> Subject: R
RE: [Discuss] Cordova-common release
It should not - it's a good change for Android 5.0. However, it does represent a big change and we need more testing. From what I understand, it's release ready with no known issues. Vladimir: Is that correct? As for the cordova-common dependency, cordova-android will bundle it. And we don't have to wait for a cordova-common release to release cordova-android. -Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Wednesday, October 21, 2015 9:19 AM To: dev Subject: Re: [Discuss] Cordova-common release OK, how will this impact the 5.0 release of Android? On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal wrote: > It got checked in earlier this morning. > > -Nikhil > > -Original Message- > From: Joe Bowser [mailto:bows...@gmail.com] > Sent: Tuesday, October 20, 2015 2:34 PM > To: dev > Subject: Re: [Discuss] Cordova-common release > > So, when did the PlatformAPI change land in Android? > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N > wrote: > > > +1 - YES please. Requiring cordoba-common for my > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > wrote: > > > > >+1 to publishing cordova-common to npm. > > > > > >-Nikhil > > > > > >-Original Message- > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > >Sent: Tuesday, October 20, 2015 2:20 PM > > >To: dev@cordova.apache.org > > >Subject: Re: [Discuss] Cordova-common release > > > > > >I want to revisit this. > > > > > >So cordova-android has a dependency now on cordova-common. It is a > > bundledDependency so when we generate a tar to release > > cordova-android, it will be included. It will also be in the > > cordova-android package that gets downloaded with cordova platform add. > > > > > >This is fine for released work, but more annoying for development. > > >I need > > to npm link cordova-common into cordova-android (and soon every > > platform which implements common platformAPI). We could check in > > cordova-common into cordova-android but that isn't a great solution > either. > > > > > >I agree that we should be going towards smaller modules and not > > >having a > > case of cordovaLib1, cordovaLib2, etc. I think this is still going > > to be a work in progress and will take some time. > > > > > >For the interim, I recommend we publish cordova-common. Of course, > > continue to add it as a bundledDependency so users don't need to npm > > install it with released packages. > > > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > > v-vlk...@microsoft.com> wrote: > > > > > >> > I still do not understand what are you trying to solve by > > >> > having all > > >> that content published as big blob. > > >> Code deduplication is the main reason. All the things from > > >> 'cordova-common' will be used by platforms intensively, so we > > >> need to share this code and keep it separately from LIB to share easily. > > >> Publishing is basically doesn't required for this, and bundling > > >> 'cordova-common' into LIB is enough for this purpose. > > >> > > >> Another reason was that third-party tool might want to use some > > >> of this functionality (like your example with ConfigParser), so > > >> we need to have this package on NPM to allow them to get it. For > > >> this case I now do agree with you that separate packages for > > >> ConfigParser, PluginInfo and other stuff looks better than > > >> putting it into one big > > package. > > >> > > >> - > > >> Best regards, Vladimir > > >> > > >> > > >> -Original Message- > > >> From: Carlos Santana [mailto:csantan...@gmail.com] > > >> Sent: Wednesday, September 30, 2015 2:07 PM > > >> To: dev@cordova.apache.org > > >> Subject: Re: [Discuss] Cordova-common release > > >> > > >> Yes temporary, maybe we can discuss some more in F2F > > >> > > >> I still do not understand what are you trying to solve by having > > >> all that content published as big blob. > > >> > > >> If the packages are only for Cordova components to depend on then > > >> we control the release and we can include them easily
Re: [Discuss] Cordova-common release
OK, how will this impact the 5.0 release of Android? On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal wrote: > It got checked in earlier this morning. > > -Nikhil > > -Original Message- > From: Joe Bowser [mailto:bows...@gmail.com] > Sent: Tuesday, October 20, 2015 2:34 PM > To: dev > Subject: Re: [Discuss] Cordova-common release > > So, when did the PlatformAPI change land in Android? > > On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N > wrote: > > > +1 - YES please. Requiring cordoba-common for my > > react-native-cordova-plugin adapter was a nightmare !! > > > > > > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" > wrote: > > > > >+1 to publishing cordova-common to npm. > > > > > >-Nikhil > > > > > >-Original Message----- > > >From: Steven Gill [mailto:stevengil...@gmail.com] > > >Sent: Tuesday, October 20, 2015 2:20 PM > > >To: dev@cordova.apache.org > > >Subject: Re: [Discuss] Cordova-common release > > > > > >I want to revisit this. > > > > > >So cordova-android has a dependency now on cordova-common. It is a > > bundledDependency so when we generate a tar to release > > cordova-android, it will be included. It will also be in the > > cordova-android package that gets downloaded with cordova platform add. > > > > > >This is fine for released work, but more annoying for development. I > > >need > > to npm link cordova-common into cordova-android (and soon every > > platform which implements common platformAPI). We could check in > > cordova-common into cordova-android but that isn't a great solution > either. > > > > > >I agree that we should be going towards smaller modules and not > > >having a > > case of cordovaLib1, cordovaLib2, etc. I think this is still going to > > be a work in progress and will take some time. > > > > > >For the interim, I recommend we publish cordova-common. Of course, > > continue to add it as a bundledDependency so users don't need to npm > > install it with released packages. > > > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > > v-vlk...@microsoft.com> wrote: > > > > > >> > I still do not understand what are you trying to solve by having > > >> > all > > >> that content published as big blob. > > >> Code deduplication is the main reason. All the things from > > >> 'cordova-common' will be used by platforms intensively, so we need > > >> to share this code and keep it separately from LIB to share easily. > > >> Publishing is basically doesn't required for this, and bundling > > >> 'cordova-common' into LIB is enough for this purpose. > > >> > > >> Another reason was that third-party tool might want to use some of > > >> this functionality (like your example with ConfigParser), so we > > >> need to have this package on NPM to allow them to get it. For this > > >> case I now do agree with you that separate packages for > > >> ConfigParser, PluginInfo and other stuff looks better than putting > > >> it into one big > > package. > > >> > > >> - > > >> Best regards, Vladimir > > >> > > >> > > >> -Original Message- > > >> From: Carlos Santana [mailto:csantan...@gmail.com] > > >> Sent: Wednesday, September 30, 2015 2:07 PM > > >> To: dev@cordova.apache.org > > >> Subject: Re: [Discuss] Cordova-common release > > >> > > >> Yes temporary, maybe we can discuss some more in F2F > > >> > > >> I still do not understand what are you trying to solve by having > > >> all that content published as big blob. > > >> > > >> If the packages are only for Cordova components to depend on then > > >> we control the release and we can include them easily. > > >> > > >> If the code is to be share by third party or anyone out there then > > >> it make sense to put in npm. > > >> > > >> One concrete example is cordova-configparser, Our IBM tool is using > > >> it in our own models code so today we taking a copy, if it's > > >> available thru npm then we can stated as a dependency and manage it > > >> as a npm package vs a loosely node module js file > > >> > > >> Maybe not all classes need to be conve
RE: [Discuss] Cordova-common release
It got checked in earlier this morning. -Nikhil -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Tuesday, October 20, 2015 2:34 PM To: dev Subject: Re: [Discuss] Cordova-common release So, when did the PlatformAPI change land in Android? On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N wrote: > +1 - YES please. Requiring cordoba-common for my > react-native-cordova-plugin adapter was a nightmare !! > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" wrote: > > >+1 to publishing cordova-common to npm. > > > >-Nikhil > > > >-Original Message- > >From: Steven Gill [mailto:stevengil...@gmail.com] > >Sent: Tuesday, October 20, 2015 2:20 PM > >To: dev@cordova.apache.org > >Subject: Re: [Discuss] Cordova-common release > > > >I want to revisit this. > > > >So cordova-android has a dependency now on cordova-common. It is a > bundledDependency so when we generate a tar to release > cordova-android, it will be included. It will also be in the > cordova-android package that gets downloaded with cordova platform add. > > > >This is fine for released work, but more annoying for development. I > >need > to npm link cordova-common into cordova-android (and soon every > platform which implements common platformAPI). We could check in > cordova-common into cordova-android but that isn't a great solution either. > > > >I agree that we should be going towards smaller modules and not > >having a > case of cordovaLib1, cordovaLib2, etc. I think this is still going to > be a work in progress and will take some time. > > > >For the interim, I recommend we publish cordova-common. Of course, > continue to add it as a bundledDependency so users don't need to npm > install it with released packages. > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > >> > I still do not understand what are you trying to solve by having > >> > all > >> that content published as big blob. > >> Code deduplication is the main reason. All the things from > >> 'cordova-common' will be used by platforms intensively, so we need > >> to share this code and keep it separately from LIB to share easily. > >> Publishing is basically doesn't required for this, and bundling > >> 'cordova-common' into LIB is enough for this purpose. > >> > >> Another reason was that third-party tool might want to use some of > >> this functionality (like your example with ConfigParser), so we > >> need to have this package on NPM to allow them to get it. For this > >> case I now do agree with you that separate packages for > >> ConfigParser, PluginInfo and other stuff looks better than putting > >> it into one big > package. > >> > >> - > >> Best regards, Vladimir > >> > >> > >> -Original Message- > >> From: Carlos Santana [mailto:csantan...@gmail.com] > >> Sent: Wednesday, September 30, 2015 2:07 PM > >> To: dev@cordova.apache.org > >> Subject: Re: [Discuss] Cordova-common release > >> > >> Yes temporary, maybe we can discuss some more in F2F > >> > >> I still do not understand what are you trying to solve by having > >> all that content published as big blob. > >> > >> If the packages are only for Cordova components to depend on then > >> we control the release and we can include them easily. > >> > >> If the code is to be share by third party or anyone out there then > >> it make sense to put in npm. > >> > >> One concrete example is cordova-configparser, Our IBM tool is using > >> it in our own models code so today we taking a copy, if it's > >> available thru npm then we can stated as a dependency and manage it > >> as a npm package vs a loosely node module js file > >> > >> Maybe not all classes need to be converted to npm packages maybe it > >> can be some cordova-configparser cordova-utils cordova-helper > >> > >> Also do some refactoring and dependency cleaning, I saw a node > >> module dependeding on underscore and the file only had one simple > >> call to > >> _.find() > >> > >> We were going to use that module, but then decided not to since it > >> depended on underscore for a simple thing, this creates legal > >> clearance work and more dependencies we need to include in our > >> product makin
Re: [Discuss] Cordova-common release
So, when did the PlatformAPI change land in Android? On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N wrote: > +1 - YES please. Requiring cordoba-common for my > react-native-cordova-plugin adapter was a nightmare !! > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" wrote: > > >+1 to publishing cordova-common to npm. > > > >-Nikhil > > > >-Original Message- > >From: Steven Gill [mailto:stevengil...@gmail.com] > >Sent: Tuesday, October 20, 2015 2:20 PM > >To: dev@cordova.apache.org > >Subject: Re: [Discuss] Cordova-common release > > > >I want to revisit this. > > > >So cordova-android has a dependency now on cordova-common. It is a > bundledDependency so when we generate a tar to release cordova-android, it > will be included. It will also be in the cordova-android package that gets > downloaded with cordova platform add. > > > >This is fine for released work, but more annoying for development. I need > to npm link cordova-common into cordova-android (and soon every platform > which implements common platformAPI). We could check in cordova-common into > cordova-android but that isn't a great solution either. > > > >I agree that we should be going towards smaller modules and not having a > case of cordovaLib1, cordovaLib2, etc. I think this is still going to be a > work in progress and will take some time. > > > >For the interim, I recommend we publish cordova-common. Of course, > continue to add it as a bundledDependency so users don't need to npm > install it with released packages. > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > >> > I still do not understand what are you trying to solve by having all > >> that content published as big blob. > >> Code deduplication is the main reason. All the things from > >> 'cordova-common' will be used by platforms intensively, so we need to > >> share this code and keep it separately from LIB to share easily. > >> Publishing is basically doesn't required for this, and bundling > >> 'cordova-common' into LIB is enough for this purpose. > >> > >> Another reason was that third-party tool might want to use some of > >> this functionality (like your example with ConfigParser), so we need > >> to have this package on NPM to allow them to get it. For this case I > >> now do agree with you that separate packages for ConfigParser, > >> PluginInfo and other stuff looks better than putting it into one big > package. > >> > >> - > >> Best regards, Vladimir > >> > >> > >> -Original Message- > >> From: Carlos Santana [mailto:csantan...@gmail.com] > >> Sent: Wednesday, September 30, 2015 2:07 PM > >> To: dev@cordova.apache.org > >> Subject: Re: [Discuss] Cordova-common release > >> > >> Yes temporary, maybe we can discuss some more in F2F > >> > >> I still do not understand what are you trying to solve by having all > >> that content published as big blob. > >> > >> If the packages are only for Cordova components to depend on then we > >> control the release and we can include them easily. > >> > >> If the code is to be share by third party or anyone out there then it > >> make sense to put in npm. > >> > >> One concrete example is cordova-configparser, Our IBM tool is using it > >> in our own models code so today we taking a copy, if it's available > >> thru npm then we can stated as a dependency and manage it as a npm > >> package vs a loosely node module js file > >> > >> Maybe not all classes need to be converted to npm packages maybe it > >> can be some cordova-configparser cordova-utils cordova-helper > >> > >> Also do some refactoring and dependency cleaning, I saw a node module > >> dependeding on underscore and the file only had one simple call to > >> _.find() > >> > >> We were going to use that module, but then decided not to since it > >> depended on underscore for a simple thing, this creates legal > >> clearance work and more dependencies we need to include in our product > >> making our download larger. > >> > >> And yes, yes we bundle all our dependencies when we go into production. > >> > >> - Carlos > >> Sent from my iPhone > >> > >> > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) < > >
Re: [Discuss] Cordova-common release
+1 - YES please. Requiring cordoba-common for my react-native-cordova-plugin adapter was a nightmare !! On 10/20/15, 2:23 PM, "Nikhil Khandelwal" wrote: >+1 to publishing cordova-common to npm. > >-Nikhil > >-Original Message- >From: Steven Gill [mailto:stevengil...@gmail.com] >Sent: Tuesday, October 20, 2015 2:20 PM >To: dev@cordova.apache.org >Subject: Re: [Discuss] Cordova-common release > >I want to revisit this. > >So cordova-android has a dependency now on cordova-common. It is a >bundledDependency so when we generate a tar to release cordova-android, it >will be included. It will also be in the cordova-android package that gets >downloaded with cordova platform add. > >This is fine for released work, but more annoying for development. I need to >npm link cordova-common into cordova-android (and soon every platform which >implements common platformAPI). We could check in cordova-common into >cordova-android but that isn't a great solution either. > >I agree that we should be going towards smaller modules and not having a case >of cordovaLib1, cordovaLib2, etc. I think this is still going to be a work in >progress and will take some time. > >For the interim, I recommend we publish cordova-common. Of course, continue to >add it as a bundledDependency so users don't need to npm install it with >released packages. > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < >v-vlk...@microsoft.com> wrote: > >> > I still do not understand what are you trying to solve by having all >> that content published as big blob. >> Code deduplication is the main reason. All the things from >> 'cordova-common' will be used by platforms intensively, so we need to >> share this code and keep it separately from LIB to share easily. >> Publishing is basically doesn't required for this, and bundling >> 'cordova-common' into LIB is enough for this purpose. >> >> Another reason was that third-party tool might want to use some of >> this functionality (like your example with ConfigParser), so we need >> to have this package on NPM to allow them to get it. For this case I >> now do agree with you that separate packages for ConfigParser, >> PluginInfo and other stuff looks better than putting it into one big package. >> >> - >> Best regards, Vladimir >> >> >> -Original Message- >> From: Carlos Santana [mailto:csantan...@gmail.com] >> Sent: Wednesday, September 30, 2015 2:07 PM >> To: dev@cordova.apache.org >> Subject: Re: [Discuss] Cordova-common release >> >> Yes temporary, maybe we can discuss some more in F2F >> >> I still do not understand what are you trying to solve by having all >> that content published as big blob. >> >> If the packages are only for Cordova components to depend on then we >> control the release and we can include them easily. >> >> If the code is to be share by third party or anyone out there then it >> make sense to put in npm. >> >> One concrete example is cordova-configparser, Our IBM tool is using it >> in our own models code so today we taking a copy, if it's available >> thru npm then we can stated as a dependency and manage it as a npm >> package vs a loosely node module js file >> >> Maybe not all classes need to be converted to npm packages maybe it >> can be some cordova-configparser cordova-utils cordova-helper >> >> Also do some refactoring and dependency cleaning, I saw a node module >> dependeding on underscore and the file only had one simple call to >> _.find() >> >> We were going to use that module, but then decided not to since it >> depended on underscore for a simple thing, this creates legal >> clearance work and more dependencies we need to include in our product >> making our download larger. >> >> And yes, yes we bundle all our dependencies when we go into production. >> >> - Carlos >> Sent from my iPhone >> >> > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) < >> v-vlk...@microsoft.com> wrote: >> > >> > Including cordova-common as bundled dependency should be enough in >> > our >> case. Changes to coho are submitted already [1], so we only need to >> update package.json for cordova-lib. >> > >> > Personally for me bundling looks like a temporary workaround before >> > we >> get all those partials of 'common' published to npm, am I right? >> > >> > [1] >> > https://na01.safelinks.prot
RE: [Discuss] Cordova-common release
+1 to publishing cordova-common to npm. -Nikhil -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Tuesday, October 20, 2015 2:20 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release I want to revisit this. So cordova-android has a dependency now on cordova-common. It is a bundledDependency so when we generate a tar to release cordova-android, it will be included. It will also be in the cordova-android package that gets downloaded with cordova platform add. This is fine for released work, but more annoying for development. I need to npm link cordova-common into cordova-android (and soon every platform which implements common platformAPI). We could check in cordova-common into cordova-android but that isn't a great solution either. I agree that we should be going towards smaller modules and not having a case of cordovaLib1, cordovaLib2, etc. I think this is still going to be a work in progress and will take some time. For the interim, I recommend we publish cordova-common. Of course, continue to add it as a bundledDependency so users don't need to npm install it with released packages. On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < v-vlk...@microsoft.com> wrote: > > I still do not understand what are you trying to solve by having all > that content published as big blob. > Code deduplication is the main reason. All the things from > 'cordova-common' will be used by platforms intensively, so we need to > share this code and keep it separately from LIB to share easily. > Publishing is basically doesn't required for this, and bundling > 'cordova-common' into LIB is enough for this purpose. > > Another reason was that third-party tool might want to use some of > this functionality (like your example with ConfigParser), so we need > to have this package on NPM to allow them to get it. For this case I > now do agree with you that separate packages for ConfigParser, > PluginInfo and other stuff looks better than putting it into one big package. > > - > Best regards, Vladimir > > > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Wednesday, September 30, 2015 2:07 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Yes temporary, maybe we can discuss some more in F2F > > I still do not understand what are you trying to solve by having all > that content published as big blob. > > If the packages are only for Cordova components to depend on then we > control the release and we can include them easily. > > If the code is to be share by third party or anyone out there then it > make sense to put in npm. > > One concrete example is cordova-configparser, Our IBM tool is using it > in our own models code so today we taking a copy, if it's available > thru npm then we can stated as a dependency and manage it as a npm > package vs a loosely node module js file > > Maybe not all classes need to be converted to npm packages maybe it > can be some cordova-configparser cordova-utils cordova-helper > > Also do some refactoring and dependency cleaning, I saw a node module > dependeding on underscore and the file only had one simple call to > _.find() > > We were going to use that module, but then decided not to since it > depended on underscore for a simple thing, this creates legal > clearance work and more dependencies we need to include in our product > making our download larger. > > And yes, yes we bundle all our dependencies when we go into production. > > - Carlos > Sent from my iPhone > > > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > > Including cordova-common as bundled dependency should be enough in > > our > case. Changes to coho are submitted already [1], so we only need to > update package.json for cordova-lib. > > > > Personally for me bundling looks like a temporary workaround before > > we > get all those partials of 'common' published to npm, am I right? > > > > [1] > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit > > hu > > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%40 > > 06 > > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86 > > f1 > > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2b > > do > > 9WX4V4JfT0%3d > > > > - > > Best regards, Vladimir. > > > > -Original Message- > > From: Carlos Santana [mailto:csantan...@gmail.com] > > Sent: Tuesday, September 29, 2015 9:15 PM > &g
Re: [Discuss] Cordova-common release
I want to revisit this. So cordova-android has a dependency now on cordova-common. It is a bundledDependency so when we generate a tar to release cordova-android, it will be included. It will also be in the cordova-android package that gets downloaded with cordova platform add. This is fine for released work, but more annoying for development. I need to npm link cordova-common into cordova-android (and soon every platform which implements common platformAPI). We could check in cordova-common into cordova-android but that isn't a great solution either. I agree that we should be going towards smaller modules and not having a case of cordovaLib1, cordovaLib2, etc. I think this is still going to be a work in progress and will take some time. For the interim, I recommend we publish cordova-common. Of course, continue to add it as a bundledDependency so users don't need to npm install it with released packages. On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < v-vlk...@microsoft.com> wrote: > > I still do not understand what are you trying to solve by having all > that content published as big blob. > Code deduplication is the main reason. All the things from > 'cordova-common' will be used by platforms intensively, so we need to share > this code and keep it separately from LIB to share easily. Publishing is > basically doesn't required for this, and bundling 'cordova-common' into LIB > is enough for this purpose. > > Another reason was that third-party tool might want to use some of this > functionality (like your example with ConfigParser), so we need to have > this package on NPM to allow them to get it. For this case I now do agree > with you that separate packages for ConfigParser, PluginInfo and other > stuff looks better than putting it into one big package. > > - > Best regards, Vladimir > > > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Wednesday, September 30, 2015 2:07 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Yes temporary, maybe we can discuss some more in F2F > > I still do not understand what are you trying to solve by having all that > content published as big blob. > > If the packages are only for Cordova components to depend on then we > control the release and we can include them easily. > > If the code is to be share by third party or anyone out there then it make > sense to put in npm. > > One concrete example is cordova-configparser, Our IBM tool is using it in > our own models code so today we taking a copy, if it's available thru npm > then we can stated as a dependency and manage it as a npm package vs a > loosely node module js file > > Maybe not all classes need to be converted to npm packages maybe it can be > some cordova-configparser cordova-utils cordova-helper > > Also do some refactoring and dependency cleaning, I saw a node module > dependeding on underscore and the file only had one simple call to _.find() > > We were going to use that module, but then decided not to since it > depended on underscore for a simple thing, this creates legal clearance > work and more dependencies we need to include in our product making our > download larger. > > And yes, yes we bundle all our dependencies when we go into production. > > - Carlos > Sent from my iPhone > > > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > > Including cordova-common as bundled dependency should be enough in our > case. Changes to coho are submitted already [1], so we only need to update > package.json for cordova-lib. > > > > Personally for me bundling looks like a temporary workaround before we > get all those partials of 'common' published to npm, am I right? > > > > [1] > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%4006 > > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1 > > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2bdo > > 9WX4V4JfT0%3d > > > > - > > Best regards, Vladimir. > > > > -Original Message- > > From: Carlos Santana [mailto:csantan...@gmail.com] > > Sent: Tuesday, September 29, 2015 9:15 PM > > To: dev@cordova.apache.org > > Subject: Re: [Discuss] Cordova-common release > > > > Do we need to absolutely publish this to npm? > > > > Can we just include the dependency in the platform as a bundle > dependency? > > > > We just need to update coho to npm install/link the cordoba-common >
RE: [Discuss] Cordova-common release
> I still do not understand what are you trying to solve by having all that > content published as big blob. Code deduplication is the main reason. All the things from 'cordova-common' will be used by platforms intensively, so we need to share this code and keep it separately from LIB to share easily. Publishing is basically doesn't required for this, and bundling 'cordova-common' into LIB is enough for this purpose. Another reason was that third-party tool might want to use some of this functionality (like your example with ConfigParser), so we need to have this package on NPM to allow them to get it. For this case I now do agree with you that separate packages for ConfigParser, PluginInfo and other stuff looks better than putting it into one big package. - Best regards, Vladimir -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Wednesday, September 30, 2015 2:07 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release Yes temporary, maybe we can discuss some more in F2F I still do not understand what are you trying to solve by having all that content published as big blob. If the packages are only for Cordova components to depend on then we control the release and we can include them easily. If the code is to be share by third party or anyone out there then it make sense to put in npm. One concrete example is cordova-configparser, Our IBM tool is using it in our own models code so today we taking a copy, if it's available thru npm then we can stated as a dependency and manage it as a npm package vs a loosely node module js file Maybe not all classes need to be converted to npm packages maybe it can be some cordova-configparser cordova-utils cordova-helper Also do some refactoring and dependency cleaning, I saw a node module dependeding on underscore and the file only had one simple call to _.find() We were going to use that module, but then decided not to since it depended on underscore for a simple thing, this creates legal clearance work and more dependencies we need to include in our product making our download larger. And yes, yes we bundle all our dependencies when we go into production. - Carlos Sent from my iPhone > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) > wrote: > > Including cordova-common as bundled dependency should be enough in our case. > Changes to coho are submitted already [1], so we only need to update > package.json for cordova-lib. > > Personally for me bundling looks like a temporary workaround before we get > all those partials of 'common' published to npm, am I right? > > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%4006 > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1 > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2bdo > 9WX4V4JfT0%3d > > - > Best regards, Vladimir. > > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Tuesday, September 29, 2015 9:15 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Do we need to absolutely publish this to npm? > > Can we just include the dependency in the platform as a bundle dependency? > > We just need to update coho to npm install/link the cordoba-common > package when doing a release of what ever component need it? (i.e. > cordova-android) > > Will this get you what you want? Why does it absolutely need to be in npm > registry? > > I really don't think will be a good idea to publish two npm packages > "cordova-lib" and "cordova-common" > > Sorry if I'm being a pain in the ass, maybe I'm something obvious here > > >> On Tue, Sep 29, 2015 at 1:34 PM Steven Gill wrote: >> >> Sounds good. Let's move forward >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" >> >> wrote: >> >>> +1. I understand the value of Carlos' proposal, but in the spirit of >>> moving forward with this which is fairly complicated refactor >>> involving multiple releases and repos, I would like us to make >>> progress on this >> soon >>> and not add significant scope to this effort. >>> >>> >>> -Nikhil >>> >>> -Original Message- >>> From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] >>> Sent: Tuesday, September 29, 2015 1:34 AM >>> To: dev@cordova.apache.org >>> Subject: RE: [Discuss] Cordova-common release >>> >>> +1 >>> >>> -Original Message--
Re: [Discuss] Cordova-common release
Yes temporary, maybe we can discuss some more in F2F I still do not understand what are you trying to solve by having all that content published as big blob. If the packages are only for Cordova components to depend on then we control the release and we can include them easily. If the code is to be share by third party or anyone out there then it make sense to put in npm. One concrete example is cordova-configparser, Our IBM tool is using it in our own models code so today we taking a copy, if it's available thru npm then we can stated as a dependency and manage it as a npm package vs a loosely node module js file Maybe not all classes need to be converted to npm packages maybe it can be some cordova-configparser cordova-utils cordova-helper Also do some refactoring and dependency cleaning, I saw a node module dependeding on underscore and the file only had one simple call to _.find() We were going to use that module, but then decided not to since it depended on underscore for a simple thing, this creates legal clearance work and more dependencies we need to include in our product making our download larger. And yes, yes we bundle all our dependencies when we go into production. - Carlos Sent from my iPhone > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) > wrote: > > Including cordova-common as bundled dependency should be enough in our case. > Changes to coho are submitted already [1], so we only need to update > package.json for cordova-lib. > > Personally for me bundling looks like a temporary workaround before we get > all those partials of 'common' published to npm, am I right? > > [1] https://github.com/apache/cordova-coho/pull/94 > > - > Best regards, Vladimir. > > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Tuesday, September 29, 2015 9:15 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Do we need to absolutely publish this to npm? > > Can we just include the dependency in the platform as a bundle dependency? > > We just need to update coho to npm install/link the cordoba-common package > when doing a release of what ever component need it? (i.e. cordova-android) > > Will this get you what you want? Why does it absolutely need to be in npm > registry? > > I really don't think will be a good idea to publish two npm packages > "cordova-lib" and "cordova-common" > > Sorry if I'm being a pain in the ass, maybe I'm something obvious here > > >> On Tue, Sep 29, 2015 at 1:34 PM Steven Gill wrote: >> >> Sounds good. Let's move forward >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" >> wrote: >> >>> +1. I understand the value of Carlos' proposal, but in the spirit of >>> moving forward with this which is fairly complicated refactor >>> involving multiple releases and repos, I would like us to make >>> progress on this >> soon >>> and not add significant scope to this effort. >>> >>> >>> -Nikhil >>> >>> -Original Message- >>> From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] >>> Sent: Tuesday, September 29, 2015 1:34 AM >>> To: dev@cordova.apache.org >>> Subject: RE: [Discuss] Cordova-common release >>> >>> +1 >>> >>> -Original Message- >>> From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] >>> Sent: Tuesday, September 29, 2015 11:27 AM >>> To: dev@cordova.apache.org >>> Subject: RE: [Discuss] Cordova-common release >>> >>> Agree with you, guys. >>> >>> Unfortunately, the underlying modules in `cordova-common` are not >>> really atomic, since they depending on each other. For example >>> ConfigParser requires `xmlHelpers`, `events` and `CordovaError` as a >>> dependencies. >>> Reworking them to be truly separated might be sort of problematic, >>> especially in context of message logging (as they use shared event >> emitter >>> to log output to console). >>> >>> So I still propose is to release `common` module as-is and then >>> gradually move inner modules out to separate packages. >>> >>> - >>> Best regards, Vladimir. >>> >>> -Original Message- >>> From: Carlos Santana [mailto:csantan...@gmail.com] >>> Sent: Friday, September 25, 2015 7:33 PM >>> To: dev@cordova.apache.org >>> Subject: Re: [Discuss] Cordova-common release >>> >>> Sorry a typo >>> to u
RE: [Discuss] Cordova-common release
Including cordova-common as bundled dependency should be enough in our case. Changes to coho are submitted already [1], so we only need to update package.json for cordova-lib. Personally for me bundling looks like a temporary workaround before we get all those partials of 'common' published to npm, am I right? [1] https://github.com/apache/cordova-coho/pull/94 - Best regards, Vladimir. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Tuesday, September 29, 2015 9:15 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release Do we need to absolutely publish this to npm? Can we just include the dependency in the platform as a bundle dependency? We just need to update coho to npm install/link the cordoba-common package when doing a release of what ever component need it? (i.e. cordova-android) Will this get you what you want? Why does it absolutely need to be in npm registry? I really don't think will be a good idea to publish two npm packages "cordova-lib" and "cordova-common" Sorry if I'm being a pain in the ass, maybe I'm something obvious here On Tue, Sep 29, 2015 at 1:34 PM Steven Gill wrote: > Sounds good. Let's move forward > On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" > wrote: > > > +1. I understand the value of Carlos' proposal, but in the spirit of > > moving forward with this which is fairly complicated refactor > > involving multiple releases and repos, I would like us to make > > progress on this > soon > > and not add significant scope to this effort. > > > > > > -Nikhil > > > > -Original Message- > > From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] > > Sent: Tuesday, September 29, 2015 1:34 AM > > To: dev@cordova.apache.org > > Subject: RE: [Discuss] Cordova-common release > > > > +1 > > > > -----Original Message- > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > Sent: Tuesday, September 29, 2015 11:27 AM > > To: dev@cordova.apache.org > > Subject: RE: [Discuss] Cordova-common release > > > > Agree with you, guys. > > > > Unfortunately, the underlying modules in `cordova-common` are not > > really atomic, since they depending on each other. For example > > ConfigParser requires `xmlHelpers`, `events` and `CordovaError` as a > > dependencies. > > Reworking them to be truly separated might be sort of problematic, > > especially in context of message logging (as they use shared event > emitter > > to log output to console). > > > > So I still propose is to release `common` module as-is and then > > gradually move inner modules out to separate packages. > > > > - > > Best regards, Vladimir. > > > > -Original Message- > > From: Carlos Santana [mailto:csantan...@gmail.com] > > Sent: Friday, September 25, 2015 7:33 PM > > To: dev@cordova.apache.org > > Subject: Re: [Discuss] Cordova-common release > > > > Sorry a typo > > to use "bundleDependencies" you will have a node_modules/ directory > > directly under "common/node_modules/cordova-error/" > > > > and the the small modules (i.e. cordoba-util, cordova-plugin-info, > > etc..) will be located there. > > > > then have explicit ignores for the dependencies you don't want to be > > source control like npm [2] > > > > [2]: > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv- > vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c7 > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qE > CnvsbnsJ%2bvEriJvqYcU%3d > > > > > > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana > > > > wrote: > > > > > Yes after reviewing the changes, I understood the purpose of the > > > code that you seperated to avoid duplicate code between the other > > > top level modules (i.e. platforms, lib, cli) > > > > > > I still think small modules is the way to go. > > > > > > Don't let process, bureaucracy, and ceremony hamper the > > > engineering process and the consumer UX using this modules. (yeah > > > that came out from the mouth of an IBMer ;-p) > > > > > > Yes, I'm not blind, I understand the voting, the releasing, the > > > packaging the publish steps > > > > > > The way I look at it no matter what you do you are not going to > > > make it easier by
Re: [Discuss] Cordova-common release
Do we need to absolutely publish this to npm? Can we just include the dependency in the platform as a bundle dependency? We just need to update coho to npm install/link the cordoba-common package when doing a release of what ever component need it? (i.e. cordova-android) Will this get you what you want? Why does it absolutely need to be in npm registry? I really don't think will be a good idea to publish two npm packages "cordova-lib" and "cordova-common" Sorry if I'm being a pain in the ass, maybe I'm something obvious here On Tue, Sep 29, 2015 at 1:34 PM Steven Gill wrote: > Sounds good. Let's move forward > On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" > wrote: > > > +1. I understand the value of Carlos' proposal, but in the spirit of > > moving forward with this which is fairly complicated refactor involving > > multiple releases and repos, I would like us to make progress on this > soon > > and not add significant scope to this effort. > > > > > > -Nikhil > > > > -Original Message- > > From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] > > Sent: Tuesday, September 29, 2015 1:34 AM > > To: dev@cordova.apache.org > > Subject: RE: [Discuss] Cordova-common release > > > > +1 > > > > -Original Message- > > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > > Sent: Tuesday, September 29, 2015 11:27 AM > > To: dev@cordova.apache.org > > Subject: RE: [Discuss] Cordova-common release > > > > Agree with you, guys. > > > > Unfortunately, the underlying modules in `cordova-common` are not really > > atomic, since they depending on each other. For example ConfigParser > > requires `xmlHelpers`, `events` and `CordovaError` as a dependencies. > > Reworking them to be truly separated might be sort of problematic, > > especially in context of message logging (as they use shared event > emitter > > to log output to console). > > > > So I still propose is to release `common` module as-is and then gradually > > move inner modules out to separate packages. > > > > - > > Best regards, Vladimir. > > > > -Original Message- > > From: Carlos Santana [mailto:csantan...@gmail.com] > > Sent: Friday, September 25, 2015 7:33 PM > > To: dev@cordova.apache.org > > Subject: Re: [Discuss] Cordova-common release > > > > Sorry a typo > > to use "bundleDependencies" you will have a node_modules/ directory > > directly under "common/node_modules/cordova-error/" > > > > and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) > > will be located there. > > > > then have explicit ignores for the dependencies you don't want to be > > source control like npm [2] > > > > [2]: > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d > > > > > > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana > > wrote: > > > > > Yes after reviewing the changes, I understood the purpose of the code > > > that you seperated to avoid duplicate code between the other top level > > > modules (i.e. platforms, lib, cli) > > > > > > I still think small modules is the way to go. > > > > > > Don't let process, bureaucracy, and ceremony hamper the engineering > > > process and the consumer UX using this modules. (yeah that came out > > > from the mouth of an IBMer ;-p) > > > > > > Yes, I'm not blind, I understand the voting, the releasing, the > > > packaging the publish steps > > > > > > The way I look at it no matter what you do you are not going to make > > > it easier by having one "common" package. > > > > > > Let's say you just need to update a file to fix a bug from Error, well > > > you need to test, vote, release, "common" > > > Next you want to fix a bug in configparser, guess what you need to > > > tests, vote, release "common" again But if only config parser changed > > > all the rest of the code in "common" > > > needs to be tested and release, and consumer will need to pick a new > > > common for only a small bug fix in a portion of "common" > > > > > > Basically that's what w
RE: [Discuss] Cordova-common release
Sounds good. Let's move forward On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" wrote: > +1. I understand the value of Carlos' proposal, but in the spirit of > moving forward with this which is fairly complicated refactor involving > multiple releases and repos, I would like us to make progress on this soon > and not add significant scope to this effort. > > > -Nikhil > > -Original Message- > From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] > Sent: Tuesday, September 29, 2015 1:34 AM > To: dev@cordova.apache.org > Subject: RE: [Discuss] Cordova-common release > > +1 > > -Original Message- > From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] > Sent: Tuesday, September 29, 2015 11:27 AM > To: dev@cordova.apache.org > Subject: RE: [Discuss] Cordova-common release > > Agree with you, guys. > > Unfortunately, the underlying modules in `cordova-common` are not really > atomic, since they depending on each other. For example ConfigParser > requires `xmlHelpers`, `events` and `CordovaError` as a dependencies. > Reworking them to be truly separated might be sort of problematic, > especially in context of message logging (as they use shared event emitter > to log output to console). > > So I still propose is to release `common` module as-is and then gradually > move inner modules out to separate packages. > > - > Best regards, Vladimir. > > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Friday, September 25, 2015 7:33 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Sorry a typo > to use "bundleDependencies" you will have a node_modules/ directory > directly under "common/node_modules/cordova-error/" > > and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) > will be located there. > > then have explicit ignores for the dependencies you don't want to be > source control like npm [2] > > [2]: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d > > > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana > wrote: > > > Yes after reviewing the changes, I understood the purpose of the code > > that you seperated to avoid duplicate code between the other top level > > modules (i.e. platforms, lib, cli) > > > > I still think small modules is the way to go. > > > > Don't let process, bureaucracy, and ceremony hamper the engineering > > process and the consumer UX using this modules. (yeah that came out > > from the mouth of an IBMer ;-p) > > > > Yes, I'm not blind, I understand the voting, the releasing, the > > packaging the publish steps > > > > The way I look at it no matter what you do you are not going to make > > it easier by having one "common" package. > > > > Let's say you just need to update a file to fix a bug from Error, well > > you need to test, vote, release, "common" > > Next you want to fix a bug in configparser, guess what you need to > > tests, vote, release "common" again But if only config parser changed > > all the rest of the code in "common" > > needs to be tested and release, and consumer will need to pick a new > > common for only a small bug fix in a portion of "common" > > > > Basically that's what we have today, the way I see it you are just > > creating two libs "lib" and "lib2" > > > > With large number of small modules, lets say we create 8 now, maybe > > only 2 change most of the time, and the other 5 are so basic and small > > that they never change and stay at version 1.0.0 for long time. > > > > I think for this small modules, I don't think we have to do the blog > > post, twitter things, those I will continue to have for the large > > components (cli, platforms, plugins) > > > > Also the side effect I would like to see, is clean APIs edges, each > > small module provides an API, it contain tests to that API, and lib > > contain integration tests as a whole. > > > > Maybe the compromise for now, to move forward let's break the > > functions into "npm packages" inside this "common" where each sub > > directory inside common is a npm package with a single entry point > > (index.js) and common package.js
RE: [Discuss] Cordova-common release
+1. I understand the value of Carlos' proposal, but in the spirit of moving forward with this which is fairly complicated refactor involving multiple releases and repos, I would like us to make progress on this soon and not add significant scope to this effort. -Nikhil -Original Message- From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] Sent: Tuesday, September 29, 2015 1:34 AM To: dev@cordova.apache.org Subject: RE: [Discuss] Cordova-common release +1 -Original Message- From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] Sent: Tuesday, September 29, 2015 11:27 AM To: dev@cordova.apache.org Subject: RE: [Discuss] Cordova-common release Agree with you, guys. Unfortunately, the underlying modules in `cordova-common` are not really atomic, since they depending on each other. For example ConfigParser requires `xmlHelpers`, `events` and `CordovaError` as a dependencies. Reworking them to be truly separated might be sort of problematic, especially in context of message logging (as they use shared event emitter to log output to console). So I still propose is to release `common` module as-is and then gradually move inner modules out to separate packages. - Best regards, Vladimir. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Friday, September 25, 2015 7:33 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release Sorry a typo to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/" and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there. then have explicit ignores for the dependencies you don't want to be source control like npm [2] [2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana wrote: > Yes after reviewing the changes, I understood the purpose of the code > that you seperated to avoid duplicate code between the other top level > modules (i.e. platforms, lib, cli) > > I still think small modules is the way to go. > > Don't let process, bureaucracy, and ceremony hamper the engineering > process and the consumer UX using this modules. (yeah that came out > from the mouth of an IBMer ;-p) > > Yes, I'm not blind, I understand the voting, the releasing, the > packaging the publish steps > > The way I look at it no matter what you do you are not going to make > it easier by having one "common" package. > > Let's say you just need to update a file to fix a bug from Error, well > you need to test, vote, release, "common" > Next you want to fix a bug in configparser, guess what you need to > tests, vote, release "common" again But if only config parser changed > all the rest of the code in "common" > needs to be tested and release, and consumer will need to pick a new > common for only a small bug fix in a portion of "common" > > Basically that's what we have today, the way I see it you are just > creating two libs "lib" and "lib2" > > With large number of small modules, lets say we create 8 now, maybe > only 2 change most of the time, and the other 5 are so basic and small > that they never change and stay at version 1.0.0 for long time. > > I think for this small modules, I don't think we have to do the blog > post, twitter things, those I will continue to have for the large > components (cli, platforms, plugins) > > Also the side effect I would like to see, is clean APIs edges, each > small module provides an API, it contain tests to that API, and lib > contain integration tests as a whole. > > Maybe the compromise for now, to move forward let's break the > functions into "npm packages" inside this "common" where each sub > directory inside common is a npm package with a single entry point > (index.js) and common package.json have them as "bundleDependencies", > similar way as npm does [1] > > the transition will be for consumers for their dependencies and the > way they consume the API > dependencies: { >cordova-common: "1.0.0" > } > cordova-common only expose one index.js with the APIs to the other > modules > > var cdvUtil = require("cordova-common").cordova-util > cdvPluginInfo = require("cordova-common").cordova-plugin-info, > cdvError = require("cord
RE: [Discuss] Cordova-common release
+1 -Original Message- From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com] Sent: Tuesday, September 29, 2015 11:27 AM To: dev@cordova.apache.org Subject: RE: [Discuss] Cordova-common release Agree with you, guys. Unfortunately, the underlying modules in `cordova-common` are not really atomic, since they depending on each other. For example ConfigParser requires `xmlHelpers`, `events` and `CordovaError` as a dependencies. Reworking them to be truly separated might be sort of problematic, especially in context of message logging (as they use shared event emitter to log output to console). So I still propose is to release `common` module as-is and then gradually move inner modules out to separate packages. - Best regards, Vladimir. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Friday, September 25, 2015 7:33 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release Sorry a typo to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/" and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there. then have explicit ignores for the dependencies you don't want to be source control like npm [2] [2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana wrote: > Yes after reviewing the changes, I understood the purpose of the code > that you seperated to avoid duplicate code between the other top level > modules (i.e. platforms, lib, cli) > > I still think small modules is the way to go. > > Don't let process, bureaucracy, and ceremony hamper the engineering > process and the consumer UX using this modules. (yeah that came out > from the mouth of an IBMer ;-p) > > Yes, I'm not blind, I understand the voting, the releasing, the > packaging the publish steps > > The way I look at it no matter what you do you are not going to make > it easier by having one "common" package. > > Let's say you just need to update a file to fix a bug from Error, well > you need to test, vote, release, "common" > Next you want to fix a bug in configparser, guess what you need to > tests, vote, release "common" again But if only config parser changed > all the rest of the code in "common" > needs to be tested and release, and consumer will need to pick a new > common for only a small bug fix in a portion of "common" > > Basically that's what we have today, the way I see it you are just > creating two libs "lib" and "lib2" > > With large number of small modules, lets say we create 8 now, maybe > only 2 change most of the time, and the other 5 are so basic and small > that they never change and stay at version 1.0.0 for long time. > > I think for this small modules, I don't think we have to do the blog > post, twitter things, those I will continue to have for the large > components (cli, platforms, plugins) > > Also the side effect I would like to see, is clean APIs edges, each > small module provides an API, it contain tests to that API, and lib > contain integration tests as a whole. > > Maybe the compromise for now, to move forward let's break the > functions into "npm packages" inside this "common" where each sub > directory inside common is a npm package with a single entry point > (index.js) and common package.json have them as "bundleDependencies", > similar way as npm does [1] > > the transition will be for consumers for their dependencies and the > way they consume the API > dependencies: { >cordova-common: "1.0.0" > } > cordova-common only expose one index.js with the APIs to the other > modules > > var cdvUtil = require("cordova-common").cordova-util > cdvPluginInfo = require("cordova-common").cordova-plugin-info, > cdvError = require("cordova-common").cordova-error, > cdvConfigParser = require("cordova-common").cordova-config-parser, > cdvConfigChanges = require("cordova-common").rcordova-config-changes); > > then it can be easier transition if we want to change later, nothing > much on our part since we already have the npm packages implemented > it's a matter if we want to make them available on npm or not. > > [1]: > https://na01.safelinks.protection.
RE: [Discuss] Cordova-common release
Agree with you, guys. Unfortunately, the underlying modules in `cordova-common` are not really atomic, since they depending on each other. For example ConfigParser requires `xmlHelpers`, `events` and `CordovaError` as a dependencies. Reworking them to be truly separated might be sort of problematic, especially in context of message logging (as they use shared event emitter to log output to console). So I still propose is to release `common` module as-is and then gradually move inner modules out to separate packages. - Best regards, Vladimir. -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Friday, September 25, 2015 7:33 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release Sorry a typo to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/" and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there. then have explicit ignores for the dependencies you don't want to be source control like npm [2] [2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana wrote: > Yes after reviewing the changes, I understood the purpose of the code > that you seperated to avoid duplicate code between the other top level > modules (i.e. platforms, lib, cli) > > I still think small modules is the way to go. > > Don't let process, bureaucracy, and ceremony hamper the engineering > process and the consumer UX using this modules. (yeah that came out > from the mouth of an IBMer ;-p) > > Yes, I'm not blind, I understand the voting, the releasing, the > packaging the publish steps > > The way I look at it no matter what you do you are not going to make > it easier by having one "common" package. > > Let's say you just need to update a file to fix a bug from Error, well > you need to test, vote, release, "common" > Next you want to fix a bug in configparser, guess what you need to > tests, vote, release "common" again But if only config parser changed > all the rest of the code in "common" > needs to be tested and release, and consumer will need to pick a new > common for only a small bug fix in a portion of "common" > > Basically that's what we have today, the way I see it you are just > creating two libs "lib" and "lib2" > > With large number of small modules, lets say we create 8 now, maybe > only 2 change most of the time, and the other 5 are so basic and small > that they never change and stay at version 1.0.0 for long time. > > I think for this small modules, I don't think we have to do the blog > post, twitter things, those I will continue to have for the large > components (cli, platforms, plugins) > > Also the side effect I would like to see, is clean APIs edges, each > small module provides an API, it contain tests to that API, and lib > contain integration tests as a whole. > > Maybe the compromise for now, to move forward let's break the > functions into "npm packages" inside this "common" where each sub > directory inside common is a npm package with a single entry point > (index.js) and common package.json have them as "bundleDependencies", > similar way as npm does [1] > > the transition will be for consumers for their dependencies and the > way they consume the API > dependencies: { >cordova-common: "1.0.0" > } > cordova-common only expose one index.js with the APIs to the other > modules > > var cdvUtil = require("cordova-common").cordova-util > cdvPluginInfo = require("cordova-common").cordova-plugin-info, > cdvError = require("cordova-common").cordova-error, > cdvConfigParser = require("cordova-common").cordova-config-parser, > cdvConfigChanges = require("cordova-common").rcordova-config-changes); > > then it can be easier transition if we want to change later, nothing > much on our part since we already have the npm packages implemented > it's a matter if we want to make them available on npm or not. > > [1]: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c01%7 > cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f% > 7c72f988bf
Re: [Discuss] Cordova-common release
Sorry a typo to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/" and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there. then have explicit ignores for the dependencies you don't want to be source control like npm [2] [2]: https://github.com/npm/npm/blob/master/.gitignore#L24 On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana wrote: > Yes after reviewing the changes, I understood the purpose of the code that > you seperated to avoid duplicate code between the other top level modules > (i.e. platforms, lib, cli) > > I still think small modules is the way to go. > > Don't let process, bureaucracy, and ceremony hamper the engineering > process and the consumer UX using this modules. (yeah that came out from > the mouth of an IBMer ;-p) > > Yes, I'm not blind, I understand the voting, the releasing, the packaging > the publish steps > > The way I look at it no matter what you do you are not going to make it > easier by having one "common" package. > > Let's say you just need to update a file to fix a bug from Error, well you > need to test, vote, release, "common" > Next you want to fix a bug in configparser, guess what you need to tests, > vote, release "common" again > But if only config parser changed all the rest of the code in "common" > needs to be tested and release, and consumer will need to pick a new common > for only a small bug fix in a portion of "common" > > Basically that's what we have today, the way I see it you are just > creating two libs "lib" and "lib2" > > With large number of small modules, lets say we create 8 now, maybe only 2 > change most of the time, and the other 5 are so basic and small that they > never change and stay at version 1.0.0 for long time. > > I think for this small modules, I don't think we have to do the blog post, > twitter things, those I will continue to have for the large components > (cli, platforms, plugins) > > Also the side effect I would like to see, is clean APIs edges, each small > module provides an API, it contain tests to that API, and lib contain > integration tests as a whole. > > Maybe the compromise for now, to move forward let's break the functions > into "npm packages" inside this "common" where each sub directory inside > common is a npm package with a single entry point (index.js) and common > package.json have them as "bundleDependencies", similar way as npm does [1] > > the transition will be for consumers for their dependencies and the way > they consume the API > dependencies: { >cordova-common: "1.0.0" > } > cordova-common only expose one index.js with the APIs to the other modules > > var cdvUtil = require("cordova-common").cordova-util > cdvPluginInfo = require("cordova-common").cordova-plugin-info, > cdvError = require("cordova-common").cordova-error, > cdvConfigParser = require("cordova-common").cordova-config-parser, > cdvConfigChanges = require("cordova-common").rcordova-config-changes); > > then it can be easier transition if we want to change later, nothing much > on our part since we already have the npm packages implemented it's a > matter if we want to make them available on npm or not. > > [1]: https://github.com/npm/npm/blob/master/package.json#L137 > > > > > > On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) < > v-seg...@microsoft.com> wrote: > >> I tend to agree w/ Carlos here, but from practical side it might be very >> hard to maintain and release such a granular modules, for example, >> - cordova-error has been updated ->Vote -> update cordova-config-parser >> + Vote-> update + Vote other depended modules >> - now we want to add some new feature: modules are very granular so we >> should introduce a new module >> >> But I totally love and support Carlos idea regarding grouping >> meaningful/independent logic in modules, this is how software must be >> designed. >> >> I personally think about this new module as some sort of core Cordova >> functionality and high level classes which could be used by cordova-lib/cli >> and platforms -unified CordovaError, events (output tracing, etc), working >> with config file, superspawn, etc >> >> Thx! >> Sergey >> -Original Message- >> From: Carlos Santana [mailto:csantan...@gmail.com] >> Sent: Thursday, September 24, 2015 6:31 PM >> To: dev@c
Re: [Discuss] Cordova-common release
I also really like what Carlos suggests. The first release will be tedious but it should get easier after that and make things easier to follow. Using ranges, like we do with pinned platforms, for modules would ease the work during releases and not require us to update every package that depends on it. We can still offer a cordova common type module that unified platforms and lib can use. Common would just depend on these smaller modules. On Sep 25, 2015 9:00 AM, "Mark Koudritsky" wrote: > > Separate modules are tempting, but I think they'll make the release process > much harder. > > On Fri, Sep 25, 2015 at 11:40 AM, Sergey Grebnov (Akvelon) < > v-seg...@microsoft.com> wrote: > > > I tend to agree w/ Carlos here, but from practical side it might be very > > hard to maintain and release such a granular modules, for example, > > - cordova-error has been updated ->Vote -> update cordova-config-parser > > + Vote-> update + Vote other depended modules > > - now we want to add some new feature: modules are very granular so we > > should introduce a new module > > > > But I totally love and support Carlos idea regarding grouping > > meaningful/independent logic in modules, this is how software must be > > designed. > > > > I personally think about this new module as some sort of core Cordova > > functionality and high level classes which could be used by cordova-lib/cli > > and platforms -unified CordovaError, events (output tracing, etc), working > > with config file, superspawn, etc > > > > Thx! > > Sergey > > -Original Message- > > From: Carlos Santana [mailto:csantan...@gmail.com] > > Sent: Thursday, September 24, 2015 6:31 PM > > To: dev@cordova.apache.org > > Subject: Re: [Discuss] Cordova-common release > > > > Sorry if I take my inner purist theoretical developer out for a minute :-) > > > > The point of having a "node module" it should be explicit and small, > > meaning that should be easy to name in a way that describes what it is or > > do. > > > > Take into account that "node module" is not the same as a "npm package" > > > > Having 2 npm packages on the npm registry "cordova-common" and > > "cordova-lib" to the simple eye would look like duplicate packages, and > > then will need to answer multiple times "What is the difference between lib > > and common?" > > > > Why not have more smaller explicit npm packages instead? > > > > cordova-util > > cordova-plugin-info > > cordova-error > > cordova-config-parser > > cordova-config-changes > > > > each one with a index.js exposing APIs > > > > Then the programing model becomes something like this: > > var cdvUtil = require('cordova-util'), > > cdvPluginInfo = require('cordova-plugin-info'), > > cdvError = require('cordova-error'), > > cdvConfigParser = require('cordova-config-parser'), > > cdvConfigChanges = require('cordova-config-changes'); > > > > > > On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon) < > > v-seg...@microsoft.com> wrote: > > > > > Hi guys - we've decided to combine shared logic as cordova-common > > > module and publish it separately (read [1] for more details). > > > Corresponding change has landed to master[2] on last week so I'm > > > wondering if we should release this module and then update LIB to rely > > on it (similar to cordova-serve). > > > So guys it will be great if we can review it one more time (including > > > the name - do we all agree to use cordova-common??) and then do > > > release - I'll be able to help w/ merging the recent changes added to > > > LIB before doing release. > > > > > > [1] > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > > > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro > > > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c > > > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d > > > [2] > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > > > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01% > > > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7 > > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0 > > > ksMKA%2fp2zpg6BNU%3d > > > > > > Thx! > > > Sergey > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > >
Re: [Discuss] Cordova-common release
Yes after reviewing the changes, I understood the purpose of the code that you seperated to avoid duplicate code between the other top level modules (i.e. platforms, lib, cli) I still think small modules is the way to go. Don't let process, bureaucracy, and ceremony hamper the engineering process and the consumer UX using this modules. (yeah that came out from the mouth of an IBMer ;-p) Yes, I'm not blind, I understand the voting, the releasing, the packaging the publish steps The way I look at it no matter what you do you are not going to make it easier by having one "common" package. Let's say you just need to update a file to fix a bug from Error, well you need to test, vote, release, "common" Next you want to fix a bug in configparser, guess what you need to tests, vote, release "common" again But if only config parser changed all the rest of the code in "common" needs to be tested and release, and consumer will need to pick a new common for only a small bug fix in a portion of "common" Basically that's what we have today, the way I see it you are just creating two libs "lib" and "lib2" With large number of small modules, lets say we create 8 now, maybe only 2 change most of the time, and the other 5 are so basic and small that they never change and stay at version 1.0.0 for long time. I think for this small modules, I don't think we have to do the blog post, twitter things, those I will continue to have for the large components (cli, platforms, plugins) Also the side effect I would like to see, is clean APIs edges, each small module provides an API, it contain tests to that API, and lib contain integration tests as a whole. Maybe the compromise for now, to move forward let's break the functions into "npm packages" inside this "common" where each sub directory inside common is a npm package with a single entry point (index.js) and common package.json have them as "bundleDependencies", similar way as npm does [1] the transition will be for consumers for their dependencies and the way they consume the API dependencies: { cordova-common: "1.0.0" } cordova-common only expose one index.js with the APIs to the other modules var cdvUtil = require("cordova-common").cordova-util cdvPluginInfo = require("cordova-common").cordova-plugin-info, cdvError = require("cordova-common").cordova-error, cdvConfigParser = require("cordova-common").cordova-config-parser, cdvConfigChanges = require("cordova-common").rcordova-config-changes); then it can be easier transition if we want to change later, nothing much on our part since we already have the npm packages implemented it's a matter if we want to make them available on npm or not. [1]: https://github.com/npm/npm/blob/master/package.json#L137 On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > I tend to agree w/ Carlos here, but from practical side it might be very > hard to maintain and release such a granular modules, for example, > - cordova-error has been updated ->Vote -> update cordova-config-parser > + Vote-> update + Vote other depended modules > - now we want to add some new feature: modules are very granular so we > should introduce a new module > > But I totally love and support Carlos idea regarding grouping > meaningful/independent logic in modules, this is how software must be > designed. > > I personally think about this new module as some sort of core Cordova > functionality and high level classes which could be used by cordova-lib/cli > and platforms -unified CordovaError, events (output tracing, etc), working > with config file, superspawn, etc > > Thx! > Sergey > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Thursday, September 24, 2015 6:31 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Sorry if I take my inner purist theoretical developer out for a minute :-) > > The point of having a "node module" it should be explicit and small, > meaning that should be easy to name in a way that describes what it is or > do. > > Take into account that "node module" is not the same as a "npm package" > > Having 2 npm packages on the npm registry "cordova-common" and > "cordova-lib" to the simple eye would look like duplicate packages, and > then will need to answer multiple times "What is the difference between lib > and common?" > > Why not have more smaller explicit npm packages instead? > > cordova-util > cordova-plugin-info > cordova-error > cordova-config-parser > co
Re: [Discuss] Cordova-common release
Separate modules are tempting, but I think they'll make the release process much harder. On Fri, Sep 25, 2015 at 11:40 AM, Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > I tend to agree w/ Carlos here, but from practical side it might be very > hard to maintain and release such a granular modules, for example, > - cordova-error has been updated ->Vote -> update cordova-config-parser > + Vote-> update + Vote other depended modules > - now we want to add some new feature: modules are very granular so we > should introduce a new module > > But I totally love and support Carlos idea regarding grouping > meaningful/independent logic in modules, this is how software must be > designed. > > I personally think about this new module as some sort of core Cordova > functionality and high level classes which could be used by cordova-lib/cli > and platforms -unified CordovaError, events (output tracing, etc), working > with config file, superspawn, etc > > Thx! > Sergey > -Original Message- > From: Carlos Santana [mailto:csantan...@gmail.com] > Sent: Thursday, September 24, 2015 6:31 PM > To: dev@cordova.apache.org > Subject: Re: [Discuss] Cordova-common release > > Sorry if I take my inner purist theoretical developer out for a minute :-) > > The point of having a "node module" it should be explicit and small, > meaning that should be easy to name in a way that describes what it is or > do. > > Take into account that "node module" is not the same as a "npm package" > > Having 2 npm packages on the npm registry "cordova-common" and > "cordova-lib" to the simple eye would look like duplicate packages, and > then will need to answer multiple times "What is the difference between lib > and common?" > > Why not have more smaller explicit npm packages instead? > > cordova-util > cordova-plugin-info > cordova-error > cordova-config-parser > cordova-config-changes > > each one with a index.js exposing APIs > > Then the programing model becomes something like this: > var cdvUtil = require('cordova-util'), > cdvPluginInfo = require('cordova-plugin-info'), > cdvError = require('cordova-error'), > cdvConfigParser = require('cordova-config-parser'), > cdvConfigChanges = require('cordova-config-changes'); > > > On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon) < > v-seg...@microsoft.com> wrote: > > > Hi guys - we've decided to combine shared logic as cordova-common > > module and publish it separately (read [1] for more details). > > Corresponding change has landed to master[2] on last week so I'm > > wondering if we should release this module and then update LIB to rely > on it (similar to cordova-serve). > > So guys it will be great if we can review it one more time (including > > the name - do we all agree to use cordova-common??) and then do > > release - I'll be able to help w/ merging the recent changes added to > > LIB before doing release. > > > > [1] > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro > > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c > > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d > > [2] > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01% > > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7 > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0 > > ksMKA%2fp2zpg6BNU%3d > > > > Thx! > > Sergey > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > >
RE: [Discuss] Cordova-common release
I tend to agree w/ Carlos here, but from practical side it might be very hard to maintain and release such a granular modules, for example, - cordova-error has been updated ->Vote -> update cordova-config-parser + Vote-> update + Vote other depended modules - now we want to add some new feature: modules are very granular so we should introduce a new module But I totally love and support Carlos idea regarding grouping meaningful/independent logic in modules, this is how software must be designed. I personally think about this new module as some sort of core Cordova functionality and high level classes which could be used by cordova-lib/cli and platforms -unified CordovaError, events (output tracing, etc), working with config file, superspawn, etc Thx! Sergey -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Thursday, September 24, 2015 6:31 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release Sorry if I take my inner purist theoretical developer out for a minute :-) The point of having a "node module" it should be explicit and small, meaning that should be easy to name in a way that describes what it is or do. Take into account that "node module" is not the same as a "npm package" Having 2 npm packages on the npm registry "cordova-common" and "cordova-lib" to the simple eye would look like duplicate packages, and then will need to answer multiple times "What is the difference between lib and common?" Why not have more smaller explicit npm packages instead? cordova-util cordova-plugin-info cordova-error cordova-config-parser cordova-config-changes each one with a index.js exposing APIs Then the programing model becomes something like this: var cdvUtil = require('cordova-util'), cdvPluginInfo = require('cordova-plugin-info'), cdvError = require('cordova-error'), cdvConfigParser = require('cordova-config-parser'), cdvConfigChanges = require('cordova-config-changes'); On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Hi guys - we've decided to combine shared logic as cordova-common > module and publish it separately (read [1] for more details). > Corresponding change has landed to master[2] on last week so I'm > wondering if we should release this module and then update LIB to rely on it > (similar to cordova-serve). > So guys it will be great if we can review it one more time (including > the name - do we all agree to use cordova-common??) and then do > release - I'll be able to help w/ merging the recent changes added to > LIB before doing release. > > [1] > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d > [2] > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01% > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7 > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0 > ksMKA%2fp2zpg6BNU%3d > > Thx! > Sergey > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
Re: [Discuss] Cordova-common release
Sorry if I take my inner purist theoretical developer out for a minute :-) The point of having a "node module" it should be explicit and small, meaning that should be easy to name in a way that describes what it is or do. Take into account that "node module" is not the same as a "npm package" Having 2 npm packages on the npm registry "cordova-common" and "cordova-lib" to the simple eye would look like duplicate packages, and then will need to answer multiple times "What is the difference between lib and common?" Why not have more smaller explicit npm packages instead? cordova-util cordova-plugin-info cordova-error cordova-config-parser cordova-config-changes each one with a index.js exposing APIs Then the programing model becomes something like this: var cdvUtil = require('cordova-util'), cdvPluginInfo = require('cordova-plugin-info'), cdvError = require('cordova-error'), cdvConfigParser = require('cordova-config-parser'), cdvConfigChanges = require('cordova-config-changes'); On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon) < v-seg...@microsoft.com> wrote: > Hi guys - we've decided to combine shared logic as cordova-common module > and publish it separately (read [1] for more details). Corresponding change > has landed to master[2] on last week so I'm wondering if we should release > this module and then update LIB to rely on it (similar to cordova-serve). > So guys it will be great if we can review it one more time (including the > name - do we all agree to use cordova-common??) and then do release - > I'll be able to help w/ merging the recent changes added to LIB before > doing release. > > [1] https://issues.apache.org/jira/browse/CB-9598 > [2] https://github.com/apache/cordova-lib/tree/master/cordova-common > > Thx! > Sergey > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >