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

Reply via email to