laeubi commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1066554536
> Well, I'd like to be sure about that. All the use cases I've seen so far rather indicate extensions are global to the build. Which ones? Just for the sake of leaving the field of theoretical discussions I have created an [practical example](https://github.com/laeubi/mvn-ext-example) that demonstrate that this is not the case, this contains: - an `aggregator` pom that includes two modules (`with-tycho-ext` and `without-tycho-ext`) - `with-tycho-ext` uses a custom packaging type of of the tycho-maven-plugin and declares the tycho extension - `without-tycho-ext` uses a custom packaging type of of the tycho-maven-plugin and but does **not** declare the tycho extension There are three combinations one can build those (as demonstrated [here](https://github.com/laeubi/mvn-ext-example/actions/runs/1979489071)): 1. You build `with-tycho-ext` what succeeds (as extension is active) 2. You build `without-tycho-ext` what fails (as extension is not active) 3. You build the `aggregator` what fails as one of its projects is not configured with the tycho extension This clearly demonstrate that extensions are **not** global to the build, and I can't imagine that "most users" would expect that the `aggregator` should magically work just because just because in one unrelated aggregated projects an extension is active. The same applies to the caching extension as well, if I enable it for a *one* project in an aggregator I do not expect it to be active for *all*. > Also given, they were currently mostly global (i.e. the extensions classloader is set until another project also define extensions), I'd rather assume users expects them to be global. I don't think users expect that we are leaking any item from one project to another if not explicitly decalred. > I'd rather go for a behavior than suits most use cases so far (lifecycle, workspace readers, wagon providers, build cache), rather than changing the behavior and have to rely on specific hacks for each kind of extension, it kinda defeat the purpose. As mentioned before it depends on the case and there are fundamental difference in a caller of an extension decides that all project lifecycle listeners should be called, versus all project lifecycle are globally available (What they are not! You can't look them all up in a Mojo even though all are called in the setup phase). Funny enough you have proven by your change that this instantly causes dreaded CCE: > Caused by: java.lang.ClassCastException: org.sonatype.plexus.components.cipher.DefaultPlexusCipher cannot be cast to org.sonatype.plexus.components.cipher.PlexusCipher in integration tests, and just as of today I'm again facing a similar issue [here](https://ci.eclipse.org/docs/job/gerrit-mylyn-docs/1899/console) for Tycho plugin, so I still think that classloader separation is more important than any vague user assumption. But I don't see how we can proceed here, as a matter of fact neither lifecycle, workspace readers nor wagon providers seem to have any issue with that but only cache-extension and now you try to propose that all of those are actually wrong and cache-extension is the one to rule that out... -- 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
