Re: [DISCUSS] cordova-common release

[raphinesse]

+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

[julio cesar sanchez]

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

[Vladimir Kotikov (Akvelon)]

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 <stevengil...@gmail.com> 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 <csantan...@gmail.com>
> 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=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1=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 <stevengil...@gmail.com>
> > 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 <dev@cordova.apache.org>
> > > > 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 <dev@co

Re: [Discuss] Cordova-common release

[Carlos Santana]

+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 <stevengil...@gmail.com> 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 <stevengil...@gmail.com>
> > 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 <csantan...@gmail.com>
> > > 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=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1=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 <stevengil...@gmail.com>
> > > > 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?
> > > > > >
> > > > > 

Re: [Discuss] Cordova-common release

[Steven Gill]

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 <stevengil...@gmail.com>
> 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 <csantan...@gmail.com>
> > 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=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1=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 <stevengil...@gmail.com>
> > > 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 <dev@cordova.apache.org>
> > > > > Subject: Re: [Discuss] Cordova-common release
> > > > >
> 

Re: [Discuss] Cordova-common release

[Carlos Santana]

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 <stevengil...@gmail.com> 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 <dev@cordova.apache.org>
> > 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 <dev@cordova.apache.org>
> > > 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:
> > > >
> > > > >+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
> > > 

Re: [Discuss] Cordova-common release

[Steven Gill]

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 <csantan...@gmail.com>
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 <stevengil...@gmail.com>
> 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 <dev@cordova.apache.org>
> > > 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 <dev@cordova.apache.org>
> > > > 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:
> > > > >
> > > > > >+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.
> > > 

Re: [Discuss] Cordova-common release

[Carlos Santana]

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 <stevengil...@gmail.com> 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 <csantan...@gmail.com>
> 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 <stevengil...@gmail.com>
> > 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 <dev@cordova.apache.org>
> > > > 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 <dev@cordova.apache.org>
> > > > > 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:2

RE: [Discuss] Cordova-common release

[Vladimir Kotikov (Akvelon)]

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 <dev@cordova.apache.org>
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 <dev@cordova.apache.org>
> 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:
> >
> > >+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

Re: [Discuss] Cordova-common release

[Steven Gill]

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 <dev@cordova.apache.org>
> 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 <dev@cordova.apache.org>
> > 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:
> > >
> > > >+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

RE: [Discuss] Cordova-common release

[Vladimir Kotikov (Akvelon)]

> 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 <dev@cordova.apache.org>
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 <dev@cordova.apache.org>
> 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:
> >
> > >+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, Septem

Re: [Discuss] Cordova-common release

[Joe Bowser]

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 <dev@cordova.apache.org>
> 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:
> >
> > >+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

RE: [Discuss] Cordova-common release

[Nikhil Khandelwal]

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 <dev@cordova.apache.org>
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 <dev@cordova.apache.org>
> 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:
> >
> > >+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

RE: [Discuss] Cordova-common release

[Nikhil Khandelwal]

+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=01%7c01%7cv-vlkoti%40
> > 06
> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86
> > f1 
> > 41af91ab2d7cd011db47%7c1=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
> > To: dev@cordova.apache.org
> > Subject: Re: [Discuss] Cord

Re: [Discuss] Cordova-common release

[Joe Bowser]

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:
>
> >+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

[Steven Gill]

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=01%7c01%7cv-vlkoti%4006
> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1
> > 41af91ab2d7cd011db47%7c1=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

Re: [Discuss] Cordova-common release

[Parashuram N]

+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:

>+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.co

RE: [Discuss] Cordova-common release

[Nikhil Khandelwal]

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 <dev@cordova.apache.org>
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:
>
> >+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 de

RE: [Discuss] Cordova-common release

[Vladimir Kotikov (Akvelon)]

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 <stevengil...@gmail.com> wrote:

> Sounds good. Let's move forward
> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <nikhi...@microsoft.com>
> 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=01%7c01%7cv-
> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c7
> 2f988bf86f141af91ab2d7cd011db47%7c1=tU%2bFHDUJZXzXnbG%2fUP7AY4qE
> CnvsbnsJ%2bvEriJvqYcU%3d
> >
> >
> > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana 
> > <csantan...@gmail.com>
> > 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 
> > > m

Re: [Discuss] Cordova-common release

[Carlos Santana]

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://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 <stevengil...@gmail.com> wrote:
>> 
>> Sounds good. Let's move forward
>> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <nikhi...@microsoft.com>
>> 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

RE: [Discuss] Cordova-common release

[Vladimir Kotikov (Akvelon)]

> 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=01%7c01%7cv-vlkoti%4006
> 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1
> 41af91ab2d7cd011db47%7c1=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 <stevengil...@gmail.com> wrote:
>> 
>> Sounds good. Let's move forward
>> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" 
>> <nikhi...@microsoft.com>
>> 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

[Vladimir Kotikov (Akvelon)]

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=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d


On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <csantan...@gmail.com>
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=01%7c01%7
> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> 7c72f988bf86f141af91ab2d7cd011db47%7c1=tUdBPvbE8oC

Re: [Discuss] Cordova-common release

[Carlos Santana]

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 <stevengil...@gmail.com> wrote:

> Sounds good. Let's move forward
> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <nikhi...@microsoft.com>
> 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=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
> >
> >
> > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <csantan...@gmail.com>
> > 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"
> > >
> > > Basi

RE: [Discuss] Cordova-common release

[Steven Gill]

Sounds good. Let's move forward
On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <nikhi...@microsoft.com>
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=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
>
>
> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <csantan...@gmail.com>
> 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.jso

RE: [Discuss] Cordova-common release

[Sergey Grebnov (Akvelon)]

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=01%7c01%7cv-segreb%40micro
> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> d011db47%7c1=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=01%
> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> 2f988bf86f141af91ab2d7cd011db47%7c1=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

[Mark Koudritsky]

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=01%7c01%7cv-segreb%40micro
> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> > d011db47%7c1=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=01%
> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> > 2f988bf86f141af91ab2d7cd011db47%7c1=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

[Carlos Santana]

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
> cordova-config-changes
>
> each

Re: [Discuss] Cordova-common release

[Steven Gill]

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" <kam...@google.com.invalid>
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=01%7c01%7cv-segreb%40micro
> > > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> > > d011db47%7c1=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=01%
> > > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> > > 2f988bf86f141af91ab2d7cd011db47%7c1=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

[Carlos Santana]

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 <csantan...@gmail.com>
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@cord

Re: [Discuss] Cordova-common release

[Carlos Santana]

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
>
>