do there really be...some widely used 3rd-party distribution (non-apache) for maven?
I know this situation be true for openjdk, but for maven I really didn't notice any... Anders Hammar <and...@hammar.net> 于2024年10月10日周四 15:26写道： > On Thu, Oct 10, 2024 at 8:46 AM Herve Boutemy <hbout...@apache.org> wrote: > > > > I always has seen this > > > more as some kind of compatibility-test-kit that can be used > independent > > > of maven itself. > > > > yes, this rings a bell: compatibility-test-kit is the spirit that was > > promoted at that time, with "apache distribution" being just one > > distribution > > > > Yes, that was the rationale back then. But I see no reason why the > project's view of this could change, especially as there are other people > doing the development nowadays. > > /Anders > > > > > > definitively a discontinued approach... > > > > On 2024/10/09 06:48:22 Christoph Läubrich wrote: > > > 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 > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
