Hi, Does that mean, every repo will have 1 pom.xml file and no more than one ?
If so, what will be the steps for creating a new module in say contrib/extensions be ? Currently its mkdir edit/build/test commit. Do we now have to contact infra before we can create a new module ? Also, I assume any existing Pull requests will have to be ported to the new structure, and if they cover multiple repositories they will have to be synchronized to prevent breaking builds. Best Regards Ian On 18 October 2017 at 12:56, Oliver Lietz <[email protected]> wrote: > On Tuesday 17 October 2017 23:16:30 Robert Munteanu wrote: > > On Tue, 2017-10-17 at 16:22 +0300, Robert Munteanu wrote: > > > On Tue, 2017-10-17 at 13:03 +0000, Justin Edelson wrote: > > > > On Tue, Oct 17, 2017 at 8:49 AM Robert Munteanu <[email protected] > > > > > > > > wrote: > > > > > Perhaps the people that actually work with these multi-project > > > > > extensions would like to comment? By a quick check we have: > > > > > > > > > > - models > > > > > > > > The models bundles can be released independently, i.e. I've done a > > > > number > > > > of releases of the implementation bundle without touching the API > > > > bundle. > > > > > > > > While Konrad is correct that ITs are an issue, my strong preference > > > > with > > > > Sling Models is to minimize the use of ITs, i.e. use them only for > > > > code > > > > paths which are difficult to test via a unit test, so I don't > > > > really > > > > see > > > > that as an issue. > > > > > > +1, ideally most changes would be covered by an unit test, not an > > > integration test. Even so, validation has its pax-exam ITs in the > > > core > > > bundle, only the test content is outside of the bundle. > > > > Any other comments? At this point I'm inclined to go with git > > repository per module, given that we should cover fixes with > > integration tests rather than unit tests. > > I guess we are able to also move the test services into the core module and > create a bundle for them with Tiny Bundles (already discussed in the past > but > no time for implementing it so far). > > Strong +1 for one Git repo per module (to keep it simple also). > > Thanks again for your great work, Robert! > > Regards, > O. > > > Thanks, > > > > Robert > >
