As example for dependency-hell, slf4j 1 and 2 use same namespace, means if some dependency use slf4j1 and another use slf4j2, some really disgusting thing will happen. I suffered from that, once.
Xeno Amess <xenoam...@gmail.com> 于2020年8月31日周一 下午9:59写道： > BTW. > From my own view, we might need a testing maven project (or a github > repo), for ensuring all commons repos can be used together, free of > dependency hell, or other internal errors about using different versions of > a same dependency. > But I admit that will really be a time-costing work, and be really hard. > I don't know if we can achieve it by adding the "proper" repo and add a > module pom at base folder, and adding some tests... > Just, I think it useful. > > > John Patrick <nhoj.patr...@gmail.com> 于2020年8月31日周一 下午9:51写道： > >> On Mon, 31 Aug 2020 at 14:16, Gary Gregory <garydgreg...@gmail.com> >> wrote: >> > >> > On Mon, Aug 31, 2020 at 9:11 AM Matt Sicker <boa...@gmail.com> wrote: >> > >> > > Git submodules are pointers to other git commits. Therefore, any >> component >> > > changes made don’t affect the mono repo until you update said mono >> repo to >> > > point to the new commit. If you do this to point at the latest release >> > > tags, this makes for less updates. Otherwise, you’ll want to figure >> out a >> > > CI system for automatically updating submodules to the latest master >> > > commits as they pass CI. >> > > >> > >> > Can that commit be HEAD? >> >> Used git submodules loads 2010-2015, and not much since. But from >> memory it can't be HEAD it has to be a specific commit hash. >> >> We had loads of issues when people worked on the sub modules >> independently, it was easier when every worked with the parent git >> module. But that was early 2010's so it might now allow HEAD or a >> named branch say develop or master/main. >> >> We also had loads of maven warnings because we had a wrapper project >> so from the git parent module it saw the submodules as maven modules. >> But the git parent module maven pom wasn't the parent pom of the git >> submodules maven pom. As parent automatically is >> <relativePath>../pom.xml</relativePath> >> >> Our setup was; >> >> git-module >> -> pom.xml (GAV project:maven-wrapper:1) >> -> git-submodule-parent >> --> pom.xml (GAV project:parent:1) >> -> git-submodule-core >> --> pom.xml (GAV project:core:1, parent GAV project:parent:1) So >> correct relative path is ../git-submodule-parent/poml.xml >> >> They had ~35 git submodules, not sure if they are still using submodules. >> >> So it can be useful if you want to have component based git repo's but >> it does add an extra overhead layer of maintenance and everyone needs >> to be onboard from experience. >> >> John >> >> > >> > Gary >> > >> > >> > > >> > > On Mon, Aug 31, 2020 at 05:17 sebb <seb...@gmail.com> wrote: >> > > >> > > > On Sun, 30 Aug 2020 at 15:01, Gary Gregory <garydgreg...@gmail.com> >> > > wrote: >> > > > >> > > > > >> > > > >> > > > > On Sun, Aug 30, 2020 at 9:47 AM Rob Tompkins <chtom...@gmail.com> >> > > wrote: >> > > > >> > > > > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > > > On Aug 30, 2020, at 9:44 AM, sebb <seb...@gmail.com> wrote: >> > > > >> > > > > > > >> > > > >> > > > > > > Some questions: >> > > > >> > > > > > > >> > > > >> > > > > > > - does it affect any existing usage? >> > > > >> > > > > > > i.e. can people continue to use the individual repos exactly >> as >> > > > before >> > > > >> > > > > > >> > > > >> > > > > > no they can’t >> > > > >> > > > > > >> > > > >> > > > > >> > > > >> > > > > Yes they can... this would be a new repo, and changes nothing for >> > > current >> > > > >> > > > > usage. This does not affect existing repos. >> > > > >> > > > >> > > > >> > > > What about my other queries? >> > > > >> > > > >> > > > >> > > > - changes to commit messages: >> > > > >> > > > can people commit to components directly from the new repo? >> > > > >> > > > If so, does that change the commit messages? >> > > > >> > > > >> > > > >> > > > - maintenance of the new repo: >> > > > >> > > > what is involved, and how will the project know when updates are >> needed? >> > > > >> > > > >> > > > >> > > > > Gary >> > > > >> > > > > >> > > > >> > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > - does it affect Git emails in any way? >> > > > >> > > > > > > e.g. do they have different text? >> > > > >> > > > > > >> > > > >> > > > > > same emails >> > > > >> > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > - will it need much maintenance? >> > > > >> > > > > > > If so, how do we know when it needs updating? >> > > > >> > > > > > >> > > > >> > > > > > more maintainance, have to maintain a git hash at a symlink >> pointing >> > > > to an >> > > > >> > > > > > external repository >> > > > >> > > > > > >> > > > >> > > > > > -Rob >> > > > >> > > > > > >> > > > >> > > > > > > >> > > > >> > > > > > > On Sun, 30 Aug 2020 at 14:26, Gary Gregory < >> garydgreg...@gmail.com >> > > > >> > > > >> > > > > > wrote: >> > > > >> > > > > > >> >> > > > >> > > > > > >> Yes yes "girl" -> "git" >> > > > >> > > > > > >> >> > > > >> > > > > > >> On Sun, Aug 30, 2020, 09:24 Gary Gregory < >> garydgreg...@gmail.com> >> > > > >> > > > > > wrote: >> > > > >> > > > > > >> >> > > > >> > > > > > >>> I'm talking about girl's own submodules: >> > > > >> > > > > > >>> >> > > > >> > > > > > >>> https://git-scm.com/book/en/v2/Git-Tools-Submodules >> > > > >> > > > > > >>> >> > > > >> > > > > > >>> https://git-scm.com/docs/git-submodule >> > > > >> > > > > > >>> >> > > > >> > > > > > >>> Gary >> > > > >> > > > > > >>> >> > > > >> > > > > > >>> On Sun, Aug 30, 2020, 09:09 Rob Tompkins < >> chtom...@gmail.com> >> > > > wrote: >> > > > >> > > > > > >>> >> > > > >> > > > > > >>>> By git submodules, are you talking about a symlink to >> another >> > > git >> > > > >> > > > > > >>>> repository inside one of our repositories? >> > > > >> > > > > > >>>> >> > > > >> > > > > > >>>> -Rob >> > > > >> > > > > > >>>> >> > > > >> > > > > > >>>>> On Aug 29, 2020, at 6:52 PM, Gary Gregory < >> > > > garydgreg...@gmail.com> >> > > > >> > > > > > >>>> wrote: >> > > > >> > > > > > >>>>> >> > > > >> > > > > > >>>>> Hi All, >> > > > >> > > > > > >>>>> >> > > > >> > > > > > >>>>> Any thoughts for or against creating a new git repository >> which >> > > > would >> > > > >> > > > > > >>>>> contain all 'proper' Commons components as git submodules? >> > > > >> > > > > > >>>>> >> > > > >> > > > > > >>>>> The idea is to be able to checkout all of Commons >> 'proper' in >> > > > one go >> > > > >> > > > > > in >> > > > >> > > > > > >>>> one >> > > > >> > > > > > >>>>> place. >> > > > >> > > > > > >>>>> >> > > > >> > > > > > >>>>> Gary >> > > > >> > > > > > >>>> >> > > > >> > > > > > >>>> >> > > > >> > > > > > >>>> >> > > > >> --------------------------------------------------------------------- >> > > > >> > > > > > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > >> > > > > > >>>> For additional commands, e-mail: >> dev-h...@commons.apache.org >> > > > >> > > > > > >>>> >> > > > >> > > > > > >>>> >> > > > >> > > > > > > >> > > > >> > > > > > > >> > > --------------------------------------------------------------------- >> > > > >> > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > >> > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > > >> --------------------------------------------------------------------- >> > > > >> > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > >> > > > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > >> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > > >> > > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > > >> > > > >> > > > >> > > > -- >> > > Matt Sicker <boa...@gmail.com> >> > > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
