You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Maarten Mulders <mt...@apache.org> on 2021/11/09 10:52:18 UTC
Eat our own dogfood
Hi all,
In the last year, we've seen multiple situations where a change in Maven core
prevented Maven from building itself [1][2].
On the path to stabilising Maven towards Maven 4, I think this isn't helping
us. That's why I propose we introduce an additional GitHub action. Let's call
it the "eat our own dogfood" check: build Maven Core, then use that build to
build Maven Core again.
Maybe it's possible to do it on Jenkins, too. I'm less familiar with our
Jenkins setup, that's all...
What do you think?
Thanks,
Maarten
[1] https://issues.apache.org/jira/browse/MNG-7087
[2] https://issues.apache.org/jira/browse/MNG-7319
Re: Eat our own dogfood
Posted by Robert Scholte <rf...@apache.org>.
There's another project that is suffering from this change:
https://github.com/quick-perf/maven-test-bench
This is a benchmark comparing the performance on a specific commit on
Camel (as it is a huge project)
It would be great if we could have statistics on a wide range of Maven
version.
There are a couple of options:
- restore the constructor causing the issue (if the removed class is
still on the classpath, this would be a easy and valuable change)
- select a different commit (and/or project)
thanks,
Robert
------ Origineel bericht ------
Van: "Paul Hammant" <pa...@hammant.org.invalid>
Aan: "Maven Developers List" <de...@maven.apache.org>; "Robert Scholte"
<rf...@apache.org>
Verzonden: 10-11-2021 08:43:39
Onderwerp: Re: Eat our own dogfood
>Apache used to operate Gump for this purpose, back on the days of Ant and
>Maven 1.x.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Eat our own dogfood
Posted by Gavin McDonald <gm...@apache.org>.
On Wed, Nov 10, 2021 at 8:44 AM Paul Hammant <pa...@hammant.org.invalid>
wrote:
> Apache used to operate Gump for this purpose, back on the days of Ant and
> Maven 1.x.
>
Still does: http://vmgump.apache.org/
--
*Gavin McDonald*
Systems Administrator
ASF Infrastructure Team
Re: Eat our own dogfood
Posted by Paul Hammant <pa...@hammant.org.INVALID>.
Apache used to operate Gump for this purpose, back on the days of Ant and
Maven 1.x.
Re: Eat our own dogfood
Posted by Robert Scholte <rf...@apache.org>.
This should be done as part of Mavens own build.
Don't rely on uploaded versions, there's always a gap where another job
could have uploaded a different version.
If things start to fail, it could be hard to reproduce it.
It should be the one that has been built and stashed, so you can unstash
and unpack it in a new stage.
Robert
------ Origineel bericht ------
Van: "Slawomir Jaranowski" <s....@gmail.com>
Aan: "Maven Developers List" <de...@maven.apache.org>; "Maarten Mulders"
<mt...@apache.org>
Verzonden: 9-11-2021 12:56:26
Onderwerp: Re: Eat our own dogfood
>Hi,
>
>Good idea.
>
>One of the resolutions can be to use maven wrapper to configure the Maven
>version to use, and use wrapper to build a project.
>Such a solution can be easily used in any CI system.
>
>Using a wrapper we simply download the latest build and deployed Maven
>version from the repository, we don't need to build the project twice.
>I assume that deployment is done after all tests pass so the repository
>will contain a working version.
>
>Task to do before:
> - Make maven wrapper functional [1]
> - Support SNAPSHOT versions by wrapper [2]
>
>[1] https://issues.apache.org/jira/browse/MWRAPPER-14
>[2] https://issues.apache.org/jira/browse/MWRAPPER-15
>
>
>wt., 9 lis 2021 o 11:52 Maarten Mulders <mt...@apache.org> napisał(a):
>
>> Hi all,
>>
>> In the last year, we've seen multiple situations where a change in
>> Maven core prevented Maven from building itself [1][2].
>>
>> On the path to stabilising Maven towards Maven 4, I think this isn't
>> helping us. That's why I propose we introduce an additional GitHub
>> action. Let's call it the "eat our own dogfood" check: build Maven Core,
>> then use that build to build Maven Core again.
>>
>> Maybe it's possible to do it on Jenkins, too. I'm less familiar with our
>> Jenkins setup, that's all...
>>
>> What do you think?
>>
>>
>> Thanks,
>>
>> Maarten
>>
>>
>> [1] https://issues.apache.org/jira/browse/MNG-7087
>> [2] https://issues.apache.org/jira/browse/MNG-7319
>>
>
>
>--
>Sławomir Jaranowski
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Eat our own dogfood
Posted by Slawomir Jaranowski <s....@gmail.com>.
Hi,
Good idea.
One of the resolutions can be to use maven wrapper to configure the Maven
version to use, and use wrapper to build a project.
Such a solution can be easily used in any CI system.
Using a wrapper we simply download the latest build and deployed Maven
version from the repository, we don't need to build the project twice.
I assume that deployment is done after all tests pass so the repository
will contain a working version.
Task to do before:
- Make maven wrapper functional [1]
- Support SNAPSHOT versions by wrapper [2]
[1] https://issues.apache.org/jira/browse/MWRAPPER-14
[2] https://issues.apache.org/jira/browse/MWRAPPER-15
wt., 9 lis 2021 o 11:52 Maarten Mulders <mt...@apache.org> napisał(a):
> Hi all,
>
> In the last year, we've seen multiple situations where a change in
> Maven core prevented Maven from building itself [1][2].
>
> On the path to stabilising Maven towards Maven 4, I think this isn't
> helping us. That's why I propose we introduce an additional GitHub
> action. Let's call it the "eat our own dogfood" check: build Maven Core,
> then use that build to build Maven Core again.
>
> Maybe it's possible to do it on Jenkins, too. I'm less familiar with our
> Jenkins setup, that's all...
>
> What do you think?
>
>
> Thanks,
>
> Maarten
>
>
> [1] https://issues.apache.org/jira/browse/MNG-7087
> [2] https://issues.apache.org/jira/browse/MNG-7319
>
--
Sławomir Jaranowski