gnodet commented on pull request #690: URL: https://github.com/apache/maven/pull/690#issuecomment-1065909731
> I'm not sure if I can give more input on this, but only quote this > > > it really depends on the use case > > `WorkspaceReader` and `AbstractMavenLifecycleParticipant` are special because they are a mean of bootstrap and/or add additional look-ups on a global level, but at the same time they are very limited and require special care, e.g. as noted above depending on how an `AbstractMavenLifecycleParticipant` is provided not all methods are called and `WorkspaceReader` for example has no access to any project or session context. Anyways I don't think one could assume that one _always_ wan't to lookup everything from all project extensions, similar to when I define a mirror in a pom.xml I for sure don't want it to be used in other (unrelated) modules just because they are part of the same reactor, if I want this then I define it on the settings.xml ... 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. The primary use case was for wagon providers afaik and those are global. 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'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. Do you have any actual use case of build extensions that should have a limited scope (which again, is not how they were working)... ? > > So for your case, if you really thing your extension should be defined on the project level, then for me it makes totally sense that this is only available in the projects where it is defined (either explicit or implicit e.g. though parent reference) and then your extension would not be looked up globally. If you want ti to act globally independent of defined in a project and you want to have much more control I think it should be a core-extension even if others not so involved in the details think "it might be useful" to define it on the project level. > > @michael-o maybe you want to take over here or suggest others more familiar with how maven is supposed to work here. -- 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
