You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com> on 2015/09/24 18:29:29 UTC
[Discuss] Cordova-common release
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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [Discuss] Cordova-common release
Posted by Steven Gill <st...@gmail.com>.
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" <ka...@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-segreb@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:csantana23@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-segreb@microsoft.com> wrote:
> >
> > > Hi guys - we've decided to combine shared logic as cordova-common
> > > module and publish it separately (read [1] for more details).
> > > Corresponding change has landed to master[2] on last week so I'm
> > > wondering if we should release this module and then update LIB to rely
> > on it (similar to cordova-serve).
> > > So guys it will be great if we can review it one more time (including
> > > the name - do we all agree to use cordova-common??) and then do
> > > release - I'll be able to help w/ merging the recent changes added to
> > > LIB before doing release.
> > >
> > > [1]
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro
> > > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> > > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d
> > > [2]
> > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01%
> > > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0
> > > ksMKA%2fp2zpg6BNU%3d
> > >
> > > Thx!
> > > Sergey
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> > >
> >
Re: [Discuss] Cordova-common release
Posted by Mark Koudritsky <ka...@google.com.INVALID>.
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-segreb@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:csantana23@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-segreb@microsoft.com> wrote:
>
> > Hi guys - we've decided to combine shared logic as cordova-common
> > module and publish it separately (read [1] for more details).
> > Corresponding change has landed to master[2] on last week so I'm
> > wondering if we should release this module and then update LIB to rely
> on it (similar to cordova-serve).
> > So guys it will be great if we can review it one more time (including
> > the name - do we all agree to use cordova-common??) and then do
> > release - I'll be able to help w/ merging the recent changes added to
> > LIB before doing release.
> >
> > [1]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro
> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d
> > [2]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01%
> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0
> > ksMKA%2fp2zpg6BNU%3d
> >
> > Thx!
> > Sergey
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
+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 <st...@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-vlkoti@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:csantana23@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 <st...@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 <cs...@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&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MevYqWuEKkGzlZB0skKnx2iTiUgi6sk57zQoNCMqIZo%3d
> > > > cdvCommon = require('cordova-common')
> > > > cdvCommon.x does x
> > > > cdvCommon.y does y
> > > > Since there is no "npm test" or test folder, the README should talk
> > > > about how this code in the npm module get's tested from cordova-lib
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill <st...@gmail.com>
> > > > wrote:
> > > >
> > > > > DO IT!
> > > > >
> > > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
> > > > > v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> > > > > > Sent: Wednesday, October 21, 2015 9:19 AM
> > > > > > To: dev <de...@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 <
> > > > > nikhilkh@microsoft.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > It got checked in earlier this morning.
> > > > > > >
> > > > > > > -Nikhil
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > > > > Sent: Tuesday, October 20, 2015 2:34 PM
> > > > > > > To: dev <de...@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 <
> > > > panarasi@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" <
> > > nikhilkh@microsoft.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > >+1 to publishing cordova-common to npm.
> > > > > > > > >
> > > > > > > > >-Nikhil
> > > > > > > > >
> > > > > > > > >-----Original Message-----
> > > > > > > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > > > > > > >> > 2f
> > > > > > > > >> > git
> > > > > > > > >> > hu
> > > > > > > > >> > https://na01.safelinks.protection.outlook.com/?url=b.co
> > > > > > > > >> > m&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c36
> > > > > > > > >> > 79b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d
> > > > > > > > >> > 7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3MuXBY3UBAw1nG
> > > > > > > > >> > Wj6b4FcA1NU%3d
> > > > %2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > > > > > > >> > ti
> > > > > > > > >> > %40
> > > > > > > > >> > 06
> > > > > > > > >> > https://na01.safelinks.protection.outlook.com/?url=4d.m
> > > > > > > > >> > gd.microsoft.com&data=01%7c01%7cv-vlkoti%40064d.mgd.mic
> > > > > > > > >> > rosoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988b
> > > > > > > > >> > f86f141af91ab2d7cd011db47%7c1&sdata=wOpIonxCAIdac1B9M3c
> > > > > > > > >> > v7U1YBv%2bFWlBhG3G%2b2faLoOA%3d
> > > > %7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > > > > > > >> > 8b
> > > > > > > > >> > f86
> > > > > > > > >> > f1
> > > > > > > > >> >
> > > > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > > > > > > >> > fm
> > > > > > > > >> > %2b
> > > > > > > > >> > do
> > > > > > > > >> > 9WX4V4JfT0%3d
> > > > > > > > >> >
> > > > > > > > >> > -
> > > > > > > > >> > Best regards, Vladimir.
> > > > > > > > >> >
> > > > > > > > >> > -----Original Message-----
> > > > > > > > >> > From: Carlos Santana [mailto:csantana23@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
> > > > > > > > >> >> <st...@gmail.com>
> > > > > > > > >> wrote:
> > > > > > > > >> >>
> > > > > > > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21
> > > > > > > > >> >> AM, "Nikhil Khandelwal"
> > > > > > > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > > > > > > >> >> %2
> > > > > > > > >> >> fgi
> > > > > > > > >> >> th
> > > > > > > > >> >> u
> > > > > > > > >> >> https://na01.safelinks.protection.outlook.com/?url=b.c
> > > > > > > > >> >> om&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c
> > > > > > > > >> >> 3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91a
> > > > > > > > >> >> b2d7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3MuXBY3UBA
> > > > > > > > >> >> w1nGWj6b4FcA1NU%3d
> > > > %2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > > > > > > >> >> c0
> > > > > > > > >> >> 1%7
> > > > > > > > >> >> cv
> > > > > > > > >> >> -
> > > > > > > > >> >> vlkoti%40064d.mgd.microsoft.com
> > > > %7c73b4ff38f0fe41e1f18608d2c5c7
> > > > > > > > >> >> 0e
> > > > > > > > >> >> 0f%
> > > > > > > > >> >> 7c
> > > > > > > > >> >> 7
> > > > > > > > >> >>
> > > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > > > > > > >> >> UP
> > > > > > > > >> >> 7AY
> > > > > > > > >> >> 4q
> > > > > > > > >> >> E
> > > > > > > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > > > > > > >> >>>
> > > > > > > > >> >>>
> > > > > > > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > > > > > > >> >>> <cs...@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
> > > > > > > > >> >>>> %2f
> > > > > > > > >> >>>> g
> > > > > > > > >> >>>> ithu
> > > > > > > > >> >>>> https://na01.safelinks.protection.outlook.com/?url=b
> > > > > > > > >> >>>> .com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.co
> > > > > > > > >> >>>> m%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f14
> > > > > > > > >> >>>> 1af91ab2d7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3M
> > > > > > > > >> >>>> uXBY3UBAw1nGWj6b4FcA1NU%3d
> > > > %2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > > > > > > >> >>>> =0
> > > > > > > > >> >>>> 1%7
> > > > > > > > >> >>>> c
> > > > > > > > >> >>>> 01%7
> > > > > > > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com
> > > > %7c73b4ff38f0fe41e1f18608d
> > > > > > > > >> >>>> 2c
> > > > > > > > >> >>>> 5c7
> > > > > > > > >> >>>> 0
> > > > > > > > >> >>>> e0f%
> > > > > > > > >> >>>>
> > > > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > > > > > > >> >>>> bm
> > > > > > > > >> >>>> Vx5
> > > > > > > > >> >>>> 0
> > > > > > > > >> >>>> QKD2
> > > > > > > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > > > > > > >> >>>>
> > > > > > > > >> >>>>
> > > > > > > > >> >>>>
> > > > > > > > >> >>>>
> > > > > > > > >> >>>>
> > > > > > > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov
> > > (Akvelon) <
> > > > > > > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > > > > > > >> >>>>>> a%
> > > > > > > > >> >>>>>> 2f%
> > > > > > > > >> >>>>>> 2fis
> > > > > > > > >> >>>>>> sue
> > > > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > > > >> >>>>>> =s.apache.org&data=01%7c01%7cv-vlkoti%40064d.mgd.m
> > > > > > > > >> >>>>>> icrosoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c
> > > > > > > > >> >>>>>> 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q3M6hF6
> > > > > > > > >> >>>>>> dtJswbfQZK8vSvlyeWhrf41qEZSPRQxKqhF8%3d
> > > > %2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > > > > > > >> >>>>>> gr
> > > > > > > > >> >>>>>> eb%
> > > > > > > > >> >>>>>> 40mi
> > > > > > > > >> >>>>>> cro
> > > > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > > > >> >>>>>> =soft.com&data=01%7c01%7cv-vlkoti%40064d.mgd.micro
> > > > > > > > >> >>>>>> soft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f9
> > > > > > > > >> >>>>>> 88bf86f141af91ab2d7cd011db47%7c1&sdata=aZRwcGSJxvv
> > > > > > > > >> >>>>>> tHxOesdVojD5kU8B0uKoNhnLovqu6OSA%3d
> > > > %7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > > > > > > >> >>>>>> 41
> > > > > > > > >> >>>>>> af9
> > > > > > > > >> >>>>>> 1ab2
> > > > > > > > >> >>>>>> d7c
> > > > > > > > >> >>>>>>
> > > > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > > > > > > >> >>>>>> rT
> > > > > > > > >> >>>>>> jwX
> > > > > > > > >> >>>>>> TXk%
> > > > > > > > >> >>>>>> 3d
> > > > > > > > >> >>>>>> [2]
> > > > > > > > >> >>>>>>
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3
> > > > > > > > >> >>>>>> a%
> > > > > > > > >> >>>>>> 2f%
> > > > > > > > >> >>>>>> 2fgi
> > > > > > > > >> >>>>>> thu
> > > > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > > > >> >>>>>> =b.com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsof
> > > > > > > > >> >>>>>> t.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988b
> > > > > > > > >> >>>>>> f86f141af91ab2d7cd011db47%7c1&sdata=%2btIES1o7b5uh
> > > > > > > > >> >>>>>> k8jzLG3MuXBY3UBAw1nGWj6b4FcA1NU%3d
> > > > %2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > > > > > > >> >>>>>> mo
> > > > > > > > >> >>>>>> n&d
> > > > > > > > >> >>>>>> ata=
> > > > > > > > >> >>>>>> 01%
> > > > > > > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com
> > > > %7cf31529ebb0de4bf28ebd08d2
> > > > > > > > >> >>>>>> c5
> > > > > > > > >> >>>>>> 491
> > > > > > > > >> >>>>>> 5f3%
> > > > > > > > >> >>>>>> 7c7
> > > > > > > > >> >>>>>>
> > > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > > > > > > >> >>>>>> I9
> > > > > > > > >> >>>>>> ASf
> > > > > > > > >> >>>>>> QMku
> > > > > > > > >> >>>>>> RV0
> > > > > > > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > > > > > > >> >>>>>>
> > > > > > > > >> >>>>>> Thx!
> > > > > > > > >> >>>>>> Sergey
> > > > > > > > >> >>>>>>
> > > > > > > > >> >>>>>>
> > > > ----------------------------------------------------------
> > > > > > > > >> >>>>>> --
> > > > > > > > >> >>>>>> ---
> > > > > > > > >> >>>>>> ----
> > > > > > > > >> >>>>>> -- To unsubscribe, e-mail:
> > > > > > > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > > > > > > >> >>>>>> For additional commands, e-mail:
> > > > > > > > >> >>>>>> dev-help@cordova.apache.org
> > > > > > > > >> >>>
> > > > > > > > >> >>>
> > > > -------------------------------------------------------------
> > > > > > > > >> >>> --
> > > > > > > > >> >>> ---
> > > > > > > > >> >>> --
> > > > > > > > >> >>> - To unsubscribe, e-mail:
> > > > dev-unsubscribe@cordova.apache.org
> > > > > > > > >> >>> For additional commands, e-mail:
> > > > dev-help@cordova.apache.org
> > > > > > > > >> >
> > > > > > > > >> >
> > > > ---------------------------------------------------------------
> > > > > > > > >> > --
> > > > > > > > >> > ---
> > > > > > > > >> > - To unsubscribe, e-mail:
> > > dev-unsubscribe@cordova.apache.org
> > > > > > > > >> > For additional commands, e-mail:
> > > dev-help@cordova.apache.org
> > > > > > > > >>
> > > > > > > > >>
> > > > -----------------------------------------------------------------
> > > > > > > > >> --
> > > > > > > > >> -- To unsubscribe, e-mail:
> > > > > > > > >> dev-unsubscribe@cordova.apache.org
> > > > > > > > >> For additional commands, e-mail:
> > > > > > > > >> dev-help@cordova.apache.org
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > -----------------------------------------------------------------
> > > > > > > > >> --
> > > > > > > > >> -- To unsubscribe, e-mail:
> > > > > > > > >> dev-unsubscribe@cordova.apache.org
> > > > > > > > >> For additional commands, e-mail:
> > > > > > > > >> dev-help@cordova.apache.org
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > >
> > > > > > > > >?B
> > > > > > > >
> > > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > > > > > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > > > > > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > > > > > > >
> > > > > > > >
> > > > --------------------------------------------------------------------
> > > > > > > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [Discuss] Cordova-common release
Posted by Steven Gill <st...@gmail.com>.
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-vlkoti@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:csantana23@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 <st...@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 <cs...@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&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MevYqWuEKkGzlZB0skKnx2iTiUgi6sk57zQoNCMqIZo%3d
> > > cdvCommon = require('cordova-common')
> > > cdvCommon.x does x
> > > cdvCommon.y does y
> > > Since there is no "npm test" or test folder, the README should talk
> > > about how this code in the npm module get's tested from cordova-lib
> > >
> > >
> > >
> > >
> > > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill <st...@gmail.com>
> > > wrote:
> > >
> > > > DO IT!
> > > >
> > > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
> > > > v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> > > > > Sent: Wednesday, October 21, 2015 9:19 AM
> > > > > To: dev <de...@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 <
> > > > nikhilkh@microsoft.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > It got checked in earlier this morning.
> > > > > >
> > > > > > -Nikhil
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > > > Sent: Tuesday, October 20, 2015 2:34 PM
> > > > > > To: dev <de...@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 <
> > > panarasi@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" <
> > nikhilkh@microsoft.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > >+1 to publishing cordova-common to npm.
> > > > > > > >
> > > > > > > >-Nikhil
> > > > > > > >
> > > > > > > >-----Original Message-----
> > > > > > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > > > > > >> > 2f
> > > > > > > >> > git
> > > > > > > >> > hu
> > > > > > > >> > https://na01.safelinks.protection.outlook.com/?url=b.co
> > > > > > > >> > m&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c36
> > > > > > > >> > 79b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d
> > > > > > > >> > 7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3MuXBY3UBAw1nG
> > > > > > > >> > Wj6b4FcA1NU%3d
> > > %2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > > > > > >> > ti
> > > > > > > >> > %40
> > > > > > > >> > 06
> > > > > > > >> > https://na01.safelinks.protection.outlook.com/?url=4d.m
> > > > > > > >> > gd.microsoft.com&data=01%7c01%7cv-vlkoti%40064d.mgd.mic
> > > > > > > >> > rosoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988b
> > > > > > > >> > f86f141af91ab2d7cd011db47%7c1&sdata=wOpIonxCAIdac1B9M3c
> > > > > > > >> > v7U1YBv%2bFWlBhG3G%2b2faLoOA%3d
> > > %7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > > > > > >> > 8b
> > > > > > > >> > f86
> > > > > > > >> > f1
> > > > > > > >> >
> > > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > > > > > >> > fm
> > > > > > > >> > %2b
> > > > > > > >> > do
> > > > > > > >> > 9WX4V4JfT0%3d
> > > > > > > >> >
> > > > > > > >> > -
> > > > > > > >> > Best regards, Vladimir.
> > > > > > > >> >
> > > > > > > >> > -----Original Message-----
> > > > > > > >> > From: Carlos Santana [mailto:csantana23@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
> > > > > > > >> >> <st...@gmail.com>
> > > > > > > >> wrote:
> > > > > > > >> >>
> > > > > > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21
> > > > > > > >> >> AM, "Nikhil Khandelwal"
> > > > > > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > > > > > >> >> %2
> > > > > > > >> >> fgi
> > > > > > > >> >> th
> > > > > > > >> >> u
> > > > > > > >> >> https://na01.safelinks.protection.outlook.com/?url=b.c
> > > > > > > >> >> om&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c
> > > > > > > >> >> 3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91a
> > > > > > > >> >> b2d7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3MuXBY3UBA
> > > > > > > >> >> w1nGWj6b4FcA1NU%3d
> > > %2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > > > > > >> >> c0
> > > > > > > >> >> 1%7
> > > > > > > >> >> cv
> > > > > > > >> >> -
> > > > > > > >> >> vlkoti%40064d.mgd.microsoft.com
> > > %7c73b4ff38f0fe41e1f18608d2c5c7
> > > > > > > >> >> 0e
> > > > > > > >> >> 0f%
> > > > > > > >> >> 7c
> > > > > > > >> >> 7
> > > > > > > >> >>
> > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > > > > > >> >> UP
> > > > > > > >> >> 7AY
> > > > > > > >> >> 4q
> > > > > > > >> >> E
> > > > > > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > > > > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > > > > > >> >>> <cs...@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
> > > > > > > >> >>>> %2f
> > > > > > > >> >>>> g
> > > > > > > >> >>>> ithu
> > > > > > > >> >>>> https://na01.safelinks.protection.outlook.com/?url=b
> > > > > > > >> >>>> .com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.co
> > > > > > > >> >>>> m%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f14
> > > > > > > >> >>>> 1af91ab2d7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3M
> > > > > > > >> >>>> uXBY3UBAw1nGWj6b4FcA1NU%3d
> > > %2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > > > > > >> >>>> =0
> > > > > > > >> >>>> 1%7
> > > > > > > >> >>>> c
> > > > > > > >> >>>> 01%7
> > > > > > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com
> > > %7c73b4ff38f0fe41e1f18608d
> > > > > > > >> >>>> 2c
> > > > > > > >> >>>> 5c7
> > > > > > > >> >>>> 0
> > > > > > > >> >>>> e0f%
> > > > > > > >> >>>>
> > > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > > > > > >> >>>> bm
> > > > > > > >> >>>> Vx5
> > > > > > > >> >>>> 0
> > > > > > > >> >>>> QKD2
> > > > > > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>>
> > > > > > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov
> > (Akvelon) <
> > > > > > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > > > > > >> >>>>>> a%
> > > > > > > >> >>>>>> 2f%
> > > > > > > >> >>>>>> 2fis
> > > > > > > >> >>>>>> sue
> > > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > > >> >>>>>> =s.apache.org&data=01%7c01%7cv-vlkoti%40064d.mgd.m
> > > > > > > >> >>>>>> icrosoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c
> > > > > > > >> >>>>>> 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q3M6hF6
> > > > > > > >> >>>>>> dtJswbfQZK8vSvlyeWhrf41qEZSPRQxKqhF8%3d
> > > %2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > > > > > >> >>>>>> gr
> > > > > > > >> >>>>>> eb%
> > > > > > > >> >>>>>> 40mi
> > > > > > > >> >>>>>> cro
> > > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > > >> >>>>>> =soft.com&data=01%7c01%7cv-vlkoti%40064d.mgd.micro
> > > > > > > >> >>>>>> soft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f9
> > > > > > > >> >>>>>> 88bf86f141af91ab2d7cd011db47%7c1&sdata=aZRwcGSJxvv
> > > > > > > >> >>>>>> tHxOesdVojD5kU8B0uKoNhnLovqu6OSA%3d
> > > %7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > > > > > >> >>>>>> 41
> > > > > > > >> >>>>>> af9
> > > > > > > >> >>>>>> 1ab2
> > > > > > > >> >>>>>> d7c
> > > > > > > >> >>>>>>
> > > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > > > > > >> >>>>>> rT
> > > > > > > >> >>>>>> jwX
> > > > > > > >> >>>>>> TXk%
> > > > > > > >> >>>>>> 3d
> > > > > > > >> >>>>>> [2]
> > > > > > > >> >>>>>>
> > > https://na01.safelinks.protection.outlook.com/?url=https%3
> > > > > > > >> >>>>>> a%
> > > > > > > >> >>>>>> 2f%
> > > > > > > >> >>>>>> 2fgi
> > > > > > > >> >>>>>> thu
> > > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > > >> >>>>>> =b.com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsof
> > > > > > > >> >>>>>> t.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988b
> > > > > > > >> >>>>>> f86f141af91ab2d7cd011db47%7c1&sdata=%2btIES1o7b5uh
> > > > > > > >> >>>>>> k8jzLG3MuXBY3UBAw1nGWj6b4FcA1NU%3d
> > > %2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > > > > > >> >>>>>> mo
> > > > > > > >> >>>>>> n&d
> > > > > > > >> >>>>>> ata=
> > > > > > > >> >>>>>> 01%
> > > > > > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com
> > > %7cf31529ebb0de4bf28ebd08d2
> > > > > > > >> >>>>>> c5
> > > > > > > >> >>>>>> 491
> > > > > > > >> >>>>>> 5f3%
> > > > > > > >> >>>>>> 7c7
> > > > > > > >> >>>>>>
> > > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > > > > > >> >>>>>> I9
> > > > > > > >> >>>>>> ASf
> > > > > > > >> >>>>>> QMku
> > > > > > > >> >>>>>> RV0
> > > > > > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>> Thx!
> > > > > > > >> >>>>>> Sergey
> > > > > > > >> >>>>>>
> > > > > > > >> >>>>>>
> > > ----------------------------------------------------------
> > > > > > > >> >>>>>> --
> > > > > > > >> >>>>>> ---
> > > > > > > >> >>>>>> ----
> > > > > > > >> >>>>>> -- To unsubscribe, e-mail:
> > > > > > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > > > > > >> >>>>>> For additional commands, e-mail:
> > > > > > > >> >>>>>> dev-help@cordova.apache.org
> > > > > > > >> >>>
> > > > > > > >> >>>
> > > -------------------------------------------------------------
> > > > > > > >> >>> --
> > > > > > > >> >>> ---
> > > > > > > >> >>> --
> > > > > > > >> >>> - To unsubscribe, e-mail:
> > > dev-unsubscribe@cordova.apache.org
> > > > > > > >> >>> For additional commands, e-mail:
> > > dev-help@cordova.apache.org
> > > > > > > >> >
> > > > > > > >> >
> > > ---------------------------------------------------------------
> > > > > > > >> > --
> > > > > > > >> > ---
> > > > > > > >> > - To unsubscribe, e-mail:
> > dev-unsubscribe@cordova.apache.org
> > > > > > > >> > For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > > > > > > >>
> > > > > > > >>
> > > -----------------------------------------------------------------
> > > > > > > >> --
> > > > > > > >> -- To unsubscribe, e-mail:
> > > > > > > >> dev-unsubscribe@cordova.apache.org
> > > > > > > >> For additional commands, e-mail:
> > > > > > > >> dev-help@cordova.apache.org
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > -----------------------------------------------------------------
> > > > > > > >> --
> > > > > > > >> -- To unsubscribe, e-mail:
> > > > > > > >> dev-unsubscribe@cordova.apache.org
> > > > > > > >> For additional commands, e-mail:
> > > > > > > >> dev-help@cordova.apache.org
> > > > > > > >>
> > > > > > > >>
> > > > > > >
> > > > > > > >?B
> > > > > > >
> > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > > > > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > > > > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > > > > > >
> > > > > > >
> > > --------------------------------------------------------------------
> > > > > > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
RE: [Discuss] Cordova-common release
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
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:csantana23@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 <st...@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 <cs...@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&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MevYqWuEKkGzlZB0skKnx2iTiUgi6sk57zQoNCMqIZo%3d
> > cdvCommon = require('cordova-common')
> > cdvCommon.x does x
> > cdvCommon.y does y
> > Since there is no "npm test" or test folder, the README should talk
> > about how this code in the npm module get's tested from cordova-lib
> >
> >
> >
> >
> > On Thu, Oct 22, 2015 at 2:46 PM Steven Gill <st...@gmail.com>
> > wrote:
> >
> > > DO IT!
> > >
> > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
> > > v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> > > > Sent: Wednesday, October 21, 2015 9:19 AM
> > > > To: dev <de...@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 <
> > > nikhilkh@microsoft.com
> > > > >
> > > > wrote:
> > > >
> > > > > It got checked in earlier this morning.
> > > > >
> > > > > -Nikhil
> > > > >
> > > > > -----Original Message-----
> > > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > > Sent: Tuesday, October 20, 2015 2:34 PM
> > > > > To: dev <de...@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 <
> > panarasi@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" <
> nikhilkh@microsoft.com>
> > > > > wrote:
> > > > > >
> > > > > > >+1 to publishing cordova-common to npm.
> > > > > > >
> > > > > > >-Nikhil
> > > > > > >
> > > > > > >-----Original Message-----
> > > > > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > > > > >> > 2f
> > > > > > >> > git
> > > > > > >> > hu
> > > > > > >> > https://na01.safelinks.protection.outlook.com/?url=b.co
> > > > > > >> > m&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c36
> > > > > > >> > 79b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91ab2d
> > > > > > >> > 7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3MuXBY3UBAw1nG
> > > > > > >> > Wj6b4FcA1NU%3d
> > %2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > > > > >> > ti
> > > > > > >> > %40
> > > > > > >> > 06
> > > > > > >> > https://na01.safelinks.protection.outlook.com/?url=4d.m
> > > > > > >> > gd.microsoft.com&data=01%7c01%7cv-vlkoti%40064d.mgd.mic
> > > > > > >> > rosoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988b
> > > > > > >> > f86f141af91ab2d7cd011db47%7c1&sdata=wOpIonxCAIdac1B9M3c
> > > > > > >> > v7U1YBv%2bFWlBhG3G%2b2faLoOA%3d
> > %7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > > > > >> > 8b
> > > > > > >> > f86
> > > > > > >> > f1
> > > > > > >> >
> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > > > > >> > fm
> > > > > > >> > %2b
> > > > > > >> > do
> > > > > > >> > 9WX4V4JfT0%3d
> > > > > > >> >
> > > > > > >> > -
> > > > > > >> > Best regards, Vladimir.
> > > > > > >> >
> > > > > > >> > -----Original Message-----
> > > > > > >> > From: Carlos Santana [mailto:csantana23@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
> > > > > > >> >> <st...@gmail.com>
> > > > > > >> wrote:
> > > > > > >> >>
> > > > > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21
> > > > > > >> >> AM, "Nikhil Khandelwal"
> > > > > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > > > > >> >> %2
> > > > > > >> >> fgi
> > > > > > >> >> th
> > > > > > >> >> u
> > > > > > >> >> https://na01.safelinks.protection.outlook.com/?url=b.c
> > > > > > >> >> om&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c
> > > > > > >> >> 3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f141af91a
> > > > > > >> >> b2d7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3MuXBY3UBA
> > > > > > >> >> w1nGWj6b4FcA1NU%3d
> > %2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > > > > >> >> c0
> > > > > > >> >> 1%7
> > > > > > >> >> cv
> > > > > > >> >> -
> > > > > > >> >> vlkoti%40064d.mgd.microsoft.com
> > %7c73b4ff38f0fe41e1f18608d2c5c7
> > > > > > >> >> 0e
> > > > > > >> >> 0f%
> > > > > > >> >> 7c
> > > > > > >> >> 7
> > > > > > >> >>
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > > > > >> >> UP
> > > > > > >> >> 7AY
> > > > > > >> >> 4q
> > > > > > >> >> E
> > > > > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > > > > >> >>>
> > > > > > >> >>>
> > > > > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > > > > >> >>> <cs...@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
> > > > > > >> >>>> %2f
> > > > > > >> >>>> g
> > > > > > >> >>>> ithu
> > > > > > >> >>>> https://na01.safelinks.protection.outlook.com/?url=b
> > > > > > >> >>>> .com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.co
> > > > > > >> >>>> m%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988bf86f14
> > > > > > >> >>>> 1af91ab2d7cd011db47%7c1&sdata=%2btIES1o7b5uhk8jzLG3M
> > > > > > >> >>>> uXBY3UBAw1nGWj6b4FcA1NU%3d
> > %2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > > > > >> >>>> =0
> > > > > > >> >>>> 1%7
> > > > > > >> >>>> c
> > > > > > >> >>>> 01%7
> > > > > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com
> > %7c73b4ff38f0fe41e1f18608d
> > > > > > >> >>>> 2c
> > > > > > >> >>>> 5c7
> > > > > > >> >>>> 0
> > > > > > >> >>>> e0f%
> > > > > > >> >>>>
> > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > > > > >> >>>> bm
> > > > > > >> >>>> Vx5
> > > > > > >> >>>> 0
> > > > > > >> >>>> QKD2
> > > > > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov
> (Akvelon) <
> > > > > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > > > > >> >>>>>> a%
> > > > > > >> >>>>>> 2f%
> > > > > > >> >>>>>> 2fis
> > > > > > >> >>>>>> sue
> > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > >> >>>>>> =s.apache.org&data=01%7c01%7cv-vlkoti%40064d.mgd.m
> > > > > > >> >>>>>> icrosoft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c
> > > > > > >> >>>>>> 72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q3M6hF6
> > > > > > >> >>>>>> dtJswbfQZK8vSvlyeWhrf41qEZSPRQxKqhF8%3d
> > %2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > > > > >> >>>>>> gr
> > > > > > >> >>>>>> eb%
> > > > > > >> >>>>>> 40mi
> > > > > > >> >>>>>> cro
> > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > >> >>>>>> =soft.com&data=01%7c01%7cv-vlkoti%40064d.mgd.micro
> > > > > > >> >>>>>> soft.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f9
> > > > > > >> >>>>>> 88bf86f141af91ab2d7cd011db47%7c1&sdata=aZRwcGSJxvv
> > > > > > >> >>>>>> tHxOesdVojD5kU8B0uKoNhnLovqu6OSA%3d
> > %7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > > > > >> >>>>>> 41
> > > > > > >> >>>>>> af9
> > > > > > >> >>>>>> 1ab2
> > > > > > >> >>>>>> d7c
> > > > > > >> >>>>>>
> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > > > > >> >>>>>> rT
> > > > > > >> >>>>>> jwX
> > > > > > >> >>>>>> TXk%
> > > > > > >> >>>>>> 3d
> > > > > > >> >>>>>> [2]
> > > > > > >> >>>>>>
> > https://na01.safelinks.protection.outlook.com/?url=https%3
> > > > > > >> >>>>>> a%
> > > > > > >> >>>>>> 2f%
> > > > > > >> >>>>>> 2fgi
> > > > > > >> >>>>>> thu
> > > > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url
> > > > > > >> >>>>>> =b.com&data=01%7c01%7cv-vlkoti%40064d.mgd.microsof
> > > > > > >> >>>>>> t.com%7c3679b90fa2504b104d0208d2dc135ab0%7c72f988b
> > > > > > >> >>>>>> f86f141af91ab2d7cd011db47%7c1&sdata=%2btIES1o7b5uh
> > > > > > >> >>>>>> k8jzLG3MuXBY3UBAw1nGWj6b4FcA1NU%3d
> > %2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > > > > >> >>>>>> mo
> > > > > > >> >>>>>> n&d
> > > > > > >> >>>>>> ata=
> > > > > > >> >>>>>> 01%
> > > > > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com
> > %7cf31529ebb0de4bf28ebd08d2
> > > > > > >> >>>>>> c5
> > > > > > >> >>>>>> 491
> > > > > > >> >>>>>> 5f3%
> > > > > > >> >>>>>> 7c7
> > > > > > >> >>>>>>
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > > > > >> >>>>>> I9
> > > > > > >> >>>>>> ASf
> > > > > > >> >>>>>> QMku
> > > > > > >> >>>>>> RV0
> > > > > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > > > > >> >>>>>>
> > > > > > >> >>>>>> Thx!
> > > > > > >> >>>>>> Sergey
> > > > > > >> >>>>>>
> > > > > > >> >>>>>>
> > ----------------------------------------------------------
> > > > > > >> >>>>>> --
> > > > > > >> >>>>>> ---
> > > > > > >> >>>>>> ----
> > > > > > >> >>>>>> -- To unsubscribe, e-mail:
> > > > > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > > > > >> >>>>>> For additional commands, e-mail:
> > > > > > >> >>>>>> dev-help@cordova.apache.org
> > > > > > >> >>>
> > > > > > >> >>>
> > -------------------------------------------------------------
> > > > > > >> >>> --
> > > > > > >> >>> ---
> > > > > > >> >>> --
> > > > > > >> >>> - To unsubscribe, e-mail:
> > dev-unsubscribe@cordova.apache.org
> > > > > > >> >>> For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > > > > > >> >
> > > > > > >> >
> > ---------------------------------------------------------------
> > > > > > >> > --
> > > > > > >> > ---
> > > > > > >> > - To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> > > > > > >> > For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > > > > >>
> > > > > > >>
> > -----------------------------------------------------------------
> > > > > > >> --
> > > > > > >> -- To unsubscribe, e-mail:
> > > > > > >> dev-unsubscribe@cordova.apache.org
> > > > > > >> For additional commands, e-mail:
> > > > > > >> dev-help@cordova.apache.org
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > -----------------------------------------------------------------
> > > > > > >> --
> > > > > > >> -- To unsubscribe, e-mail:
> > > > > > >> dev-unsubscribe@cordova.apache.org
> > > > > > >> For additional commands, e-mail:
> > > > > > >> dev-help@cordova.apache.org
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > > >?B
> > > > > >
> >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > > > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > > > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > > > > >
> > > > > >
> > --------------------------------------------------------------------
> > > > > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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 <st...@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 <cs...@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 <st...@gmail.com>
> > wrote:
> >
> > > DO IT!
> > >
> > > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
> > > v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> > > > Sent: Wednesday, October 21, 2015 9:19 AM
> > > > To: dev <de...@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 <
> > > nikhilkh@microsoft.com
> > > > >
> > > > wrote:
> > > >
> > > > > It got checked in earlier this morning.
> > > > >
> > > > > -Nikhil
> > > > >
> > > > > -----Original Message-----
> > > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > > Sent: Tuesday, October 20, 2015 2:34 PM
> > > > > To: dev <de...@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 <
> > panarasi@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" <
> nikhilkh@microsoft.com>
> > > > > wrote:
> > > > > >
> > > > > > >+1 to publishing cordova-common to npm.
> > > > > > >
> > > > > > >-Nikhil
> > > > > > >
> > > > > > >-----Original Message-----
> > > > > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > > > > >> > 2f
> > > > > > >> > git
> > > > > > >> > hu
> > > > > > >> > b.com
> > %2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > > > > >> > ti
> > > > > > >> > %40
> > > > > > >> > 06
> > > > > > >> > 4d.mgd.microsoft.com
> > %7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > > > > >> > 8b
> > > > > > >> > f86
> > > > > > >> > f1
> > > > > > >> >
> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > > > > >> > fm
> > > > > > >> > %2b
> > > > > > >> > do
> > > > > > >> > 9WX4V4JfT0%3d
> > > > > > >> >
> > > > > > >> > -
> > > > > > >> > Best regards, Vladimir.
> > > > > > >> >
> > > > > > >> > -----Original Message-----
> > > > > > >> > From: Carlos Santana [mailto:csantana23@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
> > > > > > >> >> <st...@gmail.com>
> > > > > > >> wrote:
> > > > > > >> >>
> > > > > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > > > > > >> >> "Nikhil Khandelwal"
> > > > > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > > > > >> >> %2
> > > > > > >> >> fgi
> > > > > > >> >> th
> > > > > > >> >> u
> > > > > > >> >> b.com
> > %2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > > > > >> >> c0
> > > > > > >> >> 1%7
> > > > > > >> >> cv
> > > > > > >> >> -
> > > > > > >> >> vlkoti%40064d.mgd.microsoft.com
> > %7c73b4ff38f0fe41e1f18608d2c5c7
> > > > > > >> >> 0e
> > > > > > >> >> 0f%
> > > > > > >> >> 7c
> > > > > > >> >> 7
> > > > > > >> >>
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > > > > >> >> UP
> > > > > > >> >> 7AY
> > > > > > >> >> 4q
> > > > > > >> >> E
> > > > > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > > > > >> >>>
> > > > > > >> >>>
> > > > > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > > > > >> >>> <cs...@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
> > > > > > >> >>>> %2f
> > > > > > >> >>>> g
> > > > > > >> >>>> ithu
> > > > > > >> >>>> b.com
> > %2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > > > > >> >>>> =0
> > > > > > >> >>>> 1%7
> > > > > > >> >>>> c
> > > > > > >> >>>> 01%7
> > > > > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com
> > %7c73b4ff38f0fe41e1f18608d
> > > > > > >> >>>> 2c
> > > > > > >> >>>> 5c7
> > > > > > >> >>>> 0
> > > > > > >> >>>> e0f%
> > > > > > >> >>>>
> > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > > > > >> >>>> bm
> > > > > > >> >>>> Vx5
> > > > > > >> >>>> 0
> > > > > > >> >>>> QKD2
> > > > > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>>
> > > > > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov
> (Akvelon) <
> > > > > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > > > > >> >>>>>> a%
> > > > > > >> >>>>>> 2f%
> > > > > > >> >>>>>> 2fis
> > > > > > >> >>>>>> sue
> > > > > > >> >>>>>> s.apache.org
> > %2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > > > > >> >>>>>> gr
> > > > > > >> >>>>>> eb%
> > > > > > >> >>>>>> 40mi
> > > > > > >> >>>>>> cro
> > > > > > >> >>>>>> soft.com
> > %7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > > > > >> >>>>>> 41
> > > > > > >> >>>>>> af9
> > > > > > >> >>>>>> 1ab2
> > > > > > >> >>>>>> d7c
> > > > > > >> >>>>>>
> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > > > > >> >>>>>> rT
> > > > > > >> >>>>>> jwX
> > > > > > >> >>>>>> TXk%
> > > > > > >> >>>>>> 3d
> > > > > > >> >>>>>> [2]
> > > > > > >> >>>>>>
> > https://na01.safelinks.protection.outlook.com/?url=https%3
> > > > > > >> >>>>>> a%
> > > > > > >> >>>>>> 2f%
> > > > > > >> >>>>>> 2fgi
> > > > > > >> >>>>>> thu
> > > > > > >> >>>>>> b.com
> > %2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > > > > >> >>>>>> mo
> > > > > > >> >>>>>> n&d
> > > > > > >> >>>>>> ata=
> > > > > > >> >>>>>> 01%
> > > > > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com
> > %7cf31529ebb0de4bf28ebd08d2
> > > > > > >> >>>>>> c5
> > > > > > >> >>>>>> 491
> > > > > > >> >>>>>> 5f3%
> > > > > > >> >>>>>> 7c7
> > > > > > >> >>>>>>
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > > > > >> >>>>>> I9
> > > > > > >> >>>>>> ASf
> > > > > > >> >>>>>> QMku
> > > > > > >> >>>>>> RV0
> > > > > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > > > > >> >>>>>>
> > > > > > >> >>>>>> Thx!
> > > > > > >> >>>>>> Sergey
> > > > > > >> >>>>>>
> > > > > > >> >>>>>>
> > ----------------------------------------------------------
> > > > > > >> >>>>>> --
> > > > > > >> >>>>>> ---
> > > > > > >> >>>>>> ----
> > > > > > >> >>>>>> -- To unsubscribe, e-mail:
> > > > > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > > > > >> >>>>>> For additional commands, e-mail:
> > > > > > >> >>>>>> dev-help@cordova.apache.org
> > > > > > >> >>>
> > > > > > >> >>>
> > -------------------------------------------------------------
> > > > > > >> >>> --
> > > > > > >> >>> ---
> > > > > > >> >>> --
> > > > > > >> >>> - To unsubscribe, e-mail:
> > dev-unsubscribe@cordova.apache.org
> > > > > > >> >>> For additional commands, e-mail:
> > dev-help@cordova.apache.org
> > > > > > >> >
> > > > > > >> >
> > ---------------------------------------------------------------
> > > > > > >> > --
> > > > > > >> > ---
> > > > > > >> > - To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> > > > > > >> > For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > > > > >>
> > > > > > >>
> > -----------------------------------------------------------------
> > > > > > >> --
> > > > > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > -----------------------------------------------------------------
> > > > > > >> --
> > > > > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > > >>
> > > > > > >>
> > > > > >
> > > > > > >?B
> > > > > >
> >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > > > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > > > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > > > > >
> > > > > >
> > --------------------------------------------------------------------
> > > > > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [Discuss] Cordova-common release
Posted by Steven Gill <st...@gmail.com>.
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 <cs...@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 <st...@gmail.com>
> wrote:
>
> > DO IT!
> >
> > On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
> > v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> > > Sent: Wednesday, October 21, 2015 9:19 AM
> > > To: dev <de...@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 <
> > nikhilkh@microsoft.com
> > > >
> > > wrote:
> > >
> > > > It got checked in earlier this morning.
> > > >
> > > > -Nikhil
> > > >
> > > > -----Original Message-----
> > > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > > Sent: Tuesday, October 20, 2015 2:34 PM
> > > > To: dev <de...@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 <
> panarasi@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" <ni...@microsoft.com>
> > > > wrote:
> > > > >
> > > > > >+1 to publishing cordova-common to npm.
> > > > > >
> > > > > >-Nikhil
> > > > > >
> > > > > >-----Original Message-----
> > > > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > > > >> > 2f
> > > > > >> > git
> > > > > >> > hu
> > > > > >> > b.com
> %2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > > > >> > ti
> > > > > >> > %40
> > > > > >> > 06
> > > > > >> > 4d.mgd.microsoft.com
> %7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > > > >> > 8b
> > > > > >> > f86
> > > > > >> > f1
> > > > > >> >
> 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > > > >> > fm
> > > > > >> > %2b
> > > > > >> > do
> > > > > >> > 9WX4V4JfT0%3d
> > > > > >> >
> > > > > >> > -
> > > > > >> > Best regards, Vladimir.
> > > > > >> >
> > > > > >> > -----Original Message-----
> > > > > >> > From: Carlos Santana [mailto:csantana23@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
> > > > > >> >> <st...@gmail.com>
> > > > > >> wrote:
> > > > > >> >>
> > > > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > > > > >> >> "Nikhil Khandelwal"
> > > > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > > > >> >> %2
> > > > > >> >> fgi
> > > > > >> >> th
> > > > > >> >> u
> > > > > >> >> b.com
> %2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > > > >> >> c0
> > > > > >> >> 1%7
> > > > > >> >> cv
> > > > > >> >> -
> > > > > >> >> vlkoti%40064d.mgd.microsoft.com
> %7c73b4ff38f0fe41e1f18608d2c5c7
> > > > > >> >> 0e
> > > > > >> >> 0f%
> > > > > >> >> 7c
> > > > > >> >> 7
> > > > > >> >>
> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > > > >> >> UP
> > > > > >> >> 7AY
> > > > > >> >> 4q
> > > > > >> >> E
> > > > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > > > >> >>>
> > > > > >> >>>
> > > > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > > > >> >>> <cs...@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
> > > > > >> >>>> %2f
> > > > > >> >>>> g
> > > > > >> >>>> ithu
> > > > > >> >>>> b.com
> %2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > > > >> >>>> =0
> > > > > >> >>>> 1%7
> > > > > >> >>>> c
> > > > > >> >>>> 01%7
> > > > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com
> %7c73b4ff38f0fe41e1f18608d
> > > > > >> >>>> 2c
> > > > > >> >>>> 5c7
> > > > > >> >>>> 0
> > > > > >> >>>> e0f%
> > > > > >> >>>>
> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > > > >> >>>> bm
> > > > > >> >>>> Vx5
> > > > > >> >>>> 0
> > > > > >> >>>> QKD2
> > > > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > > > >> >>>>
> > > > > >> >>>>
> > > > > >> >>>>
> > > > > >> >>>>
> > > > > >> >>>>
> > > > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > > > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > > > >> >>>>>> a%
> > > > > >> >>>>>> 2f%
> > > > > >> >>>>>> 2fis
> > > > > >> >>>>>> sue
> > > > > >> >>>>>> s.apache.org
> %2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > > > >> >>>>>> gr
> > > > > >> >>>>>> eb%
> > > > > >> >>>>>> 40mi
> > > > > >> >>>>>> cro
> > > > > >> >>>>>> soft.com
> %7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > > > >> >>>>>> 41
> > > > > >> >>>>>> af9
> > > > > >> >>>>>> 1ab2
> > > > > >> >>>>>> d7c
> > > > > >> >>>>>>
> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > > > >> >>>>>> rT
> > > > > >> >>>>>> jwX
> > > > > >> >>>>>> TXk%
> > > > > >> >>>>>> 3d
> > > > > >> >>>>>> [2]
> > > > > >> >>>>>>
> https://na01.safelinks.protection.outlook.com/?url=https%3
> > > > > >> >>>>>> a%
> > > > > >> >>>>>> 2f%
> > > > > >> >>>>>> 2fgi
> > > > > >> >>>>>> thu
> > > > > >> >>>>>> b.com
> %2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > > > >> >>>>>> mo
> > > > > >> >>>>>> n&d
> > > > > >> >>>>>> ata=
> > > > > >> >>>>>> 01%
> > > > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com
> %7cf31529ebb0de4bf28ebd08d2
> > > > > >> >>>>>> c5
> > > > > >> >>>>>> 491
> > > > > >> >>>>>> 5f3%
> > > > > >> >>>>>> 7c7
> > > > > >> >>>>>>
> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > > > >> >>>>>> I9
> > > > > >> >>>>>> ASf
> > > > > >> >>>>>> QMku
> > > > > >> >>>>>> RV0
> > > > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > > > >> >>>>>>
> > > > > >> >>>>>> Thx!
> > > > > >> >>>>>> Sergey
> > > > > >> >>>>>>
> > > > > >> >>>>>>
> ----------------------------------------------------------
> > > > > >> >>>>>> --
> > > > > >> >>>>>> ---
> > > > > >> >>>>>> ----
> > > > > >> >>>>>> -- To unsubscribe, e-mail:
> > > > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > > > >> >>>>>> For additional commands, e-mail:
> > > > > >> >>>>>> dev-help@cordova.apache.org
> > > > > >> >>>
> > > > > >> >>>
> -------------------------------------------------------------
> > > > > >> >>> --
> > > > > >> >>> ---
> > > > > >> >>> --
> > > > > >> >>> - To unsubscribe, e-mail:
> dev-unsubscribe@cordova.apache.org
> > > > > >> >>> For additional commands, e-mail:
> dev-help@cordova.apache.org
> > > > > >> >
> > > > > >> >
> ---------------------------------------------------------------
> > > > > >> > --
> > > > > >> > ---
> > > > > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >>
> > > > > >>
> -----------------------------------------------------------------
> > > > > >> --
> > > > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >>
> > > > > >>
> > > > > >>
> -----------------------------------------------------------------
> > > > > >> --
> > > > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > > >>
> > > > > >>
> > > > >
> > > > > >?B
> > > > > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > > > >
> > > > >
> --------------------------------------------------------------------
> > > > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >
> > > >
> > >
> >
>
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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 <st...@gmail.com> wrote:
> DO IT!
>
> On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
> v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> > Sent: Wednesday, October 21, 2015 9:19 AM
> > To: dev <de...@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 <
> nikhilkh@microsoft.com
> > >
> > wrote:
> >
> > > It got checked in earlier this morning.
> > >
> > > -Nikhil
> > >
> > > -----Original Message-----
> > > From: Joe Bowser [mailto:bowserj@gmail.com]
> > > Sent: Tuesday, October 20, 2015 2:34 PM
> > > To: dev <de...@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 <pa...@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" <ni...@microsoft.com>
> > > wrote:
> > > >
> > > > >+1 to publishing cordova-common to npm.
> > > > >
> > > > >-Nikhil
> > > > >
> > > > >-----Original Message-----
> > > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > > >> > 2f
> > > > >> > git
> > > > >> > hu
> > > > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > > >> > ti
> > > > >> > %40
> > > > >> > 06
> > > > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > > >> > 8b
> > > > >> > f86
> > > > >> > f1
> > > > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > > >> > fm
> > > > >> > %2b
> > > > >> > do
> > > > >> > 9WX4V4JfT0%3d
> > > > >> >
> > > > >> > -
> > > > >> > Best regards, Vladimir.
> > > > >> >
> > > > >> > -----Original Message-----
> > > > >> > From: Carlos Santana [mailto:csantana23@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
> > > > >> >> <st...@gmail.com>
> > > > >> wrote:
> > > > >> >>
> > > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > > > >> >> "Nikhil Khandelwal"
> > > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > > >> >> %2
> > > > >> >> fgi
> > > > >> >> th
> > > > >> >> u
> > > > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > > >> >> c0
> > > > >> >> 1%7
> > > > >> >> cv
> > > > >> >> -
> > > > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> > > > >> >> 0e
> > > > >> >> 0f%
> > > > >> >> 7c
> > > > >> >> 7
> > > > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > > >> >> UP
> > > > >> >> 7AY
> > > > >> >> 4q
> > > > >> >> E
> > > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > > >> >>>
> > > > >> >>>
> > > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > > >> >>> <cs...@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
> > > > >> >>>> %2f
> > > > >> >>>> g
> > > > >> >>>> ithu
> > > > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > > >> >>>> =0
> > > > >> >>>> 1%7
> > > > >> >>>> c
> > > > >> >>>> 01%7
> > > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d
> > > > >> >>>> 2c
> > > > >> >>>> 5c7
> > > > >> >>>> 0
> > > > >> >>>> e0f%
> > > > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > > >> >>>> bm
> > > > >> >>>> Vx5
> > > > >> >>>> 0
> > > > >> >>>> QKD2
> > > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>>
> > > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > > >> >>>>>> a%
> > > > >> >>>>>> 2f%
> > > > >> >>>>>> 2fis
> > > > >> >>>>>> sue
> > > > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > > >> >>>>>> gr
> > > > >> >>>>>> eb%
> > > > >> >>>>>> 40mi
> > > > >> >>>>>> cro
> > > > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > > >> >>>>>> 41
> > > > >> >>>>>> af9
> > > > >> >>>>>> 1ab2
> > > > >> >>>>>> d7c
> > > > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > > >> >>>>>> rT
> > > > >> >>>>>> jwX
> > > > >> >>>>>> TXk%
> > > > >> >>>>>> 3d
> > > > >> >>>>>> [2]
> > > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > > > >> >>>>>> a%
> > > > >> >>>>>> 2f%
> > > > >> >>>>>> 2fgi
> > > > >> >>>>>> thu
> > > > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > > >> >>>>>> mo
> > > > >> >>>>>> n&d
> > > > >> >>>>>> ata=
> > > > >> >>>>>> 01%
> > > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2
> > > > >> >>>>>> c5
> > > > >> >>>>>> 491
> > > > >> >>>>>> 5f3%
> > > > >> >>>>>> 7c7
> > > > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > > >> >>>>>> I9
> > > > >> >>>>>> ASf
> > > > >> >>>>>> QMku
> > > > >> >>>>>> RV0
> > > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > > >> >>>>>>
> > > > >> >>>>>> Thx!
> > > > >> >>>>>> Sergey
> > > > >> >>>>>>
> > > > >> >>>>>> ----------------------------------------------------------
> > > > >> >>>>>> --
> > > > >> >>>>>> ---
> > > > >> >>>>>> ----
> > > > >> >>>>>> -- To unsubscribe, e-mail:
> > > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > > >> >>>>>> For additional commands, e-mail:
> > > > >> >>>>>> dev-help@cordova.apache.org
> > > > >> >>>
> > > > >> >>> -------------------------------------------------------------
> > > > >> >>> --
> > > > >> >>> ---
> > > > >> >>> --
> > > > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >> >
> > > > >> > ---------------------------------------------------------------
> > > > >> > --
> > > > >> > ---
> > > > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >>
> > > > >> -----------------------------------------------------------------
> > > > >> --
> > > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >>
> > > > >>
> > > > >> -----------------------------------------------------------------
> > > > >> --
> > > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > > >>
> > > > >>
> > > >
> > > > >?B
> > > > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > > >
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >
> > >
> >
>
Re: [Discuss] Cordova-common release
Posted by Steven Gill <st...@gmail.com>.
DO IT!
On Thu, Oct 22, 2015 at 11:44 AM, Vladimir Kotikov (Akvelon) <
v-vlkoti@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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
> Sent: Wednesday, October 21, 2015 9:19 AM
> To: dev <de...@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 <nikhilkh@microsoft.com
> >
> wrote:
>
> > It got checked in earlier this morning.
> >
> > -Nikhil
> >
> > -----Original Message-----
> > From: Joe Bowser [mailto:bowserj@gmail.com]
> > Sent: Tuesday, October 20, 2015 2:34 PM
> > To: dev <de...@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 <pa...@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" <ni...@microsoft.com>
> > wrote:
> > >
> > > >+1 to publishing cordova-common to npm.
> > > >
> > > >-Nikhil
> > > >
> > > >-----Original Message-----
> > > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > > >> > 2f
> > > >> > git
> > > >> > hu
> > > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > > >> > ti
> > > >> > %40
> > > >> > 06
> > > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > > >> > 8b
> > > >> > f86
> > > >> > f1
> > > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > > >> > fm
> > > >> > %2b
> > > >> > do
> > > >> > 9WX4V4JfT0%3d
> > > >> >
> > > >> > -
> > > >> > Best regards, Vladimir.
> > > >> >
> > > >> > -----Original Message-----
> > > >> > From: Carlos Santana [mailto:csantana23@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
> > > >> >> <st...@gmail.com>
> > > >> wrote:
> > > >> >>
> > > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > > >> >> "Nikhil Khandelwal"
> > > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > > >> >> %2
> > > >> >> fgi
> > > >> >> th
> > > >> >> u
> > > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > > >> >> c0
> > > >> >> 1%7
> > > >> >> cv
> > > >> >> -
> > > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> > > >> >> 0e
> > > >> >> 0f%
> > > >> >> 7c
> > > >> >> 7
> > > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > > >> >> UP
> > > >> >> 7AY
> > > >> >> 4q
> > > >> >> E
> > > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > > >> >>>
> > > >> >>>
> > > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > > >> >>> <cs...@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
> > > >> >>>> %2f
> > > >> >>>> g
> > > >> >>>> ithu
> > > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > > >> >>>> =0
> > > >> >>>> 1%7
> > > >> >>>> c
> > > >> >>>> 01%7
> > > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d
> > > >> >>>> 2c
> > > >> >>>> 5c7
> > > >> >>>> 0
> > > >> >>>> e0f%
> > > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > > >> >>>> bm
> > > >> >>>> Vx5
> > > >> >>>> 0
> > > >> >>>> QKD2
> > > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>>
> > > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > > >> >>>>>> a%
> > > >> >>>>>> 2f%
> > > >> >>>>>> 2fis
> > > >> >>>>>> sue
> > > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > > >> >>>>>> gr
> > > >> >>>>>> eb%
> > > >> >>>>>> 40mi
> > > >> >>>>>> cro
> > > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > > >> >>>>>> 41
> > > >> >>>>>> af9
> > > >> >>>>>> 1ab2
> > > >> >>>>>> d7c
> > > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > > >> >>>>>> rT
> > > >> >>>>>> jwX
> > > >> >>>>>> TXk%
> > > >> >>>>>> 3d
> > > >> >>>>>> [2]
> > > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > > >> >>>>>> a%
> > > >> >>>>>> 2f%
> > > >> >>>>>> 2fgi
> > > >> >>>>>> thu
> > > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > > >> >>>>>> mo
> > > >> >>>>>> n&d
> > > >> >>>>>> ata=
> > > >> >>>>>> 01%
> > > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2
> > > >> >>>>>> c5
> > > >> >>>>>> 491
> > > >> >>>>>> 5f3%
> > > >> >>>>>> 7c7
> > > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > > >> >>>>>> I9
> > > >> >>>>>> ASf
> > > >> >>>>>> QMku
> > > >> >>>>>> RV0
> > > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > > >> >>>>>>
> > > >> >>>>>> Thx!
> > > >> >>>>>> Sergey
> > > >> >>>>>>
> > > >> >>>>>> ----------------------------------------------------------
> > > >> >>>>>> --
> > > >> >>>>>> ---
> > > >> >>>>>> ----
> > > >> >>>>>> -- To unsubscribe, e-mail:
> > > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > > >> >>>>>> For additional commands, e-mail:
> > > >> >>>>>> dev-help@cordova.apache.org
> > > >> >>>
> > > >> >>> -------------------------------------------------------------
> > > >> >>> --
> > > >> >>> ---
> > > >> >>> --
> > > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >> >
> > > >> > ---------------------------------------------------------------
> > > >> > --
> > > >> > ---
> > > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >> -----------------------------------------------------------------
> > > >> --
> > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >>
> > > >> -----------------------------------------------------------------
> > > >> --
> > > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > > >>
> > > >>
> > >
> > > >?B
> > > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
>
RE: [Discuss] Cordova-common release
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
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-vlkoti@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:nikhilkh@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:bowserj@gmail.com]
Sent: Wednesday, October 21, 2015 9:19 AM
To: dev <de...@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 <ni...@microsoft.com>
wrote:
> It got checked in earlier this morning.
>
> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, October 20, 2015 2:34 PM
> To: dev <de...@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 <pa...@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" <ni...@microsoft.com>
> wrote:
> >
> > >+1 to publishing cordova-common to npm.
> > >
> > >-Nikhil
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > >> > 2f
> > >> > git
> > >> > hu
> > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > >> > ti
> > >> > %40
> > >> > 06
> > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > >> > 8b
> > >> > f86
> > >> > f1
> > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > >> > fm
> > >> > %2b
> > >> > do
> > >> > 9WX4V4JfT0%3d
> > >> >
> > >> > -
> > >> > Best regards, Vladimir.
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carlos Santana [mailto:csantana23@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
> > >> >> <st...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > >> >> "Nikhil Khandelwal"
> > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > >> >> %2
> > >> >> fgi
> > >> >> th
> > >> >> u
> > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > >> >> c0
> > >> >> 1%7
> > >> >> cv
> > >> >> -
> > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> > >> >> 0e
> > >> >> 0f%
> > >> >> 7c
> > >> >> 7
> > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > >> >> UP
> > >> >> 7AY
> > >> >> 4q
> > >> >> E
> > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > >> >>> <cs...@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
> > >> >>>> %2f
> > >> >>>> g
> > >> >>>> ithu
> > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > >> >>>> =0
> > >> >>>> 1%7
> > >> >>>> c
> > >> >>>> 01%7
> > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d
> > >> >>>> 2c
> > >> >>>> 5c7
> > >> >>>> 0
> > >> >>>> e0f%
> > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > >> >>>> bm
> > >> >>>> Vx5
> > >> >>>> 0
> > >> >>>> QKD2
> > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fis
> > >> >>>>>> sue
> > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > >> >>>>>> gr
> > >> >>>>>> eb%
> > >> >>>>>> 40mi
> > >> >>>>>> cro
> > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > >> >>>>>> 41
> > >> >>>>>> af9
> > >> >>>>>> 1ab2
> > >> >>>>>> d7c
> > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > >> >>>>>> rT
> > >> >>>>>> jwX
> > >> >>>>>> TXk%
> > >> >>>>>> 3d
> > >> >>>>>> [2]
> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fgi
> > >> >>>>>> thu
> > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > >> >>>>>> mo
> > >> >>>>>> n&d
> > >> >>>>>> ata=
> > >> >>>>>> 01%
> > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2
> > >> >>>>>> c5
> > >> >>>>>> 491
> > >> >>>>>> 5f3%
> > >> >>>>>> 7c7
> > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > >> >>>>>> I9
> > >> >>>>>> ASf
> > >> >>>>>> QMku
> > >> >>>>>> RV0
> > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > >> >>>>>>
> > >> >>>>>> Thx!
> > >> >>>>>> Sergey
> > >> >>>>>>
> > >> >>>>>> ----------------------------------------------------------
> > >> >>>>>> --
> > >> >>>>>> ---
> > >> >>>>>> ----
> > >> >>>>>> -- To unsubscribe, e-mail:
> > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > >> >>>>>> For additional commands, e-mail:
> > >> >>>>>> dev-help@cordova.apache.org
> > >> >>>
> > >> >>> -------------------------------------------------------------
> > >> >>> --
> > >> >>> ---
> > >> >>> --
> > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> > ---------------------------------------------------------------
> > >> > --
> > >> > ---
> > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > >?B
> > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
RE: [Discuss] Cordova-common release
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
> 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:nikhilkh@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:bowserj@gmail.com]
Sent: Wednesday, October 21, 2015 9:19 AM
To: dev <de...@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 <ni...@microsoft.com>
wrote:
> It got checked in earlier this morning.
>
> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, October 20, 2015 2:34 PM
> To: dev <de...@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 <pa...@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" <ni...@microsoft.com>
> wrote:
> >
> > >+1 to publishing cordova-common to npm.
> > >
> > >-Nikhil
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > >> > 2f
> > >> > git
> > >> > hu
> > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > >> > ti
> > >> > %40
> > >> > 06
> > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > >> > 8b
> > >> > f86
> > >> > f1
> > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > >> > fm
> > >> > %2b
> > >> > do
> > >> > 9WX4V4JfT0%3d
> > >> >
> > >> > -
> > >> > Best regards, Vladimir.
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carlos Santana [mailto:csantana23@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
> > >> >> <st...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > >> >> "Nikhil Khandelwal"
> > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > >> >> %2
> > >> >> fgi
> > >> >> th
> > >> >> u
> > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > >> >> c0
> > >> >> 1%7
> > >> >> cv
> > >> >> -
> > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> > >> >> 0e
> > >> >> 0f%
> > >> >> 7c
> > >> >> 7
> > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > >> >> UP
> > >> >> 7AY
> > >> >> 4q
> > >> >> E
> > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > >> >>> <cs...@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
> > >> >>>> %2f
> > >> >>>> g
> > >> >>>> ithu
> > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > >> >>>> =0
> > >> >>>> 1%7
> > >> >>>> c
> > >> >>>> 01%7
> > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d
> > >> >>>> 2c
> > >> >>>> 5c7
> > >> >>>> 0
> > >> >>>> e0f%
> > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > >> >>>> bm
> > >> >>>> Vx5
> > >> >>>> 0
> > >> >>>> QKD2
> > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fis
> > >> >>>>>> sue
> > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > >> >>>>>> gr
> > >> >>>>>> eb%
> > >> >>>>>> 40mi
> > >> >>>>>> cro
> > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > >> >>>>>> 41
> > >> >>>>>> af9
> > >> >>>>>> 1ab2
> > >> >>>>>> d7c
> > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > >> >>>>>> rT
> > >> >>>>>> jwX
> > >> >>>>>> TXk%
> > >> >>>>>> 3d
> > >> >>>>>> [2]
> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fgi
> > >> >>>>>> thu
> > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > >> >>>>>> mo
> > >> >>>>>> n&d
> > >> >>>>>> ata=
> > >> >>>>>> 01%
> > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2
> > >> >>>>>> c5
> > >> >>>>>> 491
> > >> >>>>>> 5f3%
> > >> >>>>>> 7c7
> > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > >> >>>>>> I9
> > >> >>>>>> ASf
> > >> >>>>>> QMku
> > >> >>>>>> RV0
> > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > >> >>>>>>
> > >> >>>>>> Thx!
> > >> >>>>>> Sergey
> > >> >>>>>>
> > >> >>>>>> ----------------------------------------------------------
> > >> >>>>>> --
> > >> >>>>>> ---
> > >> >>>>>> ----
> > >> >>>>>> -- To unsubscribe, e-mail:
> > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > >> >>>>>> For additional commands, e-mail:
> > >> >>>>>> dev-help@cordova.apache.org
> > >> >>>
> > >> >>> -------------------------------------------------------------
> > >> >>> --
> > >> >>> ---
> > >> >>> --
> > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> > ---------------------------------------------------------------
> > >> > --
> > >> > ---
> > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > >?B
> > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
RE: [Discuss] Cordova-common release
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
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:bowserj@gmail.com]
Sent: Wednesday, October 21, 2015 9:19 AM
To: dev <de...@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 <ni...@microsoft.com>
wrote:
> It got checked in earlier this morning.
>
> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, October 20, 2015 2:34 PM
> To: dev <de...@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 <pa...@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" <ni...@microsoft.com>
> wrote:
> >
> > >+1 to publishing cordova-common to npm.
> > >
> > >-Nikhil
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%
> > >> > 2f
> > >> > git
> > >> > hu
> > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlko
> > >> > ti
> > >> > %40
> > >> > 06
> > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f98
> > >> > 8b
> > >> > f86
> > >> > f1
> > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2
> > >> > fm
> > >> > %2b
> > >> > do
> > >> > 9WX4V4JfT0%3d
> > >> >
> > >> > -
> > >> > Best regards, Vladimir.
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carlos Santana [mailto:csantana23@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
> > >> >> <st...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> Sounds good. Let's move forward On Sep 29, 2015 10:21 AM,
> > >> >> "Nikhil Khandelwal"
> > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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
> > >> >> %2
> > >> >> fgi
> > >> >> th
> > >> >> u
> > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7
> > >> >> c0
> > >> >> 1%7
> > >> >> cv
> > >> >> -
> > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> > >> >> 0e
> > >> >> 0f%
> > >> >> 7c
> > >> >> 7
> > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2f
> > >> >> UP
> > >> >> 7AY
> > >> >> 4q
> > >> >> E
> > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > >> >>> <cs...@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
> > >> >>>> %2f
> > >> >>>> g
> > >> >>>> ithu
> > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data
> > >> >>>> =0
> > >> >>>> 1%7
> > >> >>>> c
> > >> >>>> 01%7
> > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d
> > >> >>>> 2c
> > >> >>>> 5c7
> > >> >>>> 0
> > >> >>>> e0f%
> > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPu
> > >> >>>> bm
> > >> >>>> Vx5
> > >> >>>> 0
> > >> >>>> QKD2
> > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > >> >>>> v-segreb@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:csantana23@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-segreb@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%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fis
> > >> >>>>>> sue
> > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-se
> > >> >>>>>> gr
> > >> >>>>>> eb%
> > >> >>>>>> 40mi
> > >> >>>>>> cro
> > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f1
> > >> >>>>>> 41
> > >> >>>>>> af9
> > >> >>>>>> 1ab2
> > >> >>>>>> d7c
> > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOo
> > >> >>>>>> rT
> > >> >>>>>> jwX
> > >> >>>>>> TXk%
> > >> >>>>>> 3d
> > >> >>>>>> [2]
> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3
> > >> >>>>>> a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fgi
> > >> >>>>>> thu
> > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-com
> > >> >>>>>> mo
> > >> >>>>>> n&d
> > >> >>>>>> ata=
> > >> >>>>>> 01%
> > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2
> > >> >>>>>> c5
> > >> >>>>>> 491
> > >> >>>>>> 5f3%
> > >> >>>>>> 7c7
> > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4
> > >> >>>>>> I9
> > >> >>>>>> ASf
> > >> >>>>>> QMku
> > >> >>>>>> RV0
> > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > >> >>>>>>
> > >> >>>>>> Thx!
> > >> >>>>>> Sergey
> > >> >>>>>>
> > >> >>>>>> ----------------------------------------------------------
> > >> >>>>>> --
> > >> >>>>>> ---
> > >> >>>>>> ----
> > >> >>>>>> -- To unsubscribe, e-mail:
> > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > >> >>>>>> For additional commands, e-mail:
> > >> >>>>>> dev-help@cordova.apache.org
> > >> >>>
> > >> >>> -------------------------------------------------------------
> > >> >>> --
> > >> >>> ---
> > >> >>> --
> > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> > ---------------------------------------------------------------
> > >> > --
> > >> > ---
> > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> --
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > >?B
> > >KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B
> > >܈?Y??]?[ ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
Re: [Discuss] Cordova-common release
Posted by Joe Bowser <bo...@gmail.com>.
OK, how will this impact the 5.0 release of Android?
On Tue, Oct 20, 2015 at 6:07 PM, Nikhil Khandelwal <ni...@microsoft.com>
wrote:
> It got checked in earlier this morning.
>
> -Nikhil
>
> -----Original Message-----
> From: Joe Bowser [mailto:bowserj@gmail.com]
> Sent: Tuesday, October 20, 2015 2:34 PM
> To: dev <de...@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 <pa...@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" <ni...@microsoft.com>
> wrote:
> >
> > >+1 to publishing cordova-common to npm.
> > >
> > >-Nikhil
> > >
> > >-----Original Message-----
> > >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%2f
> > >> > git
> > >> > hu
> > >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti
> > >> > %40
> > >> > 06
> > >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988b
> > >> > f86
> > >> > f1
> > >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm
> > >> > %2b
> > >> > do
> > >> > 9WX4V4JfT0%3d
> > >> >
> > >> > -
> > >> > Best regards, Vladimir.
> > >> >
> > >> > -----Original Message-----
> > >> > From: Carlos Santana [mailto:csantana23@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
> > >> >> <st...@gmail.com>
> > >> wrote:
> > >> >>
> > >> >> Sounds good. Let's move forward
> > >> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
> > >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2
> > >> >> fgi
> > >> >> th
> > >> >> u
> > >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c0
> > >> >> 1%7
> > >> >> cv
> > >> >> -
> > >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e
> > >> >> 0f%
> > >> >> 7c
> > >> >> 7
> > >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP
> > >> >> 7AY
> > >> >> 4q
> > >> >> E
> > >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> > >> >>>
> > >> >>>
> > >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > >> >>> <cs...@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
> > >> >>>> %2f
> > >> >>>> g
> > >> >>>> ithu
> > >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=0
> > >> >>>> 1%7
> > >> >>>> c
> > >> >>>> 01%7
> > >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c
> > >> >>>> 5c7
> > >> >>>> 0
> > >> >>>> e0f%
> > >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubm
> > >> >>>> Vx5
> > >> >>>> 0
> > >> >>>> QKD2
> > >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>>
> > >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > >> >>>> v-segreb@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:csantana23@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-segreb@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%
> > >> >>>>>> 2fis
> > >> >>>>>> sue
> > >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segr
> > >> >>>>>> eb%
> > >> >>>>>> 40mi
> > >> >>>>>> cro
> > >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141
> > >> >>>>>> af9
> > >> >>>>>> 1ab2
> > >> >>>>>> d7c
> > >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorT
> > >> >>>>>> jwX
> > >> >>>>>> TXk%
> > >> >>>>>> 3d
> > >> >>>>>> [2]
> > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%
> > >> >>>>>> 2f%
> > >> >>>>>> 2fgi
> > >> >>>>>> thu
> > >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-commo
> > >> >>>>>> n&d
> > >> >>>>>> ata=
> > >> >>>>>> 01%
> > >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5
> > >> >>>>>> 491
> > >> >>>>>> 5f3%
> > >> >>>>>> 7c7
> > >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9
> > >> >>>>>> ASf
> > >> >>>>>> QMku
> > >> >>>>>> RV0
> > >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> > >> >>>>>>
> > >> >>>>>> Thx!
> > >> >>>>>> Sergey
> > >> >>>>>>
> > >> >>>>>> ------------------------------------------------------------
> > >> >>>>>> ---
> > >> >>>>>> ----
> > >> >>>>>> -- To unsubscribe, e-mail:
> > >> >>>>>> dev-unsubscribe@cordova.apache.org
> > >> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >>>
> > >> >>> ---------------------------------------------------------------
> > >> >>> ---
> > >> >>> --
> > >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> > -----------------------------------------------------------------
> > >> > ---
> > >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >>
> >
> > >?B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> > >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B ܈?Y??]?[
> > >ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
RE: [Discuss] Cordova-common release
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
It got checked in earlier this morning.
-Nikhil
-----Original Message-----
From: Joe Bowser [mailto:bowserj@gmail.com]
Sent: Tuesday, October 20, 2015 2:34 PM
To: dev <de...@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 <pa...@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" <ni...@microsoft.com> wrote:
>
> >+1 to publishing cordova-common to npm.
> >
> >-Nikhil
> >
> >-----Original Message-----
> >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@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%2f
> >> > git
> >> > hu
> >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti
> >> > %40
> >> > 06
> >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988b
> >> > f86
> >> > f1
> >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm
> >> > %2b
> >> > do
> >> > 9WX4V4JfT0%3d
> >> >
> >> > -
> >> > Best regards, Vladimir.
> >> >
> >> > -----Original Message-----
> >> > From: Carlos Santana [mailto:csantana23@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
> >> >> <st...@gmail.com>
> >> wrote:
> >> >>
> >> >> Sounds good. Let's move forward
> >> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
> >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2
> >> >> fgi
> >> >> th
> >> >> u
> >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c0
> >> >> 1%7
> >> >> cv
> >> >> -
> >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e
> >> >> 0f%
> >> >> 7c
> >> >> 7
> >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP
> >> >> 7AY
> >> >> 4q
> >> >> E
> >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> >> >>>
> >> >>>
> >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> >> >>> <cs...@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
> >> >>>> %2f
> >> >>>> g
> >> >>>> ithu
> >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=0
> >> >>>> 1%7
> >> >>>> c
> >> >>>> 01%7
> >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c
> >> >>>> 5c7
> >> >>>> 0
> >> >>>> e0f%
> >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubm
> >> >>>> Vx5
> >> >>>> 0
> >> >>>> QKD2
> >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> >> >>>> v-segreb@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:csantana23@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-segreb@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%
> >> >>>>>> 2fis
> >> >>>>>> sue
> >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segr
> >> >>>>>> eb%
> >> >>>>>> 40mi
> >> >>>>>> cro
> >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141
> >> >>>>>> af9
> >> >>>>>> 1ab2
> >> >>>>>> d7c
> >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorT
> >> >>>>>> jwX
> >> >>>>>> TXk%
> >> >>>>>> 3d
> >> >>>>>> [2]
> >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%
> >> >>>>>> 2f%
> >> >>>>>> 2fgi
> >> >>>>>> thu
> >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-commo
> >> >>>>>> n&d
> >> >>>>>> ata=
> >> >>>>>> 01%
> >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5
> >> >>>>>> 491
> >> >>>>>> 5f3%
> >> >>>>>> 7c7
> >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9
> >> >>>>>> ASf
> >> >>>>>> QMku
> >> >>>>>> RV0
> >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> >> >>>>>>
> >> >>>>>> Thx!
> >> >>>>>> Sergey
> >> >>>>>>
> >> >>>>>> ------------------------------------------------------------
> >> >>>>>> ---
> >> >>>>>> ----
> >> >>>>>> -- To unsubscribe, e-mail:
> >> >>>>>> dev-unsubscribe@cordova.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>>
> >> >>> ---------------------------------------------------------------
> >> >>> ---
> >> >>> --
> >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >
> >> > -----------------------------------------------------------------
> >> > ---
> >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> >?B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
> >KKCB ? ?[ X ܚX K??K[XZ[? ??] ][ X ܚX P? ܙ?ݘK \?X ?K ܙ B ܈?Y??]?[
> >ۘ[?? [X[ ? ??K[XZ[? ??] Z?[??? ܙ?ݘK \?X ?K ܙ B
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [Discuss] Cordova-common release
Posted by Joe Bowser <bo...@gmail.com>.
So, when did the PlatformAPI change land in Android?
On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N <pa...@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" <ni...@microsoft.com> wrote:
>
> >+1 to publishing cordova-common to npm.
> >
> >-Nikhil
> >
> >-----Original Message-----
> >From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@microsoft.com> wrote:
> >> >
> >> > Including cordova-common as bundled dependency should be enough in
> >> > our
> >> case. Changes to coho are submitted already [1], so we only need to
> >> update package.json for cordova-lib.
> >> >
> >> > Personally for me bundling looks like a temporary workaround before
> >> > we
> >> get all those partials of 'common' published to npm, am I right?
> >> >
> >> > [1]
> >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> >> > hu
> >> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%40
> >> > 06
> >> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86
> >> > f1
> >> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2b
> >> > do
> >> > 9WX4V4JfT0%3d
> >> >
> >> > -
> >> > Best regards, Vladimir.
> >> >
> >> > -----Original Message-----
> >> > From: Carlos Santana [mailto:csantana23@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
> >> >> <st...@gmail.com>
> >> wrote:
> >> >>
> >> >> Sounds good. Let's move forward
> >> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
> >> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2fgi
> >> >> th
> >> >> u
> >> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7
> >> >> cv
> >> >> -
> >> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> >> >> 7c
> >> >> 7
> >> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY
> >> >> 4q
> >> >> E
> >> >> CnvsbnsJ%2bvEriJvqYcU%3d
> >> >>>
> >> >>>
> >> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> >> >>> <cs...@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%2f
> >> >>>> g
> >> >>>> ithu
> >> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7
> >> >>>> c
> >> >>>> 01%7
> >> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> >> >>>> 0
> >> >>>> e0f%
> >> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx5
> >> >>>> 0
> >> >>>> QKD2
> >> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> >> >>>> v-segreb@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:csantana23@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-segreb@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%
> >> >>>>>> 2fis
> >> >>>>>> sue
> >> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
> >> >>>>>> 40mi
> >> >>>>>> cro
> >> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
> >> >>>>>> 1ab2
> >> >>>>>> d7c
> >> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
> >> >>>>>> TXk%
> >> >>>>>> 3d
> >> >>>>>> [2]
> >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
> >> >>>>>> 2fgi
> >> >>>>>> thu
> >> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
> >> >>>>>> ata=
> >> >>>>>> 01%
> >> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
> >> >>>>>> 5f3%
> >> >>>>>> 7c7
> >> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
> >> >>>>>> QMku
> >> >>>>>> RV0
> >> >>>>>> ksMKA%2fp2zpg6BNU%3d
> >> >>>>>>
> >> >>>>>> Thx!
> >> >>>>>> Sergey
> >> >>>>>>
> >> >>>>>> ---------------------------------------------------------------
> >> >>>>>> ----
> >> >>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >>>
> >> >>> ------------------------------------------------------------------
> >> >>> --
> >> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >> >
> >> > --------------------------------------------------------------------
> >> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> For additional commands, e-mail: dev-help@cordova.apache.org
> >>
> >>
>
> >?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
Re: [Discuss] Cordova-common release
Posted by Parashuram N <pa...@microsoft.com>.
+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" <ni...@microsoft.com> wrote:
>+1 to publishing cordova-common to npm.
>
>-Nikhil
>
>-----Original Message-----
>From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@microsoft.com> wrote:
>> >
>> > Including cordova-common as bundled dependency should be enough in
>> > our
>> case. Changes to coho are submitted already [1], so we only need to
>> update package.json for cordova-lib.
>> >
>> > Personally for me bundling looks like a temporary workaround before
>> > we
>> get all those partials of 'common' published to npm, am I right?
>> >
>> > [1]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
>> > hu
>> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%40
>> > 06
>> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86
>> > f1
>> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2b
>> > do
>> > 9WX4V4JfT0%3d
>> >
>> > -
>> > Best regards, Vladimir.
>> >
>> > -----Original Message-----
>> > From: Carlos Santana [mailto:csantana23@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
>> >> <st...@gmail.com>
>> wrote:
>> >>
>> >> Sounds good. Let's move forward
>> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
>> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2fgi
>> >> th
>> >> u
>> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7
>> >> cv
>> >> -
>> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
>> >> 7c
>> >> 7
>> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY
>> >> 4q
>> >> E
>> >> CnvsbnsJ%2bvEriJvqYcU%3d
>> >>>
>> >>>
>> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
>> >>> <cs...@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%2f
>> >>>> g
>> >>>> ithu
>> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7
>> >>>> c
>> >>>> 01%7
>> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
>> >>>> 0
>> >>>> e0f%
>> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx5
>> >>>> 0
>> >>>> QKD2
>> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
>> >>>> v-segreb@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:csantana23@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-segreb@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%
>> >>>>>> 2fis
>> >>>>>> sue
>> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
>> >>>>>> 40mi
>> >>>>>> cro
>> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
>> >>>>>> 1ab2
>> >>>>>> d7c
>> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
>> >>>>>> TXk%
>> >>>>>> 3d
>> >>>>>> [2]
>> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
>> >>>>>> 2fgi
>> >>>>>> thu
>> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
>> >>>>>> ata=
>> >>>>>> 01%
>> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
>> >>>>>> 5f3%
>> >>>>>> 7c7
>> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
>> >>>>>> QMku
>> >>>>>> RV0
>> >>>>>> ksMKA%2fp2zpg6BNU%3d
>> >>>>>>
>> >>>>>> Thx!
>> >>>>>> Sergey
>> >>>>>>
>> >>>>>> ---------------------------------------------------------------
>> >>>>>> ----
>> >>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >>>
>> >>> ------------------------------------------------------------------
>> >>> --
>> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> >>> For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> > --------------------------------------------------------------------
>> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> For additional commands, e-mail: dev-help@cordova.apache.org
>>
>>
>?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?�ܙ?ݘK�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???�ܙ?ݘK�\?X�?K�ܙ�B
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: [Discuss] Cordova-common release
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
+1 to publishing cordova-common to npm.
-Nikhil
-----Original Message-----
From: Steven Gill [mailto:stevengill97@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-vlkoti@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:csantana23@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-vlkoti@microsoft.com> wrote:
> >
> > Including cordova-common as bundled dependency should be enough in
> > our
> case. Changes to coho are submitted already [1], so we only need to
> update package.json for cordova-lib.
> >
> > Personally for me bundling looks like a temporary workaround before
> > we
> get all those partials of 'common' published to npm, am I right?
> >
> > [1]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit
> > hu
> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%40
> > 06
> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86
> > f1
> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2b
> > do
> > 9WX4V4JfT0%3d
> >
> > -
> > Best regards, Vladimir.
> >
> > -----Original Message-----
> > From: Carlos Santana [mailto:csantana23@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
> >> <st...@gmail.com>
> wrote:
> >>
> >> Sounds good. Let's move forward
> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2fgi
> >> th
> >> u
> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7
> >> cv
> >> -
> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> >> 7c
> >> 7
> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY
> >> 4q
> >> E
> >> CnvsbnsJ%2bvEriJvqYcU%3d
> >>>
> >>>
> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> >>> <cs...@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%2f
> >>>> g
> >>>> ithu
> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7
> >>>> c
> >>>> 01%7
> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c7
> >>>> 0
> >>>> e0f%
> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx5
> >>>> 0
> >>>> QKD2
> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> >>>> v-segreb@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:csantana23@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-segreb@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%
> >>>>>> 2fis
> >>>>>> sue
> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
> >>>>>> 40mi
> >>>>>> cro
> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
> >>>>>> 1ab2
> >>>>>> d7c
> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
> >>>>>> TXk%
> >>>>>> 3d
> >>>>>> [2]
> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
> >>>>>> 2fgi
> >>>>>> thu
> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
> >>>>>> ata=
> >>>>>> 01%
> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
> >>>>>> 5f3%
> >>>>>> 7c7
> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
> >>>>>> QMku
> >>>>>> RV0
> >>>>>> ksMKA%2fp2zpg6BNU%3d
> >>>>>>
> >>>>>> Thx!
> >>>>>> Sergey
> >>>>>>
> >>>>>> ---------------------------------------------------------------
> >>>>>> ----
> >>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>
> >>> ------------------------------------------------------------------
> >>> --
> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: [Discuss] Cordova-common release
Posted by Steven Gill <st...@gmail.com>.
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-vlkoti@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:csantana23@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-vlkoti@microsoft.com> wrote:
> >
> > Including cordova-common as bundled dependency should be enough in our
> case. Changes to coho are submitted already [1], so we only need to update
> package.json for cordova-lib.
> >
> > Personally for me bundling looks like a temporary workaround before we
> get all those partials of 'common' published to npm, am I right?
> >
> > [1]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%4006
> > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1
> > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2bdo
> > 9WX4V4JfT0%3d
> >
> > -
> > Best regards, Vladimir.
> >
> > -----Original Message-----
> > From: Carlos Santana [mailto:csantana23@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 <st...@gmail.com>
> wrote:
> >>
> >> Sounds good. Let's move forward
> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
> >> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2fgith
> >> u
> >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv
> >> -
> >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c
> >> 7
> >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4q
> >> E
> >> CnvsbnsJ%2bvEriJvqYcU%3d
> >>>
> >>>
> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> >>> <cs...@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%2fg
> >>>> ithu
> >>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c
> >>>> 01%7
> >>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70
> >>>> e0f%
> >>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50
> >>>> QKD2
> >>>> CLfoxrVgj%2ftTxTrMJ8%3d
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> >>>> v-segreb@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:csantana23@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-segreb@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%
> >>>>>> 2fis
> >>>>>> sue
> >>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
> >>>>>> 40mi
> >>>>>> cro
> >>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
> >>>>>> 1ab2
> >>>>>> d7c
> >>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
> >>>>>> TXk%
> >>>>>> 3d
> >>>>>> [2]
> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
> >>>>>> 2fgi
> >>>>>> thu
> >>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
> >>>>>> ata=
> >>>>>> 01%
> >>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
> >>>>>> 5f3%
> >>>>>> 7c7
> >>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
> >>>>>> QMku
> >>>>>> RV0
> >>>>>> ksMKA%2fp2zpg6BNU%3d
> >>>>>>
> >>>>>> Thx!
> >>>>>> Sergey
> >>>>>>
> >>>>>> ---------------------------------------------------------------
> >>>>>> ----
> >>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
> >>>
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >>> For additional commands, e-mail: dev-help@cordova.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
RE: [Discuss] Cordova-common release
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
> 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:csantana23@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-...@microsoft.com> wrote:
>
> Including cordova-common as bundled dependency should be enough in our case. Changes to coho are submitted already [1], so we only need to update package.json for cordova-lib.
>
> Personally for me bundling looks like a temporary workaround before we get all those partials of 'common' published to npm, am I right?
>
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%4006
> 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1
> 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2bdo
> 9WX4V4JfT0%3d
>
> -
> Best regards, Vladimir.
>
> -----Original Message-----
> From: Carlos Santana [mailto:csantana23@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 <st...@gmail.com> wrote:
>>
>> Sounds good. Let's move forward
>> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal"
>> <ni...@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-segreb@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-vlkoti@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:csantana23@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%2fgith
>> u
>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv
>> -
>> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c
>> 7
>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4q
>> E
>> CnvsbnsJ%2bvEriJvqYcU%3d
>>>
>>>
>>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
>>> <cs...@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%2fg
>>>> ithu
>>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c
>>>> 01%7
>>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70
>>>> e0f%
>>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50
>>>> QKD2
>>>> CLfoxrVgj%2ftTxTrMJ8%3d
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
>>>> v-segreb@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:csantana23@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-segreb@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%
>>>>>> 2fis
>>>>>> sue
>>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
>>>>>> 40mi
>>>>>> cro
>>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
>>>>>> 1ab2
>>>>>> d7c
>>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
>>>>>> TXk%
>>>>>> 3d
>>>>>> [2]
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
>>>>>> 2fgi
>>>>>> thu
>>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
>>>>>> ata=
>>>>>> 01%
>>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
>>>>>> 5f3%
>>>>>> 7c7
>>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
>>>>>> QMku
>>>>>> RV0
>>>>>> ksMKA%2fp2zpg6BNU%3d
>>>>>>
>>>>>> Thx!
>>>>>> Sergey
>>>>>>
>>>>>> ---------------------------------------------------------------
>>>>>> ----
>>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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-...@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:csantana23@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 <st...@gmail.com> wrote:
>>
>> Sounds good. Let's move forward
>> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <ni...@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-segreb@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-vlkoti@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:csantana23@gmail.com]
>>> Sent: Friday, September 25, 2015 7:33 PM
>>> To: dev@cordova.apache.org
>>> Subject: Re: [Discuss] Cordova-common release
>>>
>>> Sorry a typo
>>> to use "bundleDependencies" you will have a node_modules/ directory
>>> directly under "common/node_modules/cordova-error/"
>>>
>>> and the the small modules (i.e. cordoba-util, cordova-plugin-info,
>>> etc..) will be located there.
>>>
>>> then have explicit ignores for the dependencies you don't want to be
>>> source control like npm [2]
>>>
>>> [2]:
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-
>> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c7
>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qE
>> CnvsbnsJ%2bvEriJvqYcU%3d
>>>
>>>
>>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
>>> <cs...@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%2fg
>>>> ithu
>>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c
>>>> 01%7
>>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70
>>>> e0f%
>>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50
>>>> QKD2
>>>> CLfoxrVgj%2ftTxTrMJ8%3d
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
>>>> v-segreb@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:csantana23@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-segreb@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%
>>>>>> 2fis
>>>>>> sue
>>>>>> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
>>>>>> 40mi
>>>>>> cro
>>>>>> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
>>>>>> 1ab2
>>>>>> d7c
>>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
>>>>>> TXk%
>>>>>> 3d
>>>>>> [2]
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
>>>>>> 2fgi
>>>>>> thu
>>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
>>>>>> ata=
>>>>>> 01%
>>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
>>>>>> 5f3%
>>>>>> 7c7
>>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
>>>>>> QMku
>>>>>> RV0
>>>>>> ksMKA%2fp2zpg6BNU%3d
>>>>>>
>>>>>> Thx!
>>>>>> Sergey
>>>>>>
>>>>>> ---------------------------------------------------------------
>>>>>> ----
>>>>>> -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>>>>> For additional commands, e-mail: dev-help@cordova.apache.org
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: [Discuss] Cordova-common release
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
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:csantana23@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 <st...@gmail.com> wrote:
> Sounds good. Let's move forward
> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <ni...@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-segreb@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-vlkoti@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:csantana23@gmail.com]
> > Sent: Friday, September 25, 2015 7:33 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Discuss] Cordova-common release
> >
> > Sorry a typo
> > to use "bundleDependencies" you will have a node_modules/ directory
> > directly under "common/node_modules/cordova-error/"
> >
> > and the the small modules (i.e. cordoba-util, cordova-plugin-info,
> > etc..) will be located there.
> >
> > then have explicit ignores for the dependencies you don't want to be
> > source control like npm [2]
> >
> > [2]:
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-
> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c7
> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qE
> CnvsbnsJ%2bvEriJvqYcU%3d
> >
> >
> > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana
> > <cs...@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%2fg
> > > ithu
> > > b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c
> > > 01%7
> > > cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70
> > > e0f%
> > > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50
> > > QKD2
> > > CLfoxrVgj%2ftTxTrMJ8%3d
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > > v-segreb@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:csantana23@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-segreb@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%
> > >> > 2fis
> > >> > sue
> > >> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%
> > >> > 40mi
> > >> > cro
> > >> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af9
> > >> > 1ab2
> > >> > d7c
> > >> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
> > >> > TXk%
> > >> > 3d
> > >> > [2]
> > >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
> > >> > 2fgi
> > >> > thu
> > >> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
> > >> > ata=
> > >> > 01%
> > >> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
> > >> > 5f3%
> > >> > 7c7
> > >> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
> > >> > QMku
> > >> > RV0
> > >> > ksMKA%2fp2zpg6BNU%3d
> > >> >
> > >> > Thx!
> > >> > Sergey
> > >> >
> > >> > ---------------------------------------------------------------
> > >> > ----
> > >> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> >
> > >>
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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 <st...@gmail.com> wrote:
> Sounds good. Let's move forward
> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <ni...@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-segreb@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-vlkoti@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:csantana23@gmail.com]
> > Sent: Friday, September 25, 2015 7:33 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Discuss] Cordova-common release
> >
> > Sorry a typo
> > to use "bundleDependencies" you will have a node_modules/ directory
> > directly under "common/node_modules/cordova-error/"
> >
> > and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..)
> > will be located there.
> >
> > then have explicit ignores for the dependencies you don't want to be
> > source control like npm [2]
> >
> > [2]:
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
> >
> >
> > On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <cs...@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&data=01%7c01%7
> > > cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> > > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50QKD2
> > > CLfoxrVgj%2ftTxTrMJ8%3d
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > > v-segreb@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:csantana23@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-segreb@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%2fis
> > >> > sue
> > >> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40mi
> > >> > cro
> > >> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2
> > >> > d7c
> > >> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%
> > >> > 3d
> > >> > [2]
> > >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgi
> > >> > thu
> > >> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=
> > >> > 01%
> > >> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%
> > >> > 7c7
> > >> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMku
> > >> > RV0
> > >> > ksMKA%2fp2zpg6BNU%3d
> > >> >
> > >> > Thx!
> > >> > Sergey
> > >> >
> > >> > -------------------------------------------------------------------
> > >> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> > For additional commands, e-mail: dev-help@cordova.apache.org
> > >> >
> > >> >
> > >>
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
>
RE: [Discuss] Cordova-common release
Posted by Steven Gill <st...@gmail.com>.
Sounds good. Let's move forward
On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <ni...@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-segreb@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-vlkoti@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:csantana23@gmail.com]
> Sent: Friday, September 25, 2015 7:33 PM
> To: dev@cordova.apache.org
> Subject: Re: [Discuss] Cordova-common release
>
> Sorry a typo
> to use "bundleDependencies" you will have a node_modules/ directory
> directly under "common/node_modules/cordova-error/"
>
> and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..)
> will be located there.
>
> then have explicit ignores for the dependencies you don't want to be
> source control like npm [2]
>
> [2]:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
>
>
> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <cs...@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&data=01%7c01%7
> > cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> > 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50QKD2
> > CLfoxrVgj%2ftTxTrMJ8%3d
> >
> >
> >
> >
> >
> > On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> > v-segreb@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:csantana23@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-segreb@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%2fis
> >> > sue
> >> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40mi
> >> > cro
> >> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2
> >> > d7c
> >> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%
> >> > 3d
> >> > [2]
> >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgi
> >> > thu
> >> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=
> >> > 01%
> >> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%
> >> > 7c7
> >> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMku
> >> > RV0
> >> > ksMKA%2fp2zpg6BNU%3d
> >> >
> >> > Thx!
> >> > Sergey
> >> >
> >> > -------------------------------------------------------------------
> >> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> >> > For additional commands, e-mail: dev-help@cordova.apache.org
> >> >
> >> >
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: [Discuss] Cordova-common release
Posted by Nikhil Khandelwal <ni...@microsoft.com>.
+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-segreb@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-vlkoti@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:csantana23@gmail.com]
Sent: Friday, September 25, 2015 7:33 PM
To: dev@cordova.apache.org
Subject: Re: [Discuss] Cordova-common release
Sorry a typo
to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/"
and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there.
then have explicit ignores for the dependencies you don't want to be source control like npm [2]
[2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <cs...@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&data=01%7c01%7
> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50QKD2
> CLfoxrVgj%2ftTxTrMJ8%3d
>
>
>
>
>
> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> v-segreb@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:csantana23@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-segreb@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%2fis
>> > sue
>> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40mi
>> > cro
>> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2
>> > d7c
>> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%
>> > 3d
>> > [2]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgi
>> > thu
>> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=
>> > 01%
>> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%
>> > 7c7
>> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMku
>> > RV0
>> > ksMKA%2fp2zpg6BNU%3d
>> >
>> > Thx!
>> > Sergey
>> >
>> > -------------------------------------------------------------------
>> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: [Discuss] Cordova-common release
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
+1
-----Original Message-----
From: Vladimir Kotikov (Akvelon) [mailto:v-vlkoti@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:csantana23@gmail.com]
Sent: Friday, September 25, 2015 7:33 PM
To: dev@cordova.apache.org
Subject: Re: [Discuss] Cordova-common release
Sorry a typo
to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/"
and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there.
then have explicit ignores for the dependencies you don't want to be source control like npm [2]
[2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <cs...@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&data=01%7c01%7
> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50QKD2
> CLfoxrVgj%2ftTxTrMJ8%3d
>
>
>
>
>
> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> v-segreb@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:csantana23@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-segreb@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%2fis
>> > sue
>> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40mi
>> > cro
>> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2
>> > d7c
>> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%
>> > 3d
>> > [2]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgi
>> > thu
>> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=
>> > 01%
>> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%
>> > 7c7
>> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMku
>> > RV0
>> > ksMKA%2fp2zpg6BNU%3d
>> >
>> > Thx!
>> > Sergey
>> >
>> > -------------------------------------------------------------------
>> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: [Discuss] Cordova-common release
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
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:csantana23@gmail.com]
Sent: Friday, September 25, 2015 7:33 PM
To: dev@cordova.apache.org
Subject: Re: [Discuss] Cordova-common release
Sorry a typo
to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/"
and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located there.
then have explicit ignores for the dependencies you don't want to be source control like npm [2]
[2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d
On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <cs...@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&data=01%7c01%7
> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50QKD2
> CLfoxrVgj%2ftTxTrMJ8%3d
>
>
>
>
>
> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) <
> v-segreb@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:csantana23@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-segreb@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%2fis
>> > sue
>> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40mi
>> > cro
>> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2
>> > d7c
>> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%
>> > 3d
>> > [2]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgi
>> > thu
>> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=
>> > 01%
>> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%
>> > 7c7
>> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMku
>> > RV0
>> > ksMKA%2fp2zpg6BNU%3d
>> >
>> > Thx!
>> > Sergey
>> >
>> > -------------------------------------------------------------------
>> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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 <cs...@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-segreb@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:csantana23@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-segreb@microsoft.com> wrote:
>>
>> > Hi guys - we've decided to combine shared logic as cordova-common
>> > module and publish it separately (read [1] for more details).
>> > Corresponding change has landed to master[2] on last week so I'm
>> > wondering if we should release this module and then update LIB to rely
>> on it (similar to cordova-serve).
>> > So guys it will be great if we can review it one more time (including
>> > the name - do we all agree to use cordova-common??) and then do
>> > release - I'll be able to help w/ merging the recent changes added to
>> > LIB before doing release.
>> >
>> > [1]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
>> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro
>> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
>> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d
>> > [2]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
>> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01%
>> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
>> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0
>> > ksMKA%2fp2zpg6BNU%3d
>> >
>> > Thx!
>> > Sergey
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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-segreb@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:csantana23@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-segreb@microsoft.com> wrote:
>
> > Hi guys - we've decided to combine shared logic as cordova-common
> > module and publish it separately (read [1] for more details).
> > Corresponding change has landed to master[2] on last week so I'm
> > wondering if we should release this module and then update LIB to rely
> on it (similar to cordova-serve).
> > So guys it will be great if we can review it one more time (including
> > the name - do we all agree to use cordova-common??) and then do
> > release - I'll be able to help w/ merging the recent changes added to
> > LIB before doing release.
> >
> > [1]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro
> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d
> > [2]
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01%
> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0
> > ksMKA%2fp2zpg6BNU%3d
> >
> > Thx!
> > Sergey
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>
RE: [Discuss] Cordova-common release
Posted by "Sergey Grebnov (Akvelon)" <v-...@microsoft.com>.
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:csantana23@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-segreb@microsoft.com> wrote:
> Hi guys - we've decided to combine shared logic as cordova-common
> module and publish it separately (read [1] for more details).
> Corresponding change has landed to master[2] on last week so I'm
> wondering if we should release this module and then update LIB to rely on it (similar to cordova-serve).
> So guys it will be great if we can review it one more time (including
> the name - do we all agree to use cordova-common??) and then do
> release - I'll be able to help w/ merging the recent changes added to
> LIB before doing release.
>
> [1]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro
> soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c
> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d
> [2]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01%
> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7
> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0
> ksMKA%2fp2zpg6BNU%3d
>
> Thx!
> Sergey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: [Discuss] Cordova-common release
Posted by Carlos Santana <cs...@gmail.com>.
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-segreb@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-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>