On Mon, Oct 9, 2017 at 5:03 PM Robert Munteanu <[email protected]> wrote:
> Hi Andrei, > > On Mon, 2017-10-09 at 14:58 +0000, Andrei Dulvac wrote: > > Hi, > > > > Sorry I'm asking this so late, I wasn't available when this > > discussion was > > at its peak. > > Welcome to the discussion :-) > Thanks! > > > > > With the git extreme repo split, how will commits that touch two > > repos be > > handled? Or pull-requests? Would I have to open two PRs for a > > functionally-atomic change? > > Well, a functionally atomic change should not IMO touch multiple > modules. > What about coding in a feature that requires new API in a new module? Technically, yes, a "functionally-atomic" change can be broken down into two commits that justify themselves as self-standing, but it smells a bit like over-engineering. Would you create two PRs for such a change? Or add the API first, merge the PR, release the API module and then open a PR for the impl? Anyways, I really think what you mean makes sense, but sometimes it's not the reality, especially in modules that are not in maintenance mode. > > If you need to touch multiple modules then you perform multiple commits > or open multiple pull requests. > But the PRs would share the jira issue description, would not be reviewable or testable separately and would have to be merged at the same time... > > > How are projects that have reactors and SNAPSHOT dependencies going > > to work? > > Just like they do before - the CI always builds and deploys snapshots > so each project will be independently buildable. It's been this way > since we switched to per-module Jenkins jobs. > Got it. But wouldn't that make it very hard for local development? > > > It feels to me that this strict one maven module per repo would > > introduce > > some artificial problems and besides git tags, I see no tangible > > advantage > > to doing so. > > When working with 280 modules, simplicity is a great advantage :-) With > the (IMO rare) situation of needing to touch multiple modules in one > go, what other problems do you see with this approach? > Local development (keeping track of logs, N number of the same operations to e.g. checkout branches, revert changes, etc.), github events. But they're all sort of related to the need to build/ deploy/ test more than one maven module at a time. Is it really that rare? > Note that we will introduce a way of locally checking out all > repositories in a single directory so you will be able to work on a > single filesystem view. > I didn't expect anything less :) But that's extra tooling that would have to be maintained. But I guess you use something like gitslave or submodules, in which case it comes for free. > > > If it's a question of two-way referencing, the <scm> tag in the pom > > file > > should be enough for anybody or any tooling. > > Not sure what you mean by two-way referencing, can you elaborate on > that? > A way to infer the repo from an artifact (the reference the other way is obvious; i.e. build code in repo and get artifact) Still, what are the advantages besides a (false?) sense of consistency? Thanks for the explanations, btw! - Andrei > > Thanks, > > Robert >
