Re: [VOTE] Release Maven Resolver 1.9.18
+1 (non-binding) Checked with upcoming Pax URL 3 based on Maven Resolver 1.9 (soon - 2.0) and MiMa 2.4 (soon 3.0?) regards Grzegorz Grzybek czw., 23 lis 2023 o 13:55 Slawomir Jaranowski napisał(a): > +1 > > śr., 22 lis 2023 o 17:17 Tamás Cservenák napisał(a): > > > Howdy, > > > > Note1: Maven Resolver 1.x lineage is in "bugfix only" maintenance mode. > > Note2: Resolver 1.9.17 release is declared "broken" by RM, release 1.9.18 > > undos the unwanted code change that happened in FileUtils@1.9.17 and > > restores source compatibility between 2.x and 1.9.x. > > > > We solved 2 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353878 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-2037 > > > > Source release SHA512: > > > > > b74842017a4a2869dbe118a69d29d9eae39df33fc6f1dd056e5440c7489694aa1e6f53705a77d7a8af7a7a48301b1a6b48577486202900de358463acc3045e82 > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > -- > Sławomir Jaranowski >
Re: [VOTE] Release Maven Resolver 1.9.15
+1 (non-binding) I'm that quick, because I've already tested it with Camel 4 and locally. regards Grzegorz Grzybek pt., 4 sie 2023 o 14:46 Tamás Cservenák napisał(a): > Howdy, > > Context: This release focuses on "third party integrations" and provides a > migration path for those who rely on deprecated `ServiceLocator`, which is > about to be dropped in the near future (planned for 2.0.0). The main focus > is on new supplier artifact: > > https://repository.apache.org/content/repositories/maven-1984/org/apache/maven/resolver/maven-resolver-supplier/1.9.15/ > > The new module is described here: > > https://maven.apache.org/resolver-archives/resolver-LATEST/third-party-integrations.html > > === > > We solved 5 issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12353445 > > There are still some issues in JIRA: > https://issues.apache.org/jira/projects/MRESOLVER/issues > > Staging repository: > https://repository.apache.org/content/repositories/maven-1984 > > Source release SHA512: > > 94567525457ce734252686f24b8c422b2808dd9ff65763b09da7a92214e1292c0b6458619cbd8a1e73047bb1e93cab3b035fcf8062725e6c37566dc6aed68994 > > Staging site: > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 >
Re: [VOTE] Release Maven Resolver 1.9.7
Hello +1 (non-binding) I've checked 1.9.7 with Camel's own DI that configures `org.eclipse.aether.RepositorySystem` using @Inject without service locator methods (like org.apache.maven.repository.internal.MavenRepositorySystemUtils.newServiceLocator()). Also following good practice, I've moved from maven-resolver-transport-wagon to maven-resolver-transport-http/file. regards Grzegorz Grzybek śr., 8 mar 2023 o 09:46 Tamás Cservenák napisał(a): > Howdy, > > We solved 4 (1 bug + 3 improvements, all transport-http related) issues: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12352980 > > There are still some issues in JIRA: > https://issues.apache.org/jira/projects/MRESOLVER/issues > > Staging repository: > https://repository.apache.org/content/repositories/maven-1883 > > Source release SHA512: > > 27c0cc47ce67d972fc98f4f2dc2555c0cf342b223ccfbd20bef76911e7b712aecaad2b36aaf16f215b96862ec9716e476a4a27f5a7698fb7ceac8df525305e98 > > Staging site: > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 >
Re: [VOTE] Release Maven Resolver 1.9.4
+1 (non-binding) Checked with Camel's org.apache.camel.main.injection.DIRegistry and its DI-based configuration of org.eclipse.aether.RepositorySystem→org.eclipse.aether.internal.impl.DefaultRepositorySystem regards Grzegorz Grzybek pt., 13 sty 2023 o 08:46 Guillaume Nodet napisał(a): > +1 > > Le ven. 13 janv. 2023 à 08:11, Tamás Cservenák a > écrit : > > > Howdy, > > > > We solved 5 issues: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.4 > > > > There are still some issues in JIRA: > > https://issues.apache.org/jira/projects/MRESOLVER/issues > > > > Staging repository: > > https://repository.apache.org/content/repositories/maven-1851 > > > > Source release SHA512: > > > > > e02988b875a55db1f1eb0976a06d7222cb1598228634735a9afdd27b827d48ae1c37629311613949f67b171bc9feb611f5cbdfe875003326144b20c1d2539ca3 > > > > Staging site: > > https://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > > -- > > Guillaume Nodet >
Re: Heads up - resolver 1.9.4 release soon
Hello I checked 1.9.4 when working on https://issues.apache.org/jira/browse/CAMEL-18880. Camel uses proper (I hope) approach to Maven Resolver, because it doesn't use org.apache.maven.repository.internal.MavenRepositorySystemUtils#newServiceLocator(). Instead correct (and narrowed to JSR330) DI is used where implementations are bound to interfaces to satisfy @Inject annotated constructors. And yes - Camel's org.apache.camel.main.injection.DIRegistry works with @jakarta.inject.Inject and @javax.inject.Inject. kind regards Grzegorz Grzybek śr., 11 sty 2023 o 08:29 Tamás Cservenák napisał(a): > Howdy, > > Soon release of resolver 1.9.4 is to happen > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.4 > > Please ping me HERE if anything is missing... > > Thanks > T >
Re: [VOTE] Release Apache Maven version 3.8.6
+1 (non-binding) tested on few projects and some extensions. regards Grzegorz Grzybek czw., 9 cze 2022 o 17:59 Sylwester Lachiewicz napisał(a): > +1 > > pon., 6 cze 2022, 19:18 użytkownik Michael Osipov > napisał: > > > Hi, > > > > We solved 16 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351556 > > > > There are still hundreds of issues left in JIRA: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1759/ > > > > Dev dist directory: > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.6/ > > > > Source release checksums: > > apache-maven-3.8.6-src.zip sha512: > > > > > cfa8b7e5f965d4da8d0e098889b98fccf3eec70ac500c452a5257ca9f8b5e75d200ba51d89c0be6e06072255b71d8a0c0f21ee3e3d4ba6152ea72007b497344a > > apache-maven-3.8.6-src.tar.gz sha512: > > > > > 03366d0d34bba79ce6f0d5e88390e360fbf2f61c273bc18885a21a6d4dcdf5eca14fe4d902735e4fcb03db32327be086e3927d259c519aa790f42142cfcb > > > > Binary release checksums: > > apache-maven-3.8.6-bin.zip sha512: > > > > > f92dbd90060c5fd422349f844ea904a0918c9c9392f3277543ce2bfb0aab941950bb4174d9b6e2ea84cd48d2940111b83ffcc2e3acf5a5b2004277105fd22be9 > > apache-maven-3.8.6-bin.tar.gz sha512: > > > > > f790857f3b1f90ae8d16281f902c689e4f136ebe584aba45e4b1fa66c80cba826d3e0e52fdd04ed44b4c66f6d3fe3584a057c26dfcac544a60b301e6d0f91c26 > > > > Draft for release notes: > > https://github.com/apache/maven-site/pull/303 > > > > > > Guide to testing staged releases: > > http://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open until 2021-06-12T12:00Z > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
Re: A Maven extension for dependency tracking
Thanks Tamas. I'm looking at https://github.com/apache/maven-resolver/pull/182 today (and apologies for delay - other tasks...). See inline. pt., 27 maj 2022 o 21:19 Tamás Cservenák napisał(a): > Howdy, inline, also PR updated, simplified, and added a "demo" listener > that does exactly what you wanted. > > On Fri, May 27, 2022 at 8:24 AM Grzegorz Grzybek > wrote: > > > Hello and thank you very much for your time ;) > > > > This looks exactly how I imagined it ;) - that the path is reachable via > > the RequestTrace! > > Doing everything in the RepositoryListener (correct me if I'm wrong, but > > artifactResolved() is called both after remote access and when the > artifact > > is found in local repo?) looks very clean, because it's natural to > register > > such listeners - much more natural than extending some crucial classes > from > > the resolver. > > > > > Yes, now you can do everything as a listener. There is a "demo" added that > does exactly what you want. > Still, the warning stands: listener "steals" time from collection, > collecting is "hot", so be quick! :) > But now we are thread-safe as well, so "parallel pom" download will work as > well. > (there is one thing I need to fix: for this safety I need to COPY the path > list, as once multithreaded, that list will change!!!) > So in ideal situation (no listener registered), the only cost would be the copy. I'll check collectStepTrace() impact by building some of my projects and I'll let you know. > > > > > > I remember you mentioned this "end graph", but I didn't find a place > (hook, > > listener) where I can get it - could you please point me to the class? > > > > I was talking about another extension point to be added, which is not > there. > But now I am unsure if it is needed or not... > ok, so no full tree, but just a path collected in RequestTrace - that's what I needed ;) > > > > > > I think artifactResolved() callback was called not only for POMs... and > all > > the changes made to the collector were supposed to prepare the dependency > > path, so I didn't see a problem here. But you're the expert ;) > > > Yes, event is called a bit more: for every artifact being resolved, that > means that is called > for POMs (when artifactDescriptorRequest is run in collector), but that one > request may trigger SEVERAL > events, like for the POM, then for it's parent POM, then for parent parent > POM etc. This is model builder, that > is building the effective POM for a given artifact, and in case it has a > parent POM, hence it needs to be resolved > as well. > And THAT was exactly the reason I wanted to track everything. Yes - I wanted parent poms, grandparent poms, parents of boms, etc... > > Hence, there is that little "trick" in place that ensures that tree is > written only once, see the demo listener. > It could be improved even more (like in the case of mvnd, where you may > have several ongoing sessions at once). > Thanks - I promise to check PR#182 this week. regards Grzegorz Grzybek > > HTH > Tamas >
Re: A Maven extension for dependency tracking
Hello and thank you very much for your time ;) wt., 24 maj 2022 o 15:54 Tamás Cservenák napisał(a): > Howdy, > > take a look at this: > https://github.com/apache/maven-resolver/pull/182 > (demos are "mutilated" just to run them and observe output, changes there > are unrelated) > This looks exactly how I imagined it ;) - that the path is reachable via the RequestTrace! Doing everything in the RepositoryListener (correct me if I'm wrong, but artifactResolved() is called both after remote access and when the artifact is found in local repo?) looks very clean, because it's natural to register such listeners - much more natural than extending some crucial classes from the resolver. > > But still, I am on edge: I still don't see why all this is "better", then > just observe the collection end graph (having all, and then just write out > reverse dep trees then?) > I remember you mentioned this "end graph", but I didn't find a place (hook, listener) where I can get it - could you please point me to the class? > > Also, this is an "early" phase, the collection, hence only POMs are being > downloaded. And the fact POM is downloaded (collected), does NOT mean JAR > will be downloaded (resolved) as well > I think artifactResolved() callback was called not only for POMs... and all the changes made to the collector were supposed to prepare the dependency path, so I didn't see a problem here. But you're the expert ;) kind regards Grzegorz Grzybek > > > Thanks > T > > On Tue, May 24, 2022 at 12:40 PM Grzegorz Grzybek > wrote: > > > wt., 24 maj 2022 o 11:17 Tamás Cservenák > napisał(a): > > > > > Howdy, > > > > > > inline only the "interesting" part: > > > > > > So, after playing a bit with 1.8.0[.1] of the BF/DF resolvers and your > > #176 > > > > PR, I see that example > > > > > > > > > > > > > > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate#dependencyCollected() > > > > extension point you've introduced is a bit too early for my use > case... > > > > It's invoked during dependency collection, but I think it'd be better > > to > > > > simply use "full path" when there's actual download (or resolution > from > > > > local repository). > > > > > > > > > > This part I don't quite get: "too early"? What do you mean here? > > > As events you use are fired "even before" as I see... > > > > > > > By "too early" I mean that your dependencyCollected() was already > printing > > the path, while in my case I was only pushing current dependency on top > of > > the stack and full stack was available later in an implementation of > > org.eclipse.aether.AbstractRepositoryListener > > > > However I didn't check if that's simply not the same - I thought that I > > could have several stack pushed before my implementation of > > org.eclipse.aether.AbstractRepositoryListener#artifactDownloaded() was > > called - but I may be wrong. > > > > > > > > > > > > > > > > > > My whole need to extend resolver was to collect the path from initial > > to > > > > final dependency, so the stack is available when it's needed. > > > > > > > > > > Isn't the PR doing that? Or did I miss something? > > > > > > > as above - I was only thinking that there's a difference between these > two: > > - your PR calls dependencyCollected() just after > node.getChildren().add() > > (DF) or context.getParent().getChildren().add() (BF) and prints the > > reversed dependency path > > - my extension pushes the dependency (DF only in resolver 1.6.3) and > > prints the path in org.eclipse.aether.RepositoryListener > > > > if these are effectively the same, sorry for confusion ;) > > > > > > > > > > > > > > > > > > Initially I thought that org.eclipse.aether.RequestTrace should be > the > > > > thing I could use to get current dependency path, but I found it's > not > > > > possible. > > > > > > > > > > Yes, my hopes were geared toward RequestTrace as well, as it could > > > represent a tree just fine, but > > > > > > > > > > > > > > Maybe your DependencyCollectorDelegate#dependencyCollected() could > > simply > > > > "expose" the List path somewhere? Maybe in Maven > > session? > > > > as attribute? &
Re: A Maven extension for dependency tracking
wt., 24 maj 2022 o 11:17 Tamás Cservenák napisał(a): > Howdy, > > inline only the "interesting" part: > > So, after playing a bit with 1.8.0[.1] of the BF/DF resolvers and your #176 > > PR, I see that example > > > > > org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate#dependencyCollected() > > extension point you've introduced is a bit too early for my use case... > > It's invoked during dependency collection, but I think it'd be better to > > simply use "full path" when there's actual download (or resolution from > > local repository). > > > > This part I don't quite get: "too early"? What do you mean here? > As events you use are fired "even before" as I see... > By "too early" I mean that your dependencyCollected() was already printing the path, while in my case I was only pushing current dependency on top of the stack and full stack was available later in an implementation of org.eclipse.aether.AbstractRepositoryListener However I didn't check if that's simply not the same - I thought that I could have several stack pushed before my implementation of org.eclipse.aether.AbstractRepositoryListener#artifactDownloaded() was called - but I may be wrong. > > > > > > My whole need to extend resolver was to collect the path from initial to > > final dependency, so the stack is available when it's needed. > > > > Isn't the PR doing that? Or did I miss something? > as above - I was only thinking that there's a difference between these two: - your PR calls dependencyCollected() just after node.getChildren().add() (DF) or context.getParent().getChildren().add() (BF) and prints the reversed dependency path - my extension pushes the dependency (DF only in resolver 1.6.3) and prints the path in org.eclipse.aether.RepositoryListener if these are effectively the same, sorry for confusion ;) > > > > > > Initially I thought that org.eclipse.aether.RequestTrace should be the > > thing I could use to get current dependency path, but I found it's not > > possible. > > > > Yes, my hopes were geared toward RequestTrace as well, as it could > represent a tree just fine, but > > > > > > Maybe your DependencyCollectorDelegate#dependencyCollected() could simply > > "expose" the List path somewhere? Maybe in Maven session? > > as attribute? > > > > In a moment parallel collection comes into picture ( > https://github.com/apache/maven-resolver/pull/178) > this will be not enough, as there is one session but multiple threads are > working on it. Hence, > I agree that "hooking" onto existing events would be the best, but, sadly > they are quite disconnected > from collectors, hence, it is hard to "couple" them in the right manner > > Cleanest would be if the event would carry its own copy of path > Yeah... org.eclipse.aether.RepositoryEvent is very "public", so finding a path there would be great. However² I print most of the tracking information not in org.eclipse.aether.RepositoryListener but in overriden org.eclipse.aether.repository.LocalRepositoryManager#find() (because I wanted to know ALL the traces back to the ultimate origin of the dependency - even if it's already downloaded. And org.eclipse.aether.RepositoryEvent can't help here - that's why I needed the static stack... I think that indeed - #176 is something that could be both useful and cheap (defaults to empty method), dependencyCollected() could be invoked with (as in your PR): - context.parents (BF) - args.nodes.nodes (DF) This way my extension would be DF/BF independent and also it could ignore parallel/serial downloader. regards Grzegorz Grzybek > > > Thanks > T >
Re: A Maven extension for dependency tracking
Hello I've finally found some time to check your PR#176 Tamás... Here are my comments and answers (also to previous messages). https://github.com/apache/maven-resolver/pull/176 > > So here is some implementation "demo" (that could be made into extension > point), as explained in Draft PR description. > BUT, also as written in PR, am getting a feeling that doing this is > "dangerous", and a simple callback with whole collected graph would be > better > I've built Maven 3.8.5.1 (special local version) with maven-resolver 1.8.0.1 (special local version) with PR#176 included. I was easily able to switch between DF and BF collectors (-Daether.collector.impl) and I could find the "path" to "top" (or "current") dependency: - BF: org.eclipse.aether.internal.impl.collect.bf.DependencyProcessingContext#parents - DF: org.eclipse.aether.internal.impl.collect.df.NodeStack#nodes - 1st: Personally, from a Resolver perspective, I'd just provide an API > (basically the author extending resolver should implement) and make it > simple to "click in" (Sisu component discovery). > - 2nd: resolver IMHO should not provide any out of the box component > implementation at all > I agree - there should be no additional processing without an explicit extension (custom Sisu/Plexus component) So 1st would provide a "stable" extension point for users who would like to > "integrate" with resolver at this point (like you did), but it could become > possible using simply this new API, instead the hoops and loops your code > was forced to do (as resolver is quite "closed" in this respect). > Indeed - I had to shade several resolver classes simply to make them public (with protected methods). With DF/BF resolvers, it'd be even more important to have some clear contract. As for 2nd point, while I do like your idea of "decorating" local > repository, I'd try a bit different route: I'd integrate this > https://github.com/lambdazen/bitsy that makes possible to use Apache > Tinkerpop's Gremlin queries to ask about the built graph for example... > At first glance, it looks like an overkill ;) But I didn't check enough probably... So, after playing a bit with 1.8.0[.1] of the BF/DF resolvers and your #176 PR, I see that example org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate#dependencyCollected() extension point you've introduced is a bit too early for my use case... It's invoked during dependency collection, but I think it'd be better to simply use "full path" when there's actual download (or resolution from local repository). My whole need to extend resolver was to collect the path from initial to final dependency, so the stack is available when it's needed. Initially I thought that org.eclipse.aether.RequestTrace should be the thing I could use to get current dependency path, but I found it's not possible. Maybe your DependencyCollectorDelegate#dependencyCollected() could simply "expose" the List path somewhere? Maybe in Maven session? as attribute? kind regards Grzegorz Grzybek śr., 11 maj 2022 o 18:40 Tamás Cservenák napisał(a): > Howdy, > > https://github.com/apache/maven-resolver/pull/176 > > So here is some implementation "demo" (that could be made into extension > point), as explained in Draft PR description. > BUT, also as written in PR, am getting a feeling that doing this is > "dangerous", and a simple callback with whole collected graph would be > better > > > WDYT? > > Tamas > > On Mon, May 2, 2022 at 4:18 PM Tamás Cservenák > wrote: > > > Howdy, > > > > just a few short answers: > > - 1st: Personally, from a Resolver perspective, I'd just provide an API > > (basically the author extending resolver should implement) and make it > > simple to "click in" (Sisu component discovery). > > - 2nd: resolver IMHO should not provide any out of the box component > > implementation at all > > > > So 1st would provide a "stable" extension point for users who would like > > to "integrate" with resolver at this point (like you did), but it could > > become possible using simply this new API, instead the hoops and loops > your > > code was forced to do (as resolver is quite "closed" in this respect). > > > > As for 2nd point, while I do like your idea of "decorating" local > > repository, I'd try a bit different route: I'd integrate this > > https://github.com/lambdazen/bitsy that makes possible to use Apache > > Tinkerpop's Gremlin queries to ask about the built graph for example... > > > > And one big remark: the collector is the "hottest point" in resolver > (heap
Re: A Maven extension for dependency tracking
Hello! Thanks for your comments and PR - I needed to switch to different tasks, but soon (next week?) I'm going to spend more time on it. I yet have to get a feeling of the graph/stack that could be passed around. And check these DF/BF dependency collectors (as I didn't see them in resolver 1.6.3). I'll keep the https://issues.apache.org/jira/browse/MRESOLVER-248 tab open till I check it ;) kind regards Grzegorz Grzybek śr., 11 maj 2022 o 18:40 Tamás Cservenák napisał(a): > Howdy, > > https://github.com/apache/maven-resolver/pull/176 > > So here is some implementation "demo" (that could be made into extension > point), as explained in Draft PR description. > BUT, also as written in PR, am getting a feeling that doing this is > "dangerous", and a simple callback with whole collected graph would be > better > > > WDYT? > > Tamas > > On Mon, May 2, 2022 at 4:18 PM Tamás Cservenák > wrote: > > > Howdy, > > > > just a few short answers: > > - 1st: Personally, from a Resolver perspective, I'd just provide an API > > (basically the author extending resolver should implement) and make it > > simple to "click in" (Sisu component discovery). > > - 2nd: resolver IMHO should not provide any out of the box component > > implementation at all > > > > So 1st would provide a "stable" extension point for users who would like > > to "integrate" with resolver at this point (like you did), but it could > > become possible using simply this new API, instead the hoops and loops > your > > code was forced to do (as resolver is quite "closed" in this respect). > > > > As for 2nd point, while I do like your idea of "decorating" local > > repository, I'd try a bit different route: I'd integrate this > > https://github.com/lambdazen/bitsy that makes possible to use Apache > > Tinkerpop's Gremlin queries to ask about the built graph for example... > > > > And one big remark: the collector is the "hottest point" in resolver > (heap > > and cpu wise), so ANY "new API" implementation should be aware, that each > > "lost" millisecond directly affects resolver collection speed, but I > think > > for "research kind" of stuff, of just "recording the process result" > should > > fit in just fine. I don't see this as a "standard" feature of Maven, but > > who knows? :) > > > > Just my 5 cents... > > > > HTH > > Tamas > > > > On Mon, May 2, 2022 at 4:09 PM Grzegorz Grzybek > > wrote: > > > >> Thank you Tamás for checking my experiment > >> > >> I'm just finishing my work before tomorrow's national holiday, but will > >> read your information more carefully soon. > >> > >> Whether it's DFS or BFS, as long as there's tracking from initial to > >> ultimate dependency, it's enough. DFS sounds more "natural" here > though. I > >> didn't check the CollectResult class yet - is it created per dependency > or > >> for the entire project? > >> > >> And yes - I didn't check multithreading, as in normal scenario (just > `mvn > >> clean install`) I didn't observe concurrency issues accessing the stack. > >> Mind that I know a bit about maven "components", but there are > definitely > >> few missing things in my understanding. > >> > >> Checking your output, I see there are two aspects of this potential > >> enhancement to the resolver: > >> - 1st - how to effectively collect the "reverse dependency tree" in > >> context of DFS/BFS/multithreading > >> - 2nd - how to write the information > >> > >> 2nd aspect could include: > >> - whether there should be ".tracking" for each GAV directory in local > >> repo > >> (tracking for the purpose of entire local repository) > >> - maybe there should be configurable output location for single report > of > >> a build? (tracking for the purpose of single project) > >> - which format to use (human consumable or machine readable?) > >> > >> For now I've used resolver 1.6.3 from Maven 3.8.5, but I'll look at > `main` > >> branch too. > >> > >> kind regards > >> Grzegorz Grzybek > >> > >> > >> pon., 2 maj 2022 o 15:57 Tamás Cservenák > >> napisał(a): > >> > >> > What I missed to mention: in my case the trees in the gist are about > >> > "resolving maven-core 3.5.8", but I gue
Re: A Maven extension for dependency tracking
Thank you Tamás for checking my experiment I'm just finishing my work before tomorrow's national holiday, but will read your information more carefully soon. Whether it's DFS or BFS, as long as there's tracking from initial to ultimate dependency, it's enough. DFS sounds more "natural" here though. I didn't check the CollectResult class yet - is it created per dependency or for the entire project? And yes - I didn't check multithreading, as in normal scenario (just `mvn clean install`) I didn't observe concurrency issues accessing the stack. Mind that I know a bit about maven "components", but there are definitely few missing things in my understanding. Checking your output, I see there are two aspects of this potential enhancement to the resolver: - 1st - how to effectively collect the "reverse dependency tree" in context of DFS/BFS/multithreading - 2nd - how to write the information 2nd aspect could include: - whether there should be ".tracking" for each GAV directory in local repo (tracking for the purpose of entire local repository) - maybe there should be configurable output location for single report of a build? (tracking for the purpose of single project) - which format to use (human consumable or machine readable?) For now I've used resolver 1.6.3 from Maven 3.8.5, but I'll look at `main` branch too. kind regards Grzegorz Grzybek pon., 2 maj 2022 o 15:57 Tamás Cservenák napisał(a): > What I missed to mention: in my case the trees in the gist are about > "resolving maven-core 3.5.8", but I guess you figured it out from the > tree > > T > > On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I did some experiment, that (partially re-using your code to dump the rev > > tree) produces this output: > > https://gist.github.com/cstamas/598a3266f943984442c00df30520294f > > > > (note: 1.8.0 resolver has two collector implementations: original > > Depth-First and new Breadth-First called DF and BF respectively) > > > > The code is not pushed yet anywhere, but I plan to make an API for this, > > and as you can see, it works > > for both implementations of collectors. Also, I hook ONLY into collector, > > as that's the place where the graph > > is being built, but this is logically equivalent to your "More > interesting > > ... 2nd case". > > > > Will ping once again when I have the changes > > > > Thanks > > Tamas > > > > On Thu, Apr 28, 2022 at 9:01 PM Tamás Cservenák > > wrote: > > > >> Howdy, > >> > >> This is very cool, I was actually tinkering on very similar issues in > >> resolver coming from totally different angles. > >> > >> And yes, the resolver collector is not quite "extension" friendly, but > we > >> will make it right. > >> Just FYI, that in the latest resolver (1.8.0) there are actually two > >> implementations: depth-first (original) and depth-first. > >> > >> By looking at your code: collection is most critical regarding > >> performance and memory in the resolver, so "hooking" into it (like > sending > >> events per each step) might not be the best, but still, what kind of > >> extension points would you envision in the collector? > >> > >> For example, to achieve what you want, it would be completely enough to > >> receive the final CollectResult (the full graph), no? > >> As -- from a resolver perspective -- that would be simplest, especially > >> that now we have two collector implementations... > >> > >> Also, in case of multi threading, your shared stack would not cut, would > >> it? > >> > >> I personally was also looking into these, especially after some of the > >> latest additions to resolver in 1.8.0 and current master > >> > >> > >> Thanks > >> T > >> > >> > >> On Thu, Apr 28, 2022 at 12:45 PM Grzegorz Grzybek > > >> wrote: > >> > >>> Hello > >>> > >>> TL;DR: https://github.com/grgrzybek/tracking-maven-extension > >>> > >>> I'd like to share some proof of concept I made. It all started with a > >>> question "why I'm getting log4j:log4j:1.2.12" in my local Maven > >>> repository > >>> when building trivial project with fresh local repo? > >>> > >>> I knew it's possible to `grep -r --include=*.pom 1.2.12` the poms that > >>> declare old log4j, but I needed something better. > >>> > >>> In short words -
A Maven extension for dependency tracking
ava:guava:pom:10.0.1 -> org.eclipse.sisu:org.eclipse.sisu.plexus:jar:0.0.0.M5 (compile) (context: plugin) -> org.apache.maven:maven-plugin-api:jar:3.1.1 (compile) (context: plugin) -> org.apache.maven:maven-core:jar:3.1.1 (compile) (context: plugin) -> org.apache.maven.shared:maven-common-artifact-filters:jar:3.2.0 (runtime) (context: plugin) -> org.springframework.boot:spring-boot-maven-plugin:jar:2.5.12 () (context: plugin) yes - Spring Boot 2.5.12... Why Log4j 2.10.0? org.apache.logging.log4j:log4j-api:pom:2.10.0 -> org.apache.logging.log4j:log4j-to-slf4j:jar:2.10.0 (compile) (context: project) -> org.springframework.boot:spring-boot-starter-logging:jar:2.0.5.RELEASE (compile) (context: project) -> org.springframework.boot:spring-boot-starter:jar:2.0.5.RELEASE (compile) (context: project) -> org.springframework.boot:spring-boot-starter-web:jar:2.0.5.RELEASE (compile) (context: project) -> org.keycloak:keycloak-spring-boot-2-adapter:jar:17.0.1 (context: project) (see - this time the context is "project", not "plugin"). And so on and so on. What is my motivation with this email? I don't know yet - ideally I'd like to have this ".tracking" information created together with "_remote.repositories" and "*.lastUpdated" metadata by Maven Resolver. It could be optional of course (the overhead is really minimal - 1 more minute when building Camel 3 - 1 hour instead of 59 minutes). The only problem I had is that I had to fork/shade org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector class because I had to manipulate org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.Args#nodes stack around the call to org.jboss.fuse.mvnplugins.tracker.TrackingDependencyCollector#processDependency(). Besides this, normal plexus/sisu components are used. The repository is https://github.com/grgrzybek/tracking-maven-extension and I'd be happy to see some comments about this ;) kind regards Grzegorz Grzybek
Re: Welcome Guillaume Nodet as new Maven Committer
Congratulations Guillaume! Maven Force be with you! regards Grzegorz Grzybek śr., 26 maj 2021 o 09:44 Arnaud Héritier napisał(a): > Welcome Guillaume !! > Happy to see you here. > > Cheers > > On Tue, May 25, 2021 at 7:19 PM Robert Scholte > wrote: > > > Hi, > > > > On behalf of the Apache Maven PMC I am pleased to announce that > > Guillaume Nodet has been voted in as new Apache Maven committer > > and he has accepted this invitation. > > > > Welcome on board and have a lot of fun! > > > > Thanks, > > Robert Scholte > > > > > -- > Arnaud Héritier > Twitter/Skype : aheritier >
Re: [VOTE] Release Apache Maven Version 3.6.2
+1 (non-binding) I did several OSGi project builds and it looks ok. kind regards Grzegorz Grzybek pt., 30 sie 2019 o 14:24 Gabriel Belingueres napisał(a): > +1 > > Kind regards. > Gabriel > > > El mié., 28 de ago. de 2019 a la(s) 16:18, Enrico Olivelli ( > eolive...@gmail.com) escribió: > > > Hi, > > > > We have solved 52 issues: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12345234 > > > > There are issues left in JIRA for Maven core: > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1529 > > > > The distributable binaries and sources can be found here: > > > > > https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/ > > > > Specifically the zip, tarball and source archives can be found here: > > > > > > > https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.zip > > > > > https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-bin.tar.gz > > > > > > > https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.zip > > > > > https://repository.apache.org/content/repositories/maven-1529/org/apache/maven/apache-maven/3.6.2/apache-maven-3.6.2-src.tar.gz > > > > The release artifacts are staged for distribution in: > > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.6.2 > > > > Source release checksum(s): > > apache-maven-3.6.2-src.tar.gz > > > >sha1: 373ffbe9fc88e5facbe10d7a6f6badd243545ade > > sha512: > > > > > 235198b48d29fe2f2394f2607a9a1637acfd0286beacb974c566f7f36ac6c469871a0db287539b2b62e6322d7423f586949e41cbbfea330fe03bf690688f6fd7 > > > > apache-maven-3.6.2-src.zip: > > > >sha1: c6c5bd9828b3350905e97177978724eed0698de3 > > sha512: > > > > > d7fdafbc16bd547bc3c2513255df375c2a616b04d414c2ffd7d9deb9931fab5db4c7ac912cc4bb0d96d0a083560b3cc1848ea9eecc3aeb4e4c5184329a7ead5b > > > > Git tag: > > > > > https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=40f52333136460af0dc0d7232c0dc0bcf0d9e117 > > > > Staging site: > > https://maven.apache.org/components/ref/3-LATEST/ > > > > Vote open for 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > Kind regards > > Enrico Olivelli > > >
Re: [VOTE] Release Apache Maven Resolver version 1.3.2
+1 (not binding) regards Grzegorz Grzybek pt., 1 mar 2019 o 10:39 Karl Heinz Marbaise napisał(a): > Hi, > > +1 from me. > > Kind regards > Karl Heinz Marbaise > On 23.02.19 17:20, Karl Heinz Marbaise wrote: > > Hi to all, > > > > We solved 3 issues: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628=12344318 > > > > > > 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%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC > > > > > > Staging repo: > > https://repository.apache.org/content/repositories/maven-1488 > > > > > https://repository.apache.org/content/repositories/maven-1488/org/apache/maven/resolver/maven-resolver/1.3.2/maven-resolver-1.3.2-source-release.zip > > > > > > Source release checksum(s): > > maven-resolver-1.3.2-source-release.zip sha1: > > 44c0b4f5c97cabe790ef27b7e74fadf554d6506a > > > > maven-resolver-1.3.2-source-release.zip sha512: > > > 4a795e63c896e75bb6cfd1aab276a4ab8099be42b2e6091c58df9f5a992e045c263231350ac0218d64954937cbd9691c2a880992e36c52d3378f30e29914a582 > > > > > > > Staging site: > > http://maven.apache.org/resolver-archives/resolver-LATEST/ > > > > Guide to testing staged releases: > > https://maven.apache.org/guides/development/guide-testing-releases.html > > > > Vote open for at least 72 hours. > > > > [ ] +1 > > [ ] +0 > > [ ] -1 > > > > Kind regards > > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven 3.5.3
+1 (non-binding) Testing for ~week with huge OSGi projects. best regards Grzegorz Grzybek 2018-02-28 23:03 GMT+01:00 Robert Scholte <rfscho...@apache.org>: > +1 > > > On Sat, 24 Feb 2018 23:00:28 +0100, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > Hi, >> >> We solved 22 issues: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?versi >> on=12341428=Text=12316922 >> >> There are 381 issues left in JIRA for Maven core: >> https://issues.apache.org/jira/issues/?jql=project%20%3D% >> 20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY% >> 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC >> >> Staging repo: >> https://repository.apache.org/content/repositories/maven-1401/ >> >> The distributable binaries and sources can be found here: >> https://repository.apache.org/content/repositories/maven-140 >> 1/org/apache/maven/apache-maven/3.5.3/ >> >> Specifically the zip, tarball and source archives can be found here: >> https://repository.apache.org/content/repositories/maven-140 >> 1/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-bin.zip >> https://repository.apache.org/content/repositories/maven-140 >> 1/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-bin.tar.gz >> https://repository.apache.org/content/repositories/maven-140 >> 1/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-src.zip >> https://repository.apache.org/content/repositories/maven-140 >> 1/org/apache/maven/apache-maven/3.5.3/apache-maven-3.5.3-src.tar.gz >> >> The release artifacts are staged for distribution in: >> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.3 >> >> Source release checksum(s): >> apache-maven-3.5.3-src.tar.gz sha1: >> 60905d8b8b025b091f456ec25ad60dda56c26ad5 >> sha256: 471748340cdc7f78b0b0c7bdf9e5399738e6721c08e166f59ef400f1dd107e19 >> apache-maven-3.5.3-src.zip: sha1: a9be51d571165261dfb2e0c8ecc6b4 >> f1c4c96766 >> sha256: 109ac07fa337e582b8e6741f179e9f09166cae0fc9b3f44d4a35a2a2c7ccbd57 >> >> Git tag: >> https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit >> ;h=3383c37e1f9e9b3bc3df5050c29c8aff9f295297 >> >> Staging site: >> https://maven.apache.org/components/ref/3-LATEST/ >> >> Vote open for 72 hours. >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Thanks, >> >> Stephen. >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven 3.5.1
Hello +1 (non-binding) - tested Fuse/Karaf/OSGi projects regards Grzegorz Grzybek 2017-09-13 8:00 GMT+02:00 Thomas Collignon <tomiphon...@gmail.com>: > Hello > > +1 for me > > 2017-09-12 20:54 GMT+02:00 Stephen Connolly <stephen.alan.connolly@gmail. > com > >: > > > Have we got any feedback from the embedder integrations yet? > > > > On Mon 11 Sep 2017 at 22:57, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: > > > > > just for the records: it is Windows + Git Bash (MINGW64) only > > > > > > and there is a chance that adding -Djansi.force=true can force JAnsi > > > activation (even if JAnsi fails to detect that it should auto-activate) > > > > > > details on issue in https://issues.apache.org/jira/browse/MNG-6282 , > > and a > > > future JAnsi issue... > > > > > > Regards, > > > > > > Hervé > > > > > > Le lundi 11 septembre 2017, 12:53:46 CEST Stephen Connolly a écrit : > > > > So that is windows only, or were they lost on other OSes for you. > > > > > > > > I have colours on linux (via docker) and os-x > > > > > > > > On 11 September 2017 at 12:35, dejan2...@gmail.com < > > dejan2...@gmail.com> > > > > > > > > wrote: > > > > > +1 (conditionally). > > > > > > > > > > Tested via project that includes dozen of plugins: 1st tier, > MojoHaus > > > and > > > > > few 3rd party plugins (so to say). > > > > > > > > > > Everything looks good with one notable regression: > > > > > https://issues.apache.org/jira/browse/MNG-6282 Console output has > no > > > > > colors (regression in Maven 3.5.1) > > > > > > > > > > Regards, > > > > > Dejan > > > > > > > > > > On 2017-09-10 17:39, Stephen Connolly <stephen.alan.connolly@gmail. > > com > > > > > > > > > > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > We solved 25 issues: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa? > > > > > > > > > > version=12338964=Text=12316922 > > > > > > > > > > > There are 350 issues left in JIRA for Maven core: > > > > > > https://issues.apache.org/jira/issues/?jql=project%20% > > > > > > > > > > 3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER% > > > > > 20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC > > > > > > > > > > > Staging repo: > > > > > > https://repository.apache.org/content/repositories/maven-1364/ > > > > > > > > > > > > The distributable binaries and sources can be found here: > > > > > > https://repository.apache.org/content/repositories/maven-> > > > > > > 1364/org/apache/maven/apache-maven/3.5.1/ > > > > > > > > > > > Specifically the zip, tarball and source archives can be found > > here: > > > > > > https://repository.apache.org/content/repositories/maven-> > > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5. > 1-bin.zip > > > > > > > > > > > https://repository.apache.org/content/repositories/maven-> > > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5. > > 1-bin.tar.gz > > > > > > > > > > > https://repository.apache.org/content/repositories/maven-> > > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5. > 1-src.zip > > > > > > > > > > > https://repository.apache.org/content/repositories/maven-> > > > > > > 1364/org/apache/maven/apache-maven/3.5.1/apache-maven-3.5. > > 1-src.tar.gz > > > > > > > > > > > Source release checksum(s): > > > > > > apache-maven-3.5.1-src.tar.gz sha1: > 9eb821f153c7667194aa11ccd099b7 > > > > > > > > > > bd2059560d > > > > > > > > > > > apache-maven-3.5.1-src.zip: sha1: 121d54b045380a8a4895eb137970ab > > > > > > > > > > 69e698eb0e > > > > > > > > > > > Git tag: > > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h= > > > > > > > > > > 094e4e31a5af55bb17be87675da41d9aeca062f3 > > > > > > > > > > > Staging site: > > > > > > https://maven.apache.org/components/ref/3-LATEST/ > > > > > > > > > > > > Vote open for 72 hours. > > > > > > > > > > > > [ ] +1 > > > > > > [ ] +0 > > > > > > [ ] -1 > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Stephen. > > > > > > > > > > > > - > > > > > 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 > > > > > > -- > > Sent from my phone > > >
Re: [VOTE] Release Apache Maven Assembly Plugin version 3.1.0
Hello I checked with JBoss Fuse and Fabric8 v1. +1 (non-binding) regards Grzegorz Grzybek 2017-08-13 14:18 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>: > Hi, > > We solved 10 issues: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje > ctId=12317220=12338667 > > There are still a couple of issues left in JIRA: > https://issues.apache.org/jira/issues/?jql=project%20%3D% > 20MASSEMBLY%20AND%20resolution%20%3D%20Unresolved%20ORDER% > 20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC > > Staging repo: > https://repository.apache.org/content/repositories/maven-1354 > > https://repository.apache.org/content/repositories/maven-135 > 4/org/apache/maven/plugins/maven-assembly-plugin/3.1.0/maven > -assembly-plugin-3.1.0-source-release.zip > > Source release checksum(s): > maven-assembly-plugin-3.1.0-source-release.zip sha1: > 9d42c075686b216590c438f329f86e2833c0ff6c > > Staging site: > https://maven.apache.org/plugins-archives/maven-assembly-plugin-LATEST/ > > Guide to testing staged releases: > https://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for at least 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > Kind regards > Karl Heinz Marbaise > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven 3.5.0
+1 (non-binding) Tested with huge OSGi projects without problems regards Grzegorz Grzybek 2017-04-04 11:52 GMT+02:00 dejan2609 <dejan2...@gmail.com>: > *+1* (non binding). > > Tested Maven 3.5.0 on a large project with a bunch of plugins: all is > green. > > > > -- > View this message in context: http://maven.40175.n5.nabble. > com/VOTE-Release-Apache-Maven-3-5-0-tp5904383p5904485.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: [VOTE] Release Apache Maven 3.5.0-alpha-1
Hello I'm not sure if I can give any vote (even non-binding +1), but I tested several large OSGi projects using 3.5.0-alpha-1 without problems. regards Grzegorz Grzybek 2017-02-23 23:44 GMT+01:00 Stephen Connolly <stephen.alan.conno...@gmail.com>: > This is only an alpha, I'm not calling a halt unless it is S1/S2, alpha-2 > can follow next week > > On 23 February 2017 at 21:56, Christian Schulte <c...@schulte.it> wrote: > >> Can we have this patch included? I wanted to commit this to master >> yesterday when the build job succeeded. This is just pending the Jenkins >> update to get the job succeed. I would just merge it to master now. >> >> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a= >> shortlog;h=refs/heads/MNG-5889> >> >> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commitdiff;h= >> 37b5f27080006883613800127d70e8233210555e> >> >> So that we do not need to re-open MNG-5889 or even create a new issue. >> Otherwise >> >> +1 >> >> No objections to get a release out. >> >> Regards, >> -- >> Christian >> >> >> - >> 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
