Mostly what matters is the release cadence (that is somewhat in line with "what works with what').
Rule of thumb: if you have an artifact that SHOULD be released when another is released, keep it together. Otherwise, no need to tie them together (disclaimer: yes, there is all the clien side pain, what works with what, etc, but a site could explain that just nicely, or, just provide a table of versions). My 5 cents, T On Thu, Aug 31, 2023 at 3:38 PM Volkan Yazıcı <[email protected]> wrote: > *[Sorry for the late response. I was busy with incorporating your input > into the attack plan document.]* > > Thanks so much for the pointers and the insight Hervé (and Romain!), much > appreciated! > > For those interested, Log4j's motivation and proposals are shared in this > `dev@logging` thread > <https://lists.apache.org/thread/9mz47opyjwtf15ylhd1h2k8r5lzydf2g>. If you > have any feedback, I would be more than happy to hear. > > On Sat, Aug 26, 2023 at 2:03 PM Hervé Boutemy <[email protected]> > wrote: > > > 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-*> > > <http://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: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
