> 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

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

Reply via email to