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
