Repository navigation
Combine Java modules into main testcontainers-java repo #564
Description
On reflection we feel that moving modules/third-party parts into separate Git repositories was a mistake on a few levels:
- My initial thinking was to have separate versioning for the main project and modules, but this quickly turned out to be not something people want
- The level of coordination required to synchronise version numbers and perform a synchronised release, across repos, is too much. We can automate some, but not all of the process, and edge cases really hurt us.
- This has resulted in the modules neither being released independently (freely) nor in sync - so we have the worst of both worlds, sadly.
As such, we've decided we'd like to bring all modules back in to this testcontainers-java repo.
Firstly, we need permission from the authors of each of the modules where another organisation is marked as the copyright owner. We will, of course, do whatever's right and works for all concerned. If the following people wouldn't mind making their views known I'd be most grateful.
- testcontainers-java-module-vault: @mikeoswald
- testcontainers-java-module-mssqlserver: @StefanHufschmidt
Then, some other challenges we want to address as part of this exercise:
- How do we keep the build fast?: Gradle build cache should help a lot (Gradle #574)
- Is Maven holding us back in keeping the build fast? see above
- What's our release process?
- How do we ensure that module owners/'authoritative people' have the right involvement in reviewing changes and deciding when to make a release?: Github CODEOWNERS feature will help.
- Rework to documentation (add mention of modules)
Activity
kiview commentedon Feb 2, 2018
I've already talked to @StefanHufschmidt, this should be possible for
testcontainers-java-module-mssqlserver.Here are some of the current ideas we've already discussed:
Regarding the permission problem for sub-module maintainers:
Would Git sub-modules help, if we keep them up-to date automatically?
rnorth commentedon Feb 3, 2018
Thanks :)
I'm afraid I have nightmares about submodules, so would be reluctant to involve these. Unless I'm mistaken we'd also have a problem of triggering top-level builds, as a mirror image of the problem we have of triggering builds the other way right now.
I think if there's a worry about permissions let's try it and see how things go. Module owners will hopefully continue to be involved in reviewing PRs for their area of interest, and I think we should be willing to delegate some trust accordingly...
asafm commentedon Feb 4, 2018
rnorth commentedon Feb 8, 2018
@asafm - don't know how I missed that when it was announced, but that's awesome 😀
rnorth commentedon Mar 13, 2018
@mikeoswald would you be able to comment on whether we can bring the vault module into the main Testcontainers repo? If not, or if you need time to consider, that's OK; I can leave it unmodified and not migrate it yet.
mikeoz0 commentedon Mar 13, 2018
@rnorth Sorry about the late reply. That would be fine to move it into the main repository.
rnorth commentedon Mar 13, 2018
Awesome, thanks @mikeoswald!
rnorth commentedon Mar 13, 2018
Regarding release process, the bintray repository is now linked to JCenter. As I can never remember the process to wire up bintray/jcenter and maven central, @bsideup it would be good if we can perform the next release together some time..!
bsideup commentedon Mar 13, 2018
@rnorth sure! Next release is on me :)
rnorth commentedon Mar 13, 2018
I've mentioned the Couchbase module in #269 - I don't think we'll have time to integrate right away though.
kiview commentedon Mar 26, 2018
@rnorth Since you've finished the acutal implementation in #607 the only thing missing from the checklist is the release process.
Is the release implicitly working right now, aligning every module to the parent version on release/publish?
bsideup commentedon Apr 7, 2018
1.7.0 released today is a first release based on Gradle & monorepo, with all modules released at once