notice that you call it "multi-repo experience" it's in fact more about a topic of component-oriented structure, each component having its own release lifecycle. The fact that each component has his own Git repository is just an implementation detail (in the past, each component had its own root directory in Subversion: see [1] for how we went from svn structure to Git one).
> Would you still go the same route if Maven is founded today? yes: Maven is a core, with plugins (and extension) = something we would not change without loosing critical aspects of Maven and the fact that some plugins reuse some shared components is normal of course, the exact number of plugins and shared components could have been done with different granularity And on using Google repo tool and the precise directory organisation when checking out everything, it's an implementation detail: https://github.com/apache/maven-sources/tree/master Changing anything here can be done, it's not critical: what is critical is the component-oriented approach. Then the granularity chosen for these components. Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration Le samedi 26 août 2023, 09:50:28 CEST Hervé Boutemy a écrit : > Hi Volkan, > > Yes, I worked a lot on this aspect fo Maven: the result is summarised here > https://maven.apache.org/scm.html > > As you can see, you can get "Maven Full Sources" in one command using Google > "repo" tool. > > Please have a llok and we can dive into more details if you need > > Regards, > > Hervé > > Le jeudi 24 août 2023, 12:30:41 CEST Volkan Yazıcı a écrit : > > Hello, > > > > Log4j crew is considering moving to a multi-repo structure. If I am not > > mistaken, there are 125 `github.com/apache/maven-*` > > <http://github.com/apache/maven-*> repos, which makes me believe that you > > have quite a bit of experience with such a construct. I am curious to hear > > your thoughts on the matter. > > > > How does it work for you? > > What are its advantages? > > What are its disadvantages? > > What are the things we should be extra cautious about? > > Are there any major pillars we need to erect for such a construct to work? > > Would you still go the same route if Maven is founded today? > > > > I deliberately don't share in this post our goals with such a migration to > > avoid manipulating your line of thinking. I can do that later to give the > > conversation a little bit more context. > > > > Kind regards. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
