Vampire commented on issue #11442: URL: https://github.com/apache/maven/issues/11442#issuecomment-3536506135
> These tools can continue doing this, but they should switch to build pom then. But the build pom will not be published, will it? And even if it is, the tools at least have to be adapted to support both styles in parallel and also to recognize the cases. Of course it can be reprogrammed and humans can also look into two places for the information. But imho it is important information for the consumer of a module which dependencies it expects to be present at runtime. You might of course disagree and close this issue. I just wanted to have it thought and talked about, because I think it is important information and also will "break" existing tooling, and in a way that is silent, some of those checks will just be happy in the future as there are no provided dependencies listed anymore. > Consumer pom is being transformed on purpose. Otherwise maven cannot progress, with the model set in stone. Of course, no doubt about it, I did not question that. > @Vampire , Have you considered going with Gradle Module Metadata instead of provided scope? > You could generate and publish the metadata even if you use Maven, you could add whatever info you need, and it would likely have a better API than the obscure provided. I can also put the information in a text file and publish that, that is not the point. We are talking here about Maven and about loosing imho important information from the build pom in the consumer pom, and that also existing tooling depends on currently and I want to make sure this is considered, even if decided against. In thus it is also not really relevant what I want to use for libraries I create. My concern is mainly about libraries I do consume and where I can no longer from the consumer POM directly see which dependencies it requires to be present at runtime. I also don't know why `provided` should be `obscure`. In my mind it has a clear definition and meaning. The project needs those at runtime, for example if a library targets only running inside an app server and compiles against some classes that are available in the app server already. So at compilation time the libs are used, at runtime the runtime environment has to provide them. > The problem with going for provided for custom info is Why custom info? This is not custom info put purely Maven-supported standard info. It will "just" be lost in the consumer POM with Maven 4.0.0 currently. > that provided is not extensible. You can't have two teams injecting different pieces of information into provided. I totally do not get what you mean here. This is no different from `compile` or `runtime` or whatever, and the information is already there in the build pom, just gets lost in the consumer pom. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
