It got checked in earlier this morning. -Nikhil
-----Original Message----- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Tuesday, October 20, 2015 2:34 PM To: dev <dev@cordova.apache.org> Subject: Re: [Discuss] Cordova-common release So, when did the PlatformAPI change land in Android? On Tue, Oct 20, 2015 at 2:32 PM, Parashuram N <panar...@microsoft.com> wrote: > +1 - YES please. Requiring cordoba-common for my > react-native-cordova-plugin adapter was a nightmare !! > > > > > On 10/20/15, 2:23 PM, "Nikhil Khandelwal" <nikhi...@microsoft.com> wrote: > > >+1 to publishing cordova-common to npm. > > > >-Nikhil > > > >-----Original Message----- > >From: Steven Gill [mailto:stevengil...@gmail.com] > >Sent: Tuesday, October 20, 2015 2:20 PM > >To: dev@cordova.apache.org > >Subject: Re: [Discuss] Cordova-common release > > > >I want to revisit this. > > > >So cordova-android has a dependency now on cordova-common. It is a > bundledDependency so when we generate a tar to release > cordova-android, it will be included. It will also be in the > cordova-android package that gets downloaded with cordova platform add. > > > >This is fine for released work, but more annoying for development. I > >need > to npm link cordova-common into cordova-android (and soon every > platform which implements common platformAPI). We could check in > cordova-common into cordova-android but that isn't a great solution either. > > > >I agree that we should be going towards smaller modules and not > >having a > case of cordovaLib1, cordovaLib2, etc. I think this is still going to > be a work in progress and will take some time. > > > >For the interim, I recommend we publish cordova-common. Of course, > continue to add it as a bundledDependency so users don't need to npm > install it with released packages. > > > >On Wed, Sep 30, 2015 at 7:24 AM, Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > > > >> > I still do not understand what are you trying to solve by having > >> > all > >> that content published as big blob. > >> Code deduplication is the main reason. All the things from > >> 'cordova-common' will be used by platforms intensively, so we need > >> to share this code and keep it separately from LIB to share easily. > >> Publishing is basically doesn't required for this, and bundling > >> 'cordova-common' into LIB is enough for this purpose. > >> > >> Another reason was that third-party tool might want to use some of > >> this functionality (like your example with ConfigParser), so we > >> need to have this package on NPM to allow them to get it. For this > >> case I now do agree with you that separate packages for > >> ConfigParser, PluginInfo and other stuff looks better than putting > >> it into one big > package. > >> > >> - > >> Best regards, Vladimir > >> > >> > >> -----Original Message----- > >> From: Carlos Santana [mailto:csantan...@gmail.com] > >> Sent: Wednesday, September 30, 2015 2:07 PM > >> To: dev@cordova.apache.org > >> Subject: Re: [Discuss] Cordova-common release > >> > >> Yes temporary, maybe we can discuss some more in F2F > >> > >> I still do not understand what are you trying to solve by having > >> all that content published as big blob. > >> > >> If the packages are only for Cordova components to depend on then > >> we control the release and we can include them easily. > >> > >> If the code is to be share by third party or anyone out there then > >> it make sense to put in npm. > >> > >> One concrete example is cordova-configparser, Our IBM tool is using > >> it in our own models code so today we taking a copy, if it's > >> available thru npm then we can stated as a dependency and manage it > >> as a npm package vs a loosely node module js file > >> > >> Maybe not all classes need to be converted to npm packages maybe it > >> can be some cordova-configparser cordova-utils cordova-helper > >> > >> Also do some refactoring and dependency cleaning, I saw a node > >> module dependeding on underscore and the file only had one simple > >> call to > >> _.find() > >> > >> We were going to use that module, but then decided not to since it > >> depended on underscore for a simple thing, this creates legal > >> clearance work and more dependencies we need to include in our > >> product making our download larger. > >> > >> And yes, yes we bundle all our dependencies when we go into production. > >> > >> - Carlos > >> Sent from my iPhone > >> > >> > On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) < > >> v-vlk...@microsoft.com> wrote: > >> > > >> > Including cordova-common as bundled dependency should be enough > >> > in our > >> case. Changes to coho are submitted already [1], so we only need to > >> update package.json for cordova-lib. > >> > > >> > Personally for me bundling looks like a temporary workaround > >> > before we > >> get all those partials of 'common' published to npm, am I right? > >> > > >> > [1] > >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%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:csantan...@gmail.com] > >> > Sent: Tuesday, September 29, 2015 9:15 PM > >> > To: dev@cordova.apache.org > >> > Subject: Re: [Discuss] Cordova-common release > >> > > >> > Do we need to absolutely publish this to npm? > >> > > >> > Can we just include the dependency in the platform as a bundle > >> dependency? > >> > > >> > We just need to update coho to npm install/link the > >> > cordoba-common package when doing a release of what ever component need > >> > it? (i.e. > >> > cordova-android) > >> > > >> > Will this get you what you want? Why does it absolutely need to > >> > be in > >> npm registry? > >> > > >> > I really don't think will be a good idea to publish two npm > >> > packages > >> "cordova-lib" and "cordova-common" > >> > > >> > Sorry if I'm being a pain in the ass, maybe I'm something obvious > >> > here > >> > > >> > > >> >> On Tue, Sep 29, 2015 at 1:34 PM Steven Gill > >> >> <stevengil...@gmail.com> > >> wrote: > >> >> > >> >> Sounds good. Let's move forward > >> >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" > >> >> <nikhi...@microsoft.com> > >> >> wrote: > >> >> > >> >>> +1. I understand the value of Carlos' proposal, but in the > >> >>> +spirit of > >> >>> moving forward with this which is fairly complicated refactor > >> >>> involving multiple releases and repos, I would like us to make > >> >>> progress on this > >> >> soon > >> >>> and not add significant scope to this effort. > >> >>> > >> >>> > >> >>> -Nikhil > >> >>> > >> >>> -----Original Message----- > >> >>> From: Sergey Grebnov (Akvelon) [mailto:v-seg...@microsoft.com] > >> >>> Sent: Tuesday, September 29, 2015 1:34 AM > >> >>> To: dev@cordova.apache.org > >> >>> Subject: RE: [Discuss] Cordova-common release > >> >>> > >> >>> +1 > >> >>> > >> >>> -----Original Message----- > >> >>> From: Vladimir Kotikov (Akvelon) > >> >>> [mailto:v-vlk...@microsoft.com] > >> >>> Sent: Tuesday, September 29, 2015 11:27 AM > >> >>> To: dev@cordova.apache.org > >> >>> Subject: RE: [Discuss] Cordova-common release > >> >>> > >> >>> Agree with you, guys. > >> >>> > >> >>> Unfortunately, the underlying modules in `cordova-common` are > >> >>> not really atomic, since they depending on each other. For > >> >>> example ConfigParser requires `xmlHelpers`, `events` and > >> >>> `CordovaError` as a > >> dependencies. > >> >>> Reworking them to be truly separated might be sort of > >> >>> problematic, especially in context of message logging (as they > >> >>> use shared event > >> >> emitter > >> >>> to log output to console). > >> >>> > >> >>> So I still propose is to release `common` module as-is and then > >> >>> gradually move inner modules out to separate packages. > >> >>> > >> >>> - > >> >>> Best regards, Vladimir. > >> >>> > >> >>> -----Original Message----- > >> >>> From: Carlos Santana [mailto:csantan...@gmail.com] > >> >>> Sent: Friday, September 25, 2015 7:33 PM > >> >>> To: dev@cordova.apache.org > >> >>> Subject: Re: [Discuss] Cordova-common release > >> >>> > >> >>> Sorry a typo > >> >>> to use "bundleDependencies" you will have a node_modules/ > >> >>> directory directly under "common/node_modules/cordova-error/" > >> >>> > >> >>> and the the small modules (i.e. cordoba-util, > >> >>> cordova-plugin-info, > >> >>> etc..) will be located there. > >> >>> > >> >>> then have explicit ignores for the dependencies you don't want > >> >>> to be source control like npm [2] > >> >>> > >> >>> [2]: > >> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%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 > >> >>> <csantan...@gmail.com> > >> >>> wrote: > >> >>> > >> >>>> Yes after reviewing the changes, I understood the purpose of > >> >>>> the code that you seperated to avoid duplicate code between > >> >>>> the other top level modules (i.e. platforms, lib, cli) > >> >>>> > >> >>>> I still think small modules is the way to go. > >> >>>> > >> >>>> Don't let process, bureaucracy, and ceremony hamper the > >> >>>> engineering process and the consumer UX using this modules. > >> >>>> (yeah that came out from the mouth of an IBMer ;-p) > >> >>>> > >> >>>> Yes, I'm not blind, I understand the voting, the releasing, > >> >>>> the packaging the publish steps > >> >>>> > >> >>>> The way I look at it no matter what you do you are not going > >> >>>> to make it easier by having one "common" package. > >> >>>> > >> >>>> Let's say you just need to update a file to fix a bug from > >> >>>> Error, well you need to test, vote, release, "common" > >> >>>> Next you want to fix a bug in configparser, guess what you > >> >>>> need to tests, vote, release "common" again But if only config > >> >>>> parser changed all the rest of the code in "common" > >> >>>> needs to be tested and release, and consumer will need to pick > >> >>>> a new common for only a small bug fix in a portion of "common" > >> >>>> > >> >>>> Basically that's what we have today, the way I see it you are > >> >>>> just creating two libs "lib" and "lib2" > >> >>>> > >> >>>> With large number of small modules, lets say we create 8 now, > >> >>>> maybe only 2 change most of the time, and the other 5 are so > >> >>>> basic and small that they never change and stay at version > >> >>>> 1.0.0 > for long time. > >> >>>> > >> >>>> I think for this small modules, I don't think we have to do > >> >>>> the blog post, twitter things, those I will continue to have > >> >>>> for the large components (cli, platforms, plugins) > >> >>>> > >> >>>> Also the side effect I would like to see, is clean APIs edges, > >> >>>> each small module provides an API, it contain tests to that > >> >>>> API, and lib contain integration tests as a whole. > >> >>>> > >> >>>> Maybe the compromise for now, to move forward let's break the > >> >>>> functions into "npm packages" inside this "common" where each > >> >>>> sub directory inside common is a npm package with a single > >> >>>> entry point > >> >>>> (index.js) and common package.json have them as > >> >>>> "bundleDependencies", similar way as npm does [1] > >> >>>> > >> >>>> the transition will be for consumers for their dependencies > >> >>>> and the way they consume the API > >> >>>> dependencies: { > >> >>>> cordova-common: "1.0.0" > >> >>>> } > >> >>>> cordova-common only expose one index.js with the APIs to the > >> >>>> other modules > >> >>>> > >> >>>> var cdvUtil = require("cordova-common").cordova-util > >> >>>> cdvPluginInfo = > >> require("cordova-common").cordova-plugin-info, > >> >>>> cdvError = > require("cordova-common").cordova-error, > >> >>>> cdvConfigParser = > require("cordova-common").cordova-config-parser, > >> >>>> cdvConfigChanges = > >> >>>> require("cordova-common").rcordova-config-changes); > >> >>>> > >> >>>> then it can be easier transition if we want to change later, > >> >>>> nothing much on our part since we already have the npm > >> >>>> packages implemented it's a matter if we want to make them > >> >>>> available on npm or > >> not. > >> >>>> > >> >>>> [1]: > >> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f > >> >>>> %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-seg...@microsoft.com> wrote: > >> >>>> > >> >>>>> I tend to agree w/ Carlos here, but from practical side it > >> >>>>> might be very hard to maintain and release such a granular > >> >>>>> modules, for example, > >> >>>>> - cordova-error has been updated ->Vote -> update > >> >>>>> cordova-config-parser > >> >>>>> + Vote-> update + Vote other depended modules > >> >>>>> - now we want to add some new feature: modules are very > >> >>>>> granular so we should introduce a new module > >> >>>>> > >> >>>>> But I totally love and support Carlos idea regarding grouping > >> >>>>> meaningful/independent logic in modules, this is how software > >> >>>>> must be designed. > >> >>>>> > >> >>>>> I personally think about this new module as some sort of core > >> >>>>> Cordova functionality and high level classes which could be > >> >>>>> used by cordova-lib/cli and platforms -unified CordovaError, > >> >>>>> events (output tracing, etc), working with config file, > >> >>>>> superspawn, etc > >> >>>>> > >> >>>>> Thx! > >> >>>>> Sergey > >> >>>>> -----Original Message----- > >> >>>>> From: Carlos Santana [mailto:csantan...@gmail.com] > >> >>>>> Sent: Thursday, September 24, 2015 6:31 PM > >> >>>>> To: dev@cordova.apache.org > >> >>>>> Subject: Re: [Discuss] Cordova-common release > >> >>>>> > >> >>>>> Sorry if I take my inner purist theoretical developer out for > >> >>>>> a minute :-) > >> >>>>> > >> >>>>> The point of having a "node module" it should be explicit and > >> >>>>> small, meaning that should be easy to name in a way that > >> >>>>> describes what it is or do. > >> >>>>> > >> >>>>> Take into account that "node module" is not the same as a > >> >>>>> "npm > >> >> package" > >> >>>>> > >> >>>>> Having 2 npm packages on the npm registry "cordova-common" > >> >>>>> and "cordova-lib" to the simple eye would look like duplicate > >> >>>>> packages, and then will need to answer multiple times "What > >> >>>>> is the difference between lib and common?" > >> >>>>> > >> >>>>> Why not have more smaller explicit npm packages instead? > >> >>>>> > >> >>>>> cordova-util > >> >>>>> cordova-plugin-info > >> >>>>> cordova-error > >> >>>>> cordova-config-parser > >> >>>>> cordova-config-changes > >> >>>>> > >> >>>>> each one with a index.js exposing APIs > >> >>>>> > >> >>>>> Then the programing model becomes something like this: > >> >>>>> var cdvUtil = require('cordova-util'), > >> >>>>> cdvPluginInfo = require('cordova-plugin-info'), > >> >>>>> cdvError = require('cordova-error'), > >> >>>>> cdvConfigParser = require('cordova-config-parser'), > >> >>>>> cdvConfigChanges = require('cordova-config-changes'); > >> >>>>> > >> >>>>> > >> >>>>> On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon) < > >> >>>>> v-seg...@microsoft.com> wrote: > >> >>>>> > >> >>>>>> Hi guys - we've decided to combine shared logic as > >> >>>>>> cordova-common module and publish it separately (read [1] > >> >>>>>> for > more details). > >> >>>>>> Corresponding change has landed to master[2] on last week so > >> >>>>>> I'm wondering if we should release this module and then > >> >>>>>> update LIB to rely > >> >>>>> on it (similar to cordova-serve). > >> >>>>>> So guys it will be great if we can review it one more time > >> >>>>>> (including the name - do we all agree to use > >> >>>>>> cordova-common??) and then do release - I'll be able to help > >> >>>>>> w/ merging the recent changes added to LIB before doing release. > >> >>>>>> > >> >>>>>> [1] > >> >>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a% > >> >>>>>> 2f% > >> >>>>>> 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-unsubscr...@cordova.apache.org > >> >>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org > >> >>> > >> >>> --------------------------------------------------------------- > >> >>> --- > >> >>> -- > >> >>> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> >>> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > > >> > ----------------------------------------------------------------- > >> > --- > >> > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> > For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > >?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-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
