Re: Eat our own dogfood
Apache used to operate Gump for this purpose, back on the days of Ant and Maven 1.x.
Help needed for solving MNG-7310
Hi all,
A while ago I encountered a bug [1] in Maven 4 which I'm testing at work. I
took quite some time into debugging the issue, but I am at a dead end
currently.
The issue should describe the problem enough, but in short I understand it
as the following:
1. Multi module project with two submodules A and B.
2. "A" defines a plugin, which is an extension and which registers a new
lifecycle. This lifecycle uses the ${project.version} variable.
3. During the model "B" validation (DefaultModelValidator), the
lifecycle of "A" is suddenly validated as well, and trips on the
${project.version} usage.
Important to note is that this problem is introduced in a commit from April
2nd 2020 [2]. This commit "just" converted maven-core from Plexus DI to
Guice DI.
In earlier Maven versions, the custom lifecycle is not injected during the
model validation of B, but that happens at a later moment.
Does anyone understand why such a change could occur when changing from
Plexus DI to Guice DI?
Any pointers are welcome.
Thanks,
Martin
[1] https://issues.apache.org/jira/browse/MNG-7310
[2]
https://github.com/apache/maven/commit/9567da2bc889a94f5c3b692b4afb310ddbacd6e5
Re: Eat our own dogfood
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" Aan: "Maven Developers List" ; "Maarten Mulders" 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy merged pull request #272: Clarify HEAD being the default for scm.tag
hboutemy merged pull request #272: URL: https://github.com/apache/maven-site/pull/272 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-site] hboutemy commented on pull request #272: Clarify HEAD being the default for scm.tag
hboutemy commented on pull request #272: URL: https://github.com/apache/maven-site/pull/272#issuecomment-964163051 you're right https://maven.apache.org/ref/3.8.3/maven-model/maven.html#class_scm thank you -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
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 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
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 OpenPGP_signature Description: OpenPGP digital signature
