Sigh. This shall be a typical scenario for git submodule, but as we all know, git submodule is something designed so disaster that nearly shit, if not worse than shit.
.I myself vote +1 for the merge if I have the right to, for now, but like Herve Boutemy said if we could know why guys split them at that time, maybe we might change our mind... Christoph Läubrich <m...@laeubi-soft.de> 于2024年10月9日周三 14:48写道： > Maybe adding it as a git submodule would also help, then it could be > fetched/build together but still retain a separate git repo. > > I agree that having to specify version ranges for maven version in each > test looks odd if it is part of the repo itself, I always has seen this > more as some kind of compatibility-test-kit that can be used independent > of maven itself. > > > Am 09.10.24 um 08:33 schrieb Herve Boutemy: > > I understand how it adds complexity > > > > AFAIK, the interest of having a separate project of core ITs is to clear > state the Maven core version range for each test, to clearly document when > things were introduced / broken / fixed and even be able to run HEAD ITs > against a past release > > > > is it the only reason? I don't know, it's the key aspect I understood 15 > years ago when it was done and I was too noob to really grasp every detail > :) > > > > does this really deserve the complexity it creates? > > I don't know > > > > I also need to check the Git merge recipe, to see how the result would > be ok to me: do you have a personal fork somewhere so we can review without > running the command ourselves? > > > > Regards, > > > > Hervé > > > > On 2024/10/08 06:36:19 Guillaume Nodet wrote: > >> I'd like to discuss merging ITs into maven core repository. > >> The ITs have already been splitted some time ago between the 3.x branch > and > >> master for testing Maven master. But I don't really see a good reason > to > >> keep the repositories separated, this makes things more complicated when > >> modifying maven code and adding ITs. > >> > >> The following script allow merging the two repositories while keeping > both > >> histories: > >> > >> > >> brew install git-filter-repo > >> > >> git clone https://github.com/apache/maven > >> > >> git clone https://github.com/apache/maven-integration-testing > >> > >> (cd maven-integration-testing && \ > >> > >> git filter-repo --to-subdirectory-filter its) > >> > >> (cd maven && \ > >> > >> git remote add its ../maven-integration-testing && \ > >> > >> git fetch its --no-tags && \ > >> > >> EDITOR=true git merge --allow-unrelated-histories its/master && \ > >> > >> git remote remove its) > >> > >> The next step would be to actually include them in a profile and update > the > >> github workflow. > >> I think they could be refactored to: > >> * first perform a full run on Ubuntu + latest LTS JDK: > >> - restore cache > >> - checkout > >> - build with no tests > >> - run IT bootstrap (to prime local repo) > >> - save cache > >> - build again with tests and ITs > >> * if this first run succeeds, do the same on other platforms / jdks > >> > >> The cache is important to add imho. It seems lately, GH runners have > often > >> problems downloading from maven central, so that would help a lot > >> increasing the stability. So using > >> https://github.com/marketplace/actions/maven-cache or a similar action > >> would be handy imho. > >> > >> We should also upload nightlies from GH. > >> And automate the releases as much as possible.... > >> > >> -- > >> ------------------------ > >> Guillaume Nodet > >> > > > > --------------------------------------------------------------------- > > 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 > >
