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
> >
> >
>

Reply via email to