Hi Christian, Thanks for bringing this to the dev list. I have seen part of this argument from various people, but until now no one has decided to actually write about it :-)
On Tue, 2017-10-17 at 13:49 +0200, Christian Schneider wrote: > I am bit concerned about the number of repositories we are about to > create > on git and the relation between them. > > Lets take an extension as an example: > > validation > - reactor > - api > - core > - examples > - test-services > > If I understand correctly then we plan to create one git repo for > each > module above. So it would be 5 repos for the validation extension. > > I think this is quite problematic for several reasons. > - If you change something in validation you often will change more > than one > of the modules above. > - Like in svn today you can easily forget to update dependencies > after a > release. This results in the build not working anymore after the old > snapshots are discarded by nexus. Addtionally you build with a > potentially > wrong set of dependencies in the meantime. In git this is even more > problematic as you need to update several repos then to make changes > instead just several directories in one svn tree. > - It is difficult to do a build of the whole validation extension Well, these are 4 repositories, there will not be a validation.reactor modules. I don't think the examples change a lot, and we should probably move all examples/samples to the 'sling-samples' repo, where they are more visible ( personal opinion, nothing discussed/decided yet ). So I would not count examples as a repository that creates overhead. Indeed, there can be scenarios where api + impl or api + impl + tests need to change together. My gut feeling though is that they don't happen that often. And many of our modules have 'in-module' integration tests, where there is no test content outside of the bundle. For checking out and building multiple grouped projects we would like to use a tool such as google repo. See [1] and [2] for some rough ideas. In the same way we can generate one of more aggregator poms. What does remain mostly uncovered is commits and pushes to multiple repositories. There you indeed have to perform multiple commits. But I'd argue that either: - impl changes frequently, api does not ; not a problem for us - impl changes frequently, api changes as well; looks like api and impl are really tied together so should they really be separate bundles? > So I propose to rather use one repository per extension. Additionally > I > would also version and release the whole extension together. > - This makes it easy to do and test changes that reach over more than > one > module > - The release process is much easier and you can not forget to update > dependencies > > Of course such a model creates some unnecessary artifacts in a > release. For > example you would get a new api bundle even when there are no changes > in > it. This is not very problematic though as we already version APIs on > package level. So the user would still have full backwards > compatibility. > > The difficult task in this model is of course which modules to bundle > together in a repo. I think for extensions this is obvious but for > other > parts of sling it is less clear. > > As a good example that this approach can work see the apache aries > project. > In Aries we used to release each bundle individually. This created > the same > problems as in sling. We moved some projects to git but on a coarse > grained > level and it seems to work quite well. > > See these projects as examples: > https://github.com/apache/aries-rsa > https://github.com/apache/aries-jpa The problems we can encounter are mostly build related, and not affected by releases. If this model is working for Aries we can consider it. I do not oppose it, even though my preference is different. Perhaps the people that actually work with these multi-project extensions would like to comment? By a quick check we have: - caconfig - healthchek - models - sightly - validation as reactor poms with more than 2 modules in the /bundles subtree. Thanks, Robert > > Each of those projects can be built in one step and the build is > always > consistently using the correct versions. A release can be done on top > level > in one step. Still for example the Aries RSA spi is still at package > version 1.0.0. So external projects that build on it will still be > compatible with the newest Aries RSA release. > > I know I am a it late to the party with my proposal but Robert > encouraged > me to still come up with it as after the move to git it will be too > late. [1]: https://cwiki.apache.org/confluence/display/SLING/Move+from+Subver sion+to+Git [2]: https://issues.apache.org/jira/browse/SLING-7164
