Maven 3.9.7 generates dodgy snapshot maven-metadata.xml
Hello, we do builds up against the latest snapshot in our dev environment. After switching our builds from maven 3.8.5 to 3.9.7 we find that the maven-metadata.xml generated for our snapshot libraries is incorrect, resulting in a build up against the **previous** snapshot. Switching back to 3.8.5 fixes the issue. The incorrect metadata is generated when we "mvn deploy" our library. I took a look at the release logs for 3.9.8 and 3.9.9 and could not see any fixed issues which seemed to resemble this problem. We will try out 3.9.9 once we get it installed on our build system. We are using an updatePolicy of always on our snapshot repo. true always our-snapshot our-snapshots https://someurlhere Example incorrect file below. The *jar snapshotVersion *is one build number back, it should be 516 redacted also-redacted 0.30.17-SNAPSHOT 20241010.231422 516 20241010231529 sources jar 0.30.17-20241010.231422-516 20241010231422 jar 0.30.17-20241010.215322-515 20241010215322 pom 0.30.17-20241010.231422-516 20241010231422 Thanks!
Re: [DISCUSS] Merge ITs in maven
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… > > > Guillaume Nodet > > > > Le jeu. 10 oct. 2024 à 09:41, Michael Osipov a écrit : > > > 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 could live as an optional submodule with a > > Maven profile being activated. Those who need it can init the > > subrepo/submodule. > > > > Michael > > > > - > > 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
Re: [DISCUSS] Merge ITs in maven
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 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 > >
Re: [DISCUSS] Merge ITs in maven
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 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: de
Re: [DISCUSS] Merge ITs in maven
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: > > * 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 could live as an optional submodule with a > Maven profile being activated. Those who need it can init the > subrepo/submodule. > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Merge ITs in maven
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, 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: > > * 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 could live as an optional submodule with a > Maven profile being activated. Those who need it can init the > subrepo/submodule. > > Michael > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [DISCUSS] Merge ITs in maven
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 could live as an optional submodule with a Maven profile being activated. Those who need it can init the subrepo/submodule. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
