laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1064275379
> I've added a commit to revert [e327be3](https://github.com/apache/maven/commit/e327be3d85918a23a5ba48d752143a6dbf8b83f7) because it's useless. It is not useless but prevents a classloader leak as you have proven. > This restores the behavior from 3.8.4 when extensions are defined in the root pom From the code it is completely irrelevant where you define your extension as long as you only define exactly **one** and this is simply a wrong assumption. > I'm willing to write an IT I don't think it is good to make such behavior part of the covered assumptions. Whether or not an extension is defined in the root or not should be completely opaque and all code that works with extensions seems to not assume that but that project defined defined extensions are project scoped (taken the usual merging rules into account). > but I can't write until we agree on the behavior... I think instead of reverting / restoring wrong behavior it would be much more profitable to find out whats the root cause for this. For example a stack trace where a CNF exception is triggered and maybe then we see that there is actually a `attatchToThread` is missing somewhere else (or we have other classloader leaks that are revealed by the fixed behavior). > Such use cases are clearly not well covered, especially inheritance between parent/child projects, ordering, concurrency, etc... Just from reading the code and debugging the maven internals, a session-scoped component was never meant to be provided by a project-scoped extension and that it worked was just a side-effect but I could be wrong. At laest the Maven-CLI has distinct Classlaodersetups on the cases where a project scoped extension has to be accessed. -- 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: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
