I see the main issues with a tighter coupling of API and Impl with the according IT module or test-services bundle. In the best case every bugfix or new feature should also be reflected in the ITs. So after thinking a bit more about it, I think it is fine to derive from our general 1 module = 1 git repository pattern for at least
1. validation 2. models 3. healthcheck and maybe some others where the ITs are in a dedicated module and not in the generic launchpad testing. That way it is much easier to encourage people to also contribute to ITs (because opening two PRs, one for the actual feature/bugfix and another one for the IT is a lot of hassle). Also checking the PRs becomes easier, because the reactor build will also build and execute the ITs. Konrad > Am 17.10.2017 um 14:49 schrieb Robert Munteanu <romb...@apache.org>: > > 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
