my own quick opinion: 1. I did not review the full email thread, so is https://github.com/strohmattenverleger/maven/blob/MNG-4530/Dependency-Overrides.md still the current state of the idea?
2. can you add concrete examples, please? 3. given the impact, I fear this may be for Maven 5: we clearly need to focus on releasing Maven 4 first https://www.javaadvent.com/2021/12/from-maven-3-to-maven-5.html 4. as part of the build vs consumer pom approach, do you think a consumer pom can be generated from your build pom? Regards, Hervé Le lundi 20 décembre 2021, 21:25:39 CET Enno Thieleke a écrit : > Hello again, > > judging by the increased traffic in this mailing list some of you seem to be > on vacation. That's nice. I was hoping that this might be a good time to > ask for your opinion again about what I wrote a couple of weeks ago? > Kind regards > Enno > > ________________________________ > From: Enno Thieleke <enno.thiel...@holisticon.de> > Sent: Friday, December 3, 2021 10:54 AM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Hi, > > concerning the request to change the override XML element to a fully-fledged > dependency, thus removing the need for accompanying managed > dependencies... > tl;dr > I would add a version attribute, nothing more, to the override XML element. > The rest would remain unchanged. > Full version: > > If I turned the override XML element into a fully-fledged dependency, should > we support properties such as `scope` and `optional`? In my opinion we > shouldn't, because that's still subject to original dependency definitions, > not overrides. If people want to change the scope or add exclusions, they > should stick to dependency management. That's what it's there for. I think > it's enough to just add a version child-element to the current override XML > element. That would remove the need for accompanying managed dependencies > for just versions and in many simple cases that'd suffice, wouldn't you > agree? I think we should draw the line here between changing artifact > coordinates, a special kind of dependency management, and managing other > dependency properties -> separation of concerns. Suppose I added a version > child-element, I'd still have concerns about moving dependencyOverrides up > one level so that it would be a sibling of dependencyManagement. Imagine I > moved dependencyOverrides up one level. How would we import them properly? > Currently importing a POM imports both: managed dependencies as well as > overrides and I think that wouldn't be the right approach anymore. Would > special import XML elements do the trick? Such as this: > <dependencyManagement> > <dependencies> > <dependency> > ... > <scope>import</scope> <!-- Imports managed dependencies --> > </dependency> > </dependencies> > </dependencyManagement> > <dependencyOverrides> > <imports> > <import> <!-- Imports overrides; the packaging of the import MUST be pom > --> <groupId/> > <artifactId/> > <version/> > </import> > </imports> > ... > </dependencyOverrides> > > To be honest: I think that'd suck. Another way would be to introduce a new > special purpose scope, but I think the existing special purpose scope > "import" is perfect: it's meant to import dependency management information > from different POMs and since overrides affect dependencies in the sense > that they manage dependency coordinates, we're still talking about > dependency management. > Please let me know what you think. > > Kind regards > Enno > > ________________________________ > From: Romain Manni-Bucau <rmannibu...@gmail.com> > Sent: Monday, November 22, 2021 2:33 PM > To: Maven Developers List <dev@maven.apache.org> > Subject: Re: Request for Enhancement: Dependency Overrides > > Le lun. 22 nov. 2021 à 14:15, Enno Thieleke <enno.thiel...@holisticon.de> a > écrit : > > > > Hello, > > > > > > > > @Delany, regarding 1 and 2: If I added all the other elements of the > > dependency tag, I would have to apply dependency management anyway if > > present (and I played around with it for a bit), but I see your point. > > Maybe using the dependency tag (I'd still name it override though) is > > "good enough" for small projects/POMs. I will throw a bit of time at it > > and check for "bad" implications. > > > > > > > > Making the override tag optional to have some sort of global exclusion > > mechanism is out of scope. Let me explain: When dependency management > > comes into play (in maven-resolver), it is not designed/intended to > > suddenly have no dependency at hand to work with. The dependency node in > > the graph already exists and the only thing that's left to do is filling > > it with the right information. I would have to rewrite/change that code > > as well. I.e. the code would have to check for a dependencyOverride with > > a matching original with no override. To be honest, I personally find > > that to be confusing. An exclusion should be explicit, because it carries > > a lot of weight in my opinion. The absence of an XML element should not > > make for an exclusion. Global excludes should exist though, just in a > > different way.> > > > > > > @Romain, I disagree that not defining the version in an override could be > > a source of big issues, because it would have to be defined in dependency > > management anyway, so it's basically there. Changing the major version is > > possible, even today, simply by using dependency management. It is the > > responsibility of the developer to provide a proper override (which is > > why > > I suggested a different name, dropinReplacement, to make the intent > > clearer). Still, as stated earlier, I will see what I can do. No promises > > though. :) > > > > > > > I never said I like that but it is what it is so "it would have to be > defined in dependency management" is an assumption you cannot do and is > erroneous and I don't see us saying you can't use this override feature > and/or we break your project if you do so I guess we don't have much choice > than baking it completely and not half. > > Keep in mind dependencyManagement does not behave as dependency override > but that it solves similar issues (controlling your dependency graph for > submodules since in a single module it is not that useful and excludes are > more straight forwards) so as an user you will want to put it in the same > (root? ;)) pom to keep the maintenance easy - spreading overrides in all > poms is not easy to handle in time, this is why mgt block beats dependency > for ex in multimodule projects, I don't see why it wouldn't be the same for > overrides. > > Alternatively we can fail if we hit this case to prevent overrides in such > a case, can be okish in first versions maybe? > > > > > > > > > I agree, having 2 dependencies with the same coordinates but different > > versions is a common thing. But in a single Maven module maven-resolver > > would see to it that there's only one version on the classpath. After > > all, > > we're not talking about OSGi (thank god). It's different for multiple > > Maven modules though and you know it, so I won't elaborate. > > > > > > > Would mean you forbid overrides in packaging=pom modules, not sure it would > be that useful to do so since you would duplicate the override in all > modules. > Makes a lot of noise compared to excludes in a depMgt block form my quick > tests so guess it is not the intent ;). > > > > > > > > > And yes, overriding the classifier (and extension/type) should be > > possible > > too. And it already is, but it needs more testing, which I'm working on. > > > > > > > 👍 > > > > > > > > > Kind regards > > Enno > > > > > > > > ________________________________ > > From: Romain Manni-Bucau <rmannibu...@gmail.com> > > Sent: Monday, November 22, 2021 11:00 AM > > To: Maven Developers List <dev@maven.apache.org> > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > Hi all, > > > > > > > > I fear not defining the version is likely a source of big issues and > > worse > > than not having this feature at all since often, when you change the > > major, you change totally the dependency and the override will just not > > work. You can indeed say you must not have 2 dependencies in different > > versions but it is what it is and it is not that uncommon - in particular > > for libs (and if you want to force a single version you use dependency > > management). So if this feature is desired I fear it must include the > > version and likely manage the classifier as well to work. > > > > > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > https://www.packtpub.com/application-development/java-ee-8-high-performanc > > e > > > > > > > > > > > > > > Le lun. 22 nov. 2021 à 10:14, Delany <delany.middle...@gmail.com> a écrit > > > > : > > > > > > > > > Hi Enno, > > > > > > > > > > > > On point 1, figuring out the order of events in a build can be > > > > challenging > > > > > for newbies since Maven is declarative. For example profiles are > > > resolved > > > early on and this is reflected by their place in the pom. Although > > > that's > > > really about config composition, having the overrides under project > > > could > > > also hint at their special nature. No strong argument to make. > > > > > > > > > > > > Point 2, you say you are following a separation of concerns, but it > > > seems > > > rather you are forcing one. By requiring dependency management the > > > result > > > is a tight coupling between stages of resolving the final dependencies > > > > (not > > > > > being self-contained, you probably *should* make dependencyOverrides a > > > child of dependencyManagement). > > > Maven doesn't require managing dependencies, but your overrides do. > > > > There's > > > > > no harm in picking up config provided by DM, but why force the > > > relationship? If someone wants to add an exclude at the time of an > > > override, frankly that should just be "not your problem". Reusing an > > > existing structure is surely preferable to inventing another one? Would > > > > the > > > > > enforcer rules have to learn about your new structure? > > > I see why you went the path of only groupId:artifactId - you copied the > > > exclusion structure. But then excluding doesn't require DM. > > > > > > > > > > > > You're right about wrapping the lists. Will you at least allow not > > > > defining > > > > > a dependency at all, aka a global exclude? > > > > > > > > > > > > Delany > > > > > > > > > > > > On Sun, 21 Nov 2021 at 17:14, Enno Thieleke > > > <enno.thiel...@holisticon.de > > > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi, Delany, > > > > > > > > > > > > > > > > thanks for the feedback. > > > > > > > > > > > > > > > > I get your point that management and overrides can be seen as > > > > > > independent. > > > > > > > To be honest, I'm really not picky about where in the POM overrides > > > > > > should > > > > > > > be located. I was hoping for opinions on this from others (and was > > > > not > > > > disappointed) and at least one strong opinion from the Maven core > > > > team. > > > > > > As > > > > > > > to why I put overrides in the management section in the first place: > > > > > > simply > > > > > > > because I saw overrides as a management subject. > > > > > > > > > > > > > > > > About using the existing dependency tag to define replacements: I > > > > tried > > > > that (in a way, I still used a different tag name though). The issue > > > > I > > > > > > have > > > > > > > with it is that the dependency tag can also take version, exclusions, > > > > optional, etc. and I want that to be in the > > > > /project/dependencyManagement/dependencies section. I'm applying the > > > > separation of concerns principle here: overrides should simply map > > > > > > artifact > > > > > > > coordinates whereas managed dependencies are all about the right > > > > versions > > > > > > and such. Or maybe the managed dependencies should also provide the > > > > override information? The entire existing implementation can still be > > > > changed with little effort. > > > > > > > > > > > > > > > > I also thought about allowing 0..n overrides for one original, but I > > > > decided to make it a 1:1 mapping. Let me explain: First, I think it > > > > is > > > > currently not possible to have lists in POMs without a wrapping > > > > element. > > > > > > One would have to write: > > > > > > > > > > > > > > > > <!-- Simplified code for brevity --> > > > > <dependencyOverrides> > > > > > > > > <dependencyOverride> > > > > > > > > <original/> > > > > <dependencies> > > > > > > > > <dependency/> > > > > ... > > > > > > > > </dependencies> > > > > > > > > </dependencyOverride> > > > > > > > > </dependencyOverrides> > > > > > > > > > > > > > > > > Please correct me on this if I'm wrong. Second, I think most of the > > > > time > > > > > > people will be having 1:1 mappings anyway and with that in mind, > > > > having > > > > > > the > > > > > > > need to use lists which require a wrapping element would bloat a POM. > > > > > > > > > > > > > > > > Long story short, your first point is up for discussion. If more > > > > people > > > > want overrides located elsewhere, then that's fine by me. Regarding > > > > your > > > > > > second point, I think the current approach is good and people would > > > > have > > > > > to > > > > > > > provide strong arguments to convince me of a different approach. > > > > > > > > > > > > > > > > Again, thanks for the feedback, it's really appreciated and if you > > > > have > > > > more, please let me know. > > > > > > > > > > > > > > > > Kind regards, > > > > Enno > > > > > > > > > > > > > > > > ________________________________ > > > > From: Delany <delany.middle...@gmail.com> > > > > Sent: Sunday, November 21, 2021 4:46 AM > > > > To: Maven Developers List <dev@maven.apache.org> > > > > Subject: 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. > > > > > > > > > > > > > > > > ... > > > > <groupId>a</groupId> > > > > <artifactId>a</artifactId> > > > > <dependencyOverrides> > > > > > > > > <dependencyOverride> > > > > > > > > <original> > > > > > > > > <groupId>y</groupId> > > > > <artifactId>y</artifactId> > > > > > > > > </original> > > > > <dependency> > > > > > > > > <groupId>z</groupId> > > > > <artifactId>z</artifactId> > > > > > > > > </dependency> > > > > <dependency> > > > > > > > > <groupId>q</groupId> > > > > <artifactId>q</artifactId> > > > > > > > > </dependency> > > > > > > > > </dependencyOverride> > > > > > > > > </dependencyOverrides> > > > > <dependencies> > > > > > > > > <dependency> > > > > > > > > <groupId>w</groupId> > > > > <artifactId>w</artifactId> > > > > > > > > </dependency> > > > > <dependency> > > > > > > > > <groupId>x</groupId> > > > > <artifactId>x</artifactId> > > > > > > > > </dependency> > > > > > > > > </dependencies> > > > > ... > > > > > > > > > > > > > > > > > > > > Regards, > > > > Delany > > > > > > > > > > > > > > > > > > > > On Sun, 21 Nov 2021 at 02:05, Enno Thieleke < > > > > enno.thiel...@holisticon.de > > > > > > > > > > > > > > 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-Over > > rides.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 <rmannibu...@gmail.com> > > > > > Sent: Sunday, September 5, 2021 8:34 AM > > > > > To: Maven Developers List <dev@maven.apache.org> > > > > > 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 < > > > > > > enno.thiel...@holisticon.de > > > > > > > > > > > > > > > > > > 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-Over > > rides.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 <enno.thiel...@holisticon.de> > > > > > > Sent: Thursday, August 26, 2021 11:59 AM > > > > > > To: Maven Developers List <dev@maven.apache.org> > > > > > > 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 > > > > > > https://issues.apache.org/jira/browse/MNG-4530 suffice or would > > > > you > > > > > > like > > > > > > > > > > to see a new one? > > > > > > > > > > > > > > > > > > > > > > > > Where do I create the proposal? > > > > > > > > > > > > > > > > > > > > > > > > What should be created first, the issue or the proposal? I'm > > > > asking, > > > > > > > > because in the proposal we'd work out the details and after > > > > > > that's > > > > > > > > done, > > > > > > > > > > that's where the issue becomes relevant (no issue, no code > > > > changes). > > > > > At > > > > > > > > > least that's how I'm used to implementing changes like this. I > > > > don't > > > > > > want > > > > > > > > > > to have created unnecessary noise in your issue system, if - for > > > > some > > > > > > > > unknown eventuality - the proposal doesn't get your approval. > > > > > > > > > > > > > > > > > > > > > > > > Is it ok to use one issue for changes in both projects, Maven and > > > > > > maven-resolver? > > > > > > > > > > > > > > > > > > > > > > > > Kind regards > > > > > > Enno > > > > > > ________________________________ > > > > > > From: Michael Osipov <micha...@apache.org> > > > > > > Sent: Wednesday, August 25, 2021 9:01 PM > > > > > > To: dev@maven.apache.org <dev@maven.apache.org> > > > > > > Subject: Re: Request for Enhancement: Dependency Overrides > > > > > > > > > > > > > > > > > > > > > > > > Am 2021-08-25 um 20:51 schrieb Enno Thieleke: > > > > > > > > > > > > > Hello again, > > > > > > > > > > > > > > > > > > > > > > > > > > > > some days have passed and I didn't want to distract you people > > > > from > > > > > > > > releasing the new version of Maven, but now that it's done, I'm > > > > > > getting > > > > > > > > > back to this topic. > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm asking for the opinion of the Maven PMC and committers > > > > > > regarding > > > > > > > > > this feature. I'd like to see some sort of dependency > > > > > > > > > > override/replacement > > > > > > > > > > > mechanism. One that's powerful, yet easy to use, which doesn't > > > > > > require > > > > > > > > > boilerplate XML and which leaves the dependency graph virtually > > > > > > > > untouched > > > > > > > > > > (by that I mean the shape of the graph remains the same, unless > > > > > > > > > > additional > > > > > > > > > > > transitive dependencies are brought into play by > > > > > > > > overrides/replacements). > > > > > > > > > > > > > > > > > > > > > > > > > Please let me know what you people think of such a feature. > > > > Maybe a > > > > > > > vote > > > > > > > > > > > is in order, but I'm not sure and I wouldn't know how to call for > > > > one > > > > > > > > properly here. Please tell me how to proceed. I'm only willing to > > > > > > > > commit > > > > > > > > > > more time to this, if I have an ok from you that it'll be merged > > > > once > > > > > > it > > > > > > > > > > meets the quality standards of the Maven project. > > > > > > > > > > > > > > > > > > > > > > > > As I said previously, this perfectly makes sense, but having this > > > > in > > > > > > > > Core means that someone needs to create an issue, proposal and a > > > > PR. > > > > > > > > Consider that no one of us is getting paid on this, so free time > > > > > > only. > > > > > > > > > Unless it comes from the community, I see little chances to have > > > > this > > > > > > > soon. > > > > > > > > > > > > > > > > > > > > > > > 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
