+1 for merging, but please keep the ability to run them against any version
Enrico
Il Sab 12 Ott 2024, 15:28 Tamás Cservenák ha scritto:
> Howdy,
>
> I am with Herve here: +1 to merge, as long as we don't lose the "run
> IT suite on custom distro" ability
>
> Thanks
> T
>
> On Fri, Oct 11, 20
Howdy,
I am with Herve here: +1 to merge, as long as we don't lose the "run
IT suite on custom distro" ability
Thanks
T
On Fri, Oct 11, 2024 at 8:33 PM Hervé Boutemy wrote:
>
> in fact, putting everything in 1 Git repo does not force to run 1 single
> build: we can continue running in separate
in fact, putting everything in 1 Git repo does not force to run 1 single
build: we can continue running in separate executions
and with this, nothing prevents from running the its HEAD against another
commit for Maven core build
Le jeudi 10 octobre 2024, 13:47:31 CEST Michael Osipov a écrit :
>
the resulting history looks reasonable
and we can later split with filter if necessary
I don't know if making one single build is useful, or keeping 2 separate, or
even promoting 3 (Maven core itself, ITs build, ITs run)
But definitively, doing one single Git commit when doing a feature is a cle
On Thu, Oct 10, 2024 at 7:32 AM Xeno Amess wrote:
>
> 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...
>
No, there isn't. This was a now abandoned plan and can be rev
No, it won't, but it will allow you to integrate the IT w/o pulling them in
physically.
On 2024/10/10 11:22:25 Guillaume Nodet wrote:
> I don’t see git submodules fixing the pain of having to create two PRs,
> keeping them aligned, having to merge or rebase both at the same time…
>
> ---
instead sub module makes them more pain ...
发件人: Guillaume Nodet
发送时间: 星期四, 十月 10, 2024 7:22:45 下午
收件人: Maven Developers List
主题: Re: [DISCUSS] Merge ITs in maven
I don’t see git submodules fixing the pain of having to create two PRs,
keeping them aligned
I don’t see git submodules fixing the pain of having to create two PRs,
keeping them aligned, having to merge or rebase both at the same time…
Guillaume Nodet
Le jeu. 10 oct. 2024 à 09:41, Michael Osipov a écrit :
> A few notes on this though I am neutral:
>
> * Signi
A few notes on this though I am neutral:
* Significant growth of repo, thus repo size for those who simply don't need ITs
* A compat kit (which it is) is usually a separate repo/product/project
* Though I consider Git submodules as a horrible implementation compared to
Subversion externals, it co
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 于2024年10月10日周四 15:26写道：
> On Thu, Oct 10, 2024 at 8:46 AM Herve Boutemy wrote:
>
> > > I always has seen thi
On Thu, Oct 10, 2024 at 8:46 AM Herve Boutemy 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 distrib
> 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
Yes, that's definitely not a problem.
I was simply stating that merging the branch is not sufficient and that the
real integration needs to be done.
Le mer. 9 oct. 2024 à 09:21, Xeno Amess a écrit :
> RAT checks has a excluding rule, if we really wanna so we can just exclude
> that folder anyway
RAT checks has a excluding rule, if we really wanna so we can just exclude
that folder anyway...
Guillaume Nodet 于2024年10月9日周三 15:11写道：
> I just pushed a branch with the results:
>https://github.com/gnodet/maven/tree/merge-its
>
> This is just the raw output of the recipe. The ITs are not i
I just pushed a branch with the results:
https://github.com/gnodet/maven/tree/merge-its
This is just the raw output of the recipe. The ITs are not integrated into
the build, which will even fail due to RAT checks and maybe other reasons.
Le mer. 9 oct. 2024 à 08:35, Herve Boutemy a écrit :
Sigh. This shall be a typical scenario for git submodule, but as we all
know, git submodule is something designed so disaster that nearly shit, if
not worse than shit.
.I myself vote +1 for the merge if I have the right to, for now, but
like Herve Boutemy said if we could know why guys split them
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
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
I don't know the history about WHY they are seperated, so maybe there
are (or at least there were) valid reason to do so - at least in this
repo. In several plugins the IT are part of the same repo as the code.
In general: I think it's usefull to merge them so that the IT can be run
while buildin
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
20 matches
Mail list logo
