I like the clear distinction of plugman workflow vs cordova workflow, so I wouldn't want to drop the separation. If this goes well, the contents of plugman (and cordova) will be argument parsing, help/usage messages, and forwarding into cordova-lib, so they will not need updating often unless the interface changes.
I do like to proposal to add plugin publishing functionality to cordova-cli, which we can easily do once we have a common cordova-lib which both cli call into. Lets leave that for a follow-on task after the restructuring (filed: CB-6447). -Michal On Tue, Apr 15, 2014 at 9:36 AM, Andrew Grieve <agri...@chromium.org> wrote: > I think everyone is on board with the idea that modules should be used to > enable sharing code, and for code organization. > > Two problems that are happening in practice: > - Multiple pull requests (plugman and CLI) to make a change > - Code duplication between the repositories > > Both of these are solved by moving all common code into the same git > repository. > > I think whether to make additional npm packages should happen as a > follow-up, and as concrete proposals (e.g. Let's publish CordovaError into > an npm package) > > It's a bit weird that a lot of cordova's CLI is in a module called > "cordova", but you need to install "plugman" to publish to the registry. > > Analogy: there's not an "npm-cli" separate from "npm-publisher". > > How about folding the functionality of plugman into cordova? > - "cordova publish" > - "cordova owner add" > - "cordova plugin add --platform > <ios|amazon-fireos|android|blackberry10|wp7|wp8> --project <directory> > --plugin <name|url|path> [--plugins_dir <directory>] [--www <directory>] > [--variable <name>=<value> [--variable <name>=<value> ...]] > > This would: > - Only one tool for devs to install (aptly named "cordova") > - "cordova --help" as one entry-point to what's available > - Simply release process > - Fewer release steps > - Single set of release notes (no more having to duplicate fixes to > plugman in CLI's release notes) > > For users that are accustomed to using plugman directly, we could make > plugman depend on CLI to have it continue working. > > On Mon, Apr 14, 2014 at 12:16 PM, Brian LeRoux <b...@brian.io> wrote: > > > If we manage to get down to 1 module === 1 function then its doubtful > we'd > > have much advantage to the atomic commits thing. I'm cool w/ starting w/ > > one repo and seeing where it leads. Sort of a graduation step thing. > > > > > > On Mon, Apr 14, 2014 at 12:02 PM, Michal Mocny <mmo...@chromium.org> > > wrote: > > > > > Alright then, lets do 3+ npm packages: cordova (cli only), plugman (cli > > > only), and cordova-lib (or something similarly named, TBD, > suggestions?). > > > As cordova-lib refactors to have some useful self-contained utils, we > > will > > > move those to dedicated npm modules published separately. > > > > > > However, we are currently debating the use of a single vs multiple git > > > repos to hold the modules. > > > > > > The advantages of single repo: > > > - Easier to create atomic commits to multiple npm modules (there are > > often > > > multi-part changes), which is especially true for external Pull > Requests. > > > - More likely that we will be willing to move utils out to dedicated > npm > > > modules if there is no additional repo/release management overhead. > > > > > > The advantages of multiple repos: > > > - Easier to isolate github issues (though we don't really use these), > and > > > Pull Requests. Note: does not affect git logs, which are easy to > filter > > > based on subdirectory. > > > - We already have cordova-cli and plugman repos anyway. > > > - "Feels" cleaner? > > > > > > -Michal > > > > > > > > > > > > > > > On Mon, Apr 14, 2014 at 2:13 PM, Anis KADRI <anis.ka...@gmail.com> > > wrote: > > > > > > > To brian and steve's points I think it's a bad idea to move common > code > > > to > > > > cordova-cli. I don't think we want another cordova-coho. > > > > > > > > > > > > On Fri, Apr 11, 2014 at 5:36 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > > > > > It would be very good for folks to understand the benefit of using > > npm > > > is > > > > > that we will likely only have to release these small modules very > > > rarely. > > > > > Once the module is out the dependency part is done. This is vastly > > > > simpler > > > > > workflow, smaller codebases to reason about, quicker to test, and > > > easier > > > > to > > > > > ship small releases. If the small module is only applicable to > > Corodva > > > > that > > > > > is fine and good. > > > > > > > > > > This is less complicated. It is easier to share code that is in > > > modules. > > > > > Adding them to the same repo is no different than adding it to the > > > > > package.json and require'ing it in from a programming perspective > > (but > > > it > > > > > does add overhead of a large codebase in a single repo). > > > > > > > > > > Having large monolith codebases is considered a poor practice in > Node > > > > based > > > > > projects and most of Cordova today is a Node based project. I > > recommend > > > > > learning more about the philosophy and reasoning for these > practices. > > > We > > > > > don't need to 'conform' to all Node-isms (like favoring callbacks > to > > > > > promises or streams to sync i/o operations) but the committers here > > > would > > > > > do well to understand those primitives and the motivations for > them. > > > > > > > > > > > > > > > > > > > > On Sat, Apr 12, 2014 at 5:42 AM, Mark Koudritsky < > kam...@google.com> > > > > > wrote: > > > > > > > > > > > On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill < > > stevengil...@gmail.com > > > > > > > > > > wrote: > > > > > > ... > > > > > > > > > > > > > > > > > > > I'd love to get more details about your proposed first patch. > > What > > > do > > > > > you > > > > > > > mean by "Move internal implementation details of plugman into > > > > > > > cordova". I interpret it as move common functionality into cli, > > > make > > > > > > > plugman dependent on cli. > > > > > > > > > > > > Yes, that's the intention. > > > > > > > > > > > > > > > > > > > If that is the case, wouldn't it make more sense > > > > > > > to move the functionality into plugman since the cli already > > > requires > > > > > it? > > > > > > > > > > > > > There is no big difference which way to move the code as long as > > it's > > > > > easy > > > > > > to share, the change is very simple either way. The cli npm > package > > > > name > > > > > is > > > > > > "cordova" which is an argument towards keeping most of the logic > > > there > > > > > > because that's the name people know. For users the change will be > > > > > > transparent, plugman users will continue to "npm install plugman" > > and > > > > cli > > > > > > users will continue to "npm install cordova". > > > > > > > > > > > > I like the end goals of your proposal, in that we are working > > towards > > > > > > > smaller modules. I'm not sure if moving components from one > repo > > to > > > > > > another > > > > > > > is a better way to reach the end goal, instead of Mark's > original > > > > > > > suggestion of a third cordova-lib repo that both plugman + cli > > can > > > > > depend > > > > > > > on. > > > > > > > > > > > > The end goal of my proposal is simplified development workflow > > > without > > > > > > complicating release workflow. > > > > > > > > > > > > Right now I'm working on a new piece of code (dealing with plugin > > > deps > > > > > and > > > > > > versions) that should be used in both plugman and cli. While it > > seems > > > > > like > > > > > > it should be trivial, at a closer look there is currently no > clean > > > way > > > > to > > > > > > share such code between cli and plugman (just like xml helpers > are > > > > > cloned). > > > > > > At this stage that piece of code is nowhere close to being ready > > for > > > > > > release as a separate small module, but it has a good potential > to > > > > > > eventually become such module (though it will never be usable > > outside > > > > > > cordova). > > > > > > > > > > > > > > > > > > > > >
