[ANN] Apache Maven Dependency Analyzer 1.15.0 Released
The Apache Maven team is pleased to announce the release of the Apache Maven Dependency Analyzer, version 1.15.0 This component analyzes the dependencies of a project for undeclared or unused artifacts. https://maven.apache.org/shared/maven-dependency-analyzer/ You should specify the version in your project's dependencies configuration: org.apache.maven.shared maven-dependency-analyzer 1.15.0 You can download the appropriate sources etc. from the download page: https://maven.apache.org/shared/maven-dependency-analyzer/download.cgi Release Notes - Maven Shared Components - Version maven-dependency-analyzer-1.15.0 ** New Feature * [MSHARED-1407] - Track dependency usage by referencing classes * [MSHARED-1410] - Track used declared dependency usage by referencing classes ** Dependency upgrade * [MSHARED-1428] - Upgrade Parent to 43 * [MSHARED-1429] - Bump mavenVersion from 3.9.6 to 3.9.9 Enjoy, -The Apache Maven team - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[RESULT] [VOTE] Release Apache Maven Dependency Analyzer version 1.15.0
Hi, The vote has passed with the following result: +1: Herve Boutemy, Michael Osipov, Sylwester Lachiewicz, Tamás Cservenák PMC quorum: reached I will promote the source release zip file to the Apache distribution area and the artifacts to the central repo. -- Sławomir Jaranowski - 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
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
Re: [DISCUSS] Merge ITs in maven
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 at that time, maybe we might change our mind... Christoph Läubrich 于2024年10月9日周三 14:48写道： > 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 > >
Re: [VOTE] Release Apache Maven Doxia Sitetools version 2.0.0
+1 Reproducible Build ok: reference done with JDK 8 on Windows Regards, Hervé On 2024/10/06 18:49:26 Michael Osipov wrote: > Hi, > > we solved 107 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320&version=12354040 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open > > Staging repo: > https://repository.apache.org/content/repositories/maven-2215 > https://repository.apache.org/content/repositories/maven-2215/org/apache/maven/doxia/doxia-sitetools/2.0.0/doxia-sitetools-2.0.0-source-release.zip > > Source release checksum(s): > doxia-sitetools-2.0.0-source-release.zip > sha512: > 9d589ad5165add7a162343497bacd45316547be03120b282f6de4756580348386f4eff0c54da3dee1649f113f200db21772ab2d5ed307a2f29d2135f056379ed > > Staging site: > https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > 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
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
Re: [DISCUSS] Merge ITs in maven
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 building / developing it. Matthias Am 08.10.2024 um 08:36 schrieb Guillaume Nodet: 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
