Re: Request for Enhancement: Dependency Overrides
Hi Enno, 2 things. I'd want to emphasise that the resolution of dependency management info and the dependency overrides (more like a reactor management concern) are independent of one another. Can achieve by promoting the tag to project. Then why not use the existing dependency tag to define the replacement(s). Accept 0, 1 or many. ... a a y y z z q q w w x x ... Regards, Delany On Sun, 21 Nov 2021 at 02:05, Enno Thieleke wrote: > Hello, > > it's been a while and I've made some progress regarding > overrides/replacements and wanted to share the current state. > > What's implemented/changed: > > * The POM version has been upgraded to 4.1.0 and will accept > /project/dependencyManagement/dependencyOverrides which in turn can take > the coordinates of original and overriding artifacts. > * Overrides can be declared on any POM level in a hierarchy POMs (i.e. > parents and children. > * Overrides can be imported from other POMs using the existing > `import` scope for POMs in the dependencyManagement section. > * If the same original artifact is overridden on different levels, the > "most downstream" wins. > * An override *must* be accompanied by an entry in the > dependencyManagement section. Maven generates an error and halts, if that's > not the case. > * If an override is declared and consumed in the same effective POM, > Maven generates a warning that the user should use the overriding artifact > instead of the original artifact. > * The dependencies of an effective POM remain untouched. Overrides are > declared in POMs, but the act of overriding is implemented in > maven-resolver. > * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because > interfaces needed additions. While some might consider this to be a minor > change, I consider this to be a major change, because the interfaces are > not (and cannot be, yet) sealed. > * It is possible to override overrides of transitive dependencies. In > other words, it is possible to override overrides of POMs of dependencies. > > While working on this I thought about names for overrides/replacements. > I'm still open to suggestions and pretty much undecided. Another name that > popped into my head is `dropinReplacements`, because it makes the intent > very clear. > > For those of you who are interested, here are the links to the code again > (so it's just one click away): > > * https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530 > * https://github.com/strohmattenverleger/maven/tree/MNG-4530 > * https://github.com/strohmattenverleger/maven-MNG-4530-example > > Also, I've rebased my changes onto master very recently. > > And here's the proposal itself: > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md > > If you find the time to look, please let me know what you think and what > you think is missing. > > Kind regards > Enno > > > From: Romain Manni-Bucau > Sent: Sunday, September 5, 2021 8:34 AM > To: Maven Developers List > Subject: Re: Request for Enhancement: Dependency Overrides > > A few notes on the proposal: > > >- Leave a dependency graph virtually untouched. >Only change/override nodes in place. Don't exclude dependencies and >include new ones on a different level in the graph. > > Think, whatever it means, served dependencies in mojo shouldnt have to rely > on this new section using getXArtifact or dependency visitor. No real good > reason to break everyone there. > > A not used override must break the build (it is an unexpected bug and would > make the dev life hard otherwise). I perfectly see that it will break > building a submodule in several cases but otherwise the section will become > unmanageable with time (see hibernate or cxf example) and since you loose > the dependency relationship with this option compared to exclusions, it way > too much work to maintain it in practise. (This is why I think it shouldnt > be done this way but very worse case at dependency level giving hints for > overrides and not elsewhere, mixed with dependency managementnit is trivial > to handle and maintain then). > > Pom rewriter must handle this section by dropping it and replacing it by > exludes to keep compatibility with 3rd party resolvers (deployment). > > Overall, I still think it would be neat to see it as an extension for maven > 3.8.2 or 4 to be testable and validate design choices and actual usage on > real dependencies compared to current option. > > Le sam. 4 sept. 2021 à 23:21, Enno Thieleke > a > écrit : > > > Hello again, > > > > I tried to create a proposal in/under > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567 > , > > but I'm not allowed to, which makes sense since I'm new to the wiki, so I > > committed a proposal to my fork: > > >
Re: [maven-enforcer] branch master updated (3047f7f -> e3f2f27)
Hi, I'm new to this group and would like to contribute. How best can I do that? Please advise, Thanks, Asha On Sat, Nov 20, 2021 at 8:03 PM wrote: > This is an automated email from the ASF dual-hosted git repository. > > slachiewicz pushed a change to branch master > in repository https://gitbox.apache.org/repos/asf/maven-enforcer.git. > > > from 3047f7f Bump mockito-junit-jupiter from 3.12.4 to 4.0.0 > add e3f2f27 [MENFORCER-372] Drop PlexusTestCase and junit:junit > dependency > > No new revisions were added by this update. > > Summary of changes: > enforcer-rules/pom.xml | 11 +-- > .../apache/maven/plugins/enforcer/MockProject.java | 4 ++-- > maven-enforcer-extension/pom.xml | 5 - > maven-enforcer-plugin/pom.xml | 23 > -- > pom.xml| 23 > +++--- > 5 files changed, 14 insertions(+), 52 deletions(-) >
Re: Request for Enhancement: Dependency Overrides
Hello, it's been a while and I've made some progress regarding overrides/replacements and wanted to share the current state. What's implemented/changed: * The POM version has been upgraded to 4.1.0 and will accept /project/dependencyManagement/dependencyOverrides which in turn can take the coordinates of original and overriding artifacts. * Overrides can be declared on any POM level in a hierarchy POMs (i.e. parents and children. * Overrides can be imported from other POMs using the existing `import` scope for POMs in the dependencyManagement section. * If the same original artifact is overridden on different levels, the "most downstream" wins. * An override *must* be accompanied by an entry in the dependencyManagement section. Maven generates an error and halts, if that's not the case. * If an override is declared and consumed in the same effective POM, Maven generates a warning that the user should use the overriding artifact instead of the original artifact. * The dependencies of an effective POM remain untouched. Overrides are declared in POMs, but the act of overriding is implemented in maven-resolver. * I set the version of maven-resolver to 2.0.0-SNAPSHOT, because interfaces needed additions. While some might consider this to be a minor change, I consider this to be a major change, because the interfaces are not (and cannot be, yet) sealed. * It is possible to override overrides of transitive dependencies. In other words, it is possible to override overrides of POMs of dependencies. While working on this I thought about names for overrides/replacements. I'm still open to suggestions and pretty much undecided. Another name that popped into my head is `dropinReplacements`, because it makes the intent very clear. For those of you who are interested, here are the links to the code again (so it's just one click away): * https://github.com/strohmattenverleger/maven-resolver/tree/MNG-4530 * https://github.com/strohmattenverleger/maven/tree/MNG-4530 * https://github.com/strohmattenverleger/maven-MNG-4530-example Also, I've rebased my changes onto master very recently. And here's the proposal itself: https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md If you find the time to look, please let me know what you think and what you think is missing. Kind regards Enno From: Romain Manni-Bucau Sent: Sunday, September 5, 2021 8:34 AM To: Maven Developers List Subject: Re: Request for Enhancement: Dependency Overrides A few notes on the proposal: - Leave a dependency graph virtually untouched. Only change/override nodes in place. Don't exclude dependencies and include new ones on a different level in the graph. Think, whatever it means, served dependencies in mojo shouldnt have to rely on this new section using getXArtifact or dependency visitor. No real good reason to break everyone there. A not used override must break the build (it is an unexpected bug and would make the dev life hard otherwise). I perfectly see that it will break building a submodule in several cases but otherwise the section will become unmanageable with time (see hibernate or cxf example) and since you loose the dependency relationship with this option compared to exclusions, it way too much work to maintain it in practise. (This is why I think it shouldnt be done this way but very worse case at dependency level giving hints for overrides and not elsewhere, mixed with dependency managementnit is trivial to handle and maintain then). Pom rewriter must handle this section by dropping it and replacing it by exludes to keep compatibility with 3rd party resolvers (deployment). Overall, I still think it would be neat to see it as an extension for maven 3.8.2 or 4 to be testable and validate design choices and actual usage on real dependencies compared to current option. Le sam. 4 sept. 2021 à 23:21, Enno Thieleke a écrit : > Hello again, > > I tried to create a proposal in/under > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=5964567, > but I'm not allowed to, which makes sense since I'm new to the wiki, so I > committed a proposal to my fork: > https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md > > The current version probably still contains errors and misses details but > I imo they need to be worked out in a group effort. > > Some feedback/comments would be appreciated. > > Maybe you could create a proposal page in your wiki and grant me edit > rights (user eth)? > > Kind regards > Enno > > > From: Enno Thieleke > Sent: Thursday, August 26, 2021 11:59 AM > To: Maven Developers List > Subject: Re: Request for Enhancement: Dependency Overrides > > Hi Michael, > > I'll take this as a "go ahead, if it's good we'll accept it". > > Just a few more questions before I start. > > For the issue: Would reopening
[VOTE] Release Maven Resolver Ant Tasks version 1.4.0
Hi, We solved 13 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12350366 There are still a couple of issues left in JIRA: https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%20%3D%20%22Ant%20Tasks%22 Staging repo: https://repository.apache.org/content/repositories/maven-1670/ https://repository.apache.org/content/repositories/maven-1670/org/apache/maven/resolver/maven-resolver-ant-tasks/1.4.0/maven-resolver-ant-tasks-1.4.0-source-release.zip Source release checksum(s): maven-resolver-ant-tasks-1.4.0-source-release.zip sha512: 8c3fc5095a4a71fc091629d8dc928821c124890714166b6cb3caa79d9af123d22f56779312ebc0b348fc76d8d89be64163274d009c9ea4586bd3f1f72fadc5f8 Staging site: https://maven.apache.org/resolver-archives/resolver-ant-tasks-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
[GitHub] [maven-site] manuelbl opened a new pull request #275: Version requirement for versions before next major release
manuelbl opened a new pull request #275: URL: https://github.com/apache/maven-site/pull/275 In a POM, one would often like to restrict a dependency to a version before the next major release (incl. pre-releases). This does not work as most people would expect. So the proposed paragraph explains how to do it. -- 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-wrapper-plugin] rfscholte commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
rfscholte commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974682770 This commit touches 75 files, and after MWRAPPER-16 a lot of them are removed. Keep in mind that I moved it to maven-core due to the huge overlap of scripts, but that argument disappears with MWRAPPER-16. I'd suggest to start from scratch with the scripts in MWRAPPER-14, and just skip MWRAPPER-14. -- 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-wrapper-plugin] hboutemy edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
hboutemy edited a comment on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974664732 wrong logic: not merging MWRAPPER-14 (and not releasing a usable wrapper) does not help on evolving with MWRAPPER-16 please think again: scripts released as part of Maven core do not help to have consistency between wrapper scripts copied to project Git and scripts from downloaded Maven distribution = the right objective we share. It just helps on their maintenance in ASF Git (between maven.git and maven-wrapper-plugin.git), at the cost of a confusing release cycle and limitation on possible target Maven version (future Maven 4 only) but at least, I can create MWRAPPER-16 branch to be merged to MWRAPPER-14: it's just sad to not be able to work in a constructive way -- 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-wrapper-plugin] jvanzyl commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
jvanzyl commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974671779 @rfscholte are you fine with a first step of dynamically importing the scripts and implementing the more sophisticated https://issues.apache.org/jira/browse/MWRAPPER-16 later? I’d really like to shut down the Takari Wrapper repo sooner rather than later, if possible. -- 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-wrapper-plugin] hboutemy edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
hboutemy edited a comment on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974664732 wrong logic: not merging MWRAPPER-14 (and not releasing a usable wrapper) does not help on evolving with MWRAPPER-16 please think again: scripts released as part of Maven core do not help to have consistency between wrapper scripts copied to project Git and scripts from downloaded maven distribution = the right objective we share. It just helps on their maintenance in ASF Git (between maven.git and maven-wrapper-plugin.git), at the cost of a confusion release cycle and limitation on possible target Maven version (future Maven 4 only) but at least, I can create MWRAPPER-16 branch to be merged to MWRAPPER-14: it's just sad to not be able to work in a constructive way -- 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-wrapper-plugin] hboutemy edited a comment on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
hboutemy edited a comment on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974664732 wrong logic: not merging MWRAPPER-14 (and not releasing a usable wrapper) does not help on evolving with MWRAPPER-16 please think again: scripts released as part of Maven core do not help to have consistency between wrapper scripts copied to project Git and scripts from downloaded maven distribution = the right objective we share. It just helps on their maintenance in ASF Git, at the cost of a confusion release cycle and limitation on possible target Maven version (future Maven 4 only) but at least, I can create MWRAPPER-16 branch to be merged to MWRAPPER-14: it's just sad to not be able to work in a constructive way -- 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-wrapper-plugin] hboutemy commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
hboutemy commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974664732 wrong logic: not merging MWRAPPER-14 (and not releasing a usable wrapper) does not help on evolving with MWRAPPER-16 please think again: scripts released as part of Maven core do not work as a way to have consistency between wrapper scripts copied to project Git and scripts from downloaded maven distribution. It just helps a little bit their maintenance, at the cost of a confusion release cycle and limitation on possible target Maven version (future Maven 4 only) but at least, I can create MWRAPPER-16 branch to be merged to MWRAPPER-14: it's just sad to not be able to work in a constructive way -- 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] michael-o merged pull request #274: Add release notes for Maven 3.8.4
michael-o merged pull request #274: URL: https://github.com/apache/maven-site/pull/274 -- 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
[ANN] Apache Maven 3.8.4 released
The Apache Maven team is pleased to announce the release of the Apache Maven 3.8.4 Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. Maven 3.8.4 is available via https://maven.apache.org/download.cgi The core release is independent of plugin releases. Further releases of plugins will be made separately. If you have any questions, please consult: - the web site: https://maven.apache.org/ - the maven-user mailing list: https://maven.apache.org/mailing-lists.html - the reference documentation: https://maven.apache.org/ref/3.8.4/ Release Notes - Maven - Version 3.8.4 ** Bug * [MNG-7270] - Maven startup script (init) calls which(1) which is an external command * [MNG-7285] - [Regression] MavenProject.getArtifacts() not returning correct value across multiple threads * [MNG-7300] - [Regression] Reloading web application (Enter) fails due to java.lang.ClassNotFoundException ** Task * [MNG-7312] - Revert ThreadLocal approach from MNG-6843 and MNG-7251 ** Dependency upgrade * [MNG-7331] - Upgrade Jansi to 2.4.0 For more information read https://maven.apache.org/docs/3.8.4/release-notes.html Enjoy! - The 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 version 3.8.4
Hi, The vote has passed with the following result: +1: Karl Heinz Marbaise, Romain Manni-Bucau, Mickael Istria, Tamás Cservenák, Arnaud Héritier, Enrico Olivelli, Tibor Digana, Sylwester Lachiewicz, Jason van Zyl, Hervé Boutemy, Olivier Lamy, Guillaume Nodet PMC quorum: reached I will promote the artifacts to the central repo, the source release ZIP file and add this release the board report. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] [maven-wrapper-plugin] rfscholte commented on pull request #1: [MWRAPPER-14] put all wrapper pieces in one build
rfscholte commented on pull request #1: URL: https://github.com/apache/maven-wrapper-plugin/pull/1#issuecomment-974648100 it still contains the copy of the original scripts, right? Then I'm -1. -- 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
