gemmellr commented on PR #4567: URL: https://github.com/apache/activemq-artemis/pull/4567#issuecomment-1649671814
Yes this way can be better in some regards, but at a cost of increased complexity, and in this case really only in a specific on-demand development case that is already isolated by profile, and doesnt apply at all in the regular builds. I would say the added complexity outweighs the benefit in the current case. As did another developer previously when expressly avoiding doing this (even though they instead selected adding the processor as a constantly present provided dep in every module in the tree...I later removed all that and profiled it off as as present to isolate it all from normal builds, as yes the normal build should not have ErrorProne dependencies in it). We are are only setting the version of the artifact via dependencyManagement so its consistent and defined in one place. The configuration of actually using the processor is being done on demand via the dependency within the profile, which is already isolating it to be optionally enabled-on-request, typically only in CI checks, adding it as the last dependency entry. The version being managed for interesting transitive dependencies such as guava means there is already minimal scope for change even there (except, say, if you also removed that dependencyManagement against feedback). This is simpler as it is and for the vast majority of the time, i.e all regular build ones, still the same as it would be after this change. Lets jsut leave it as it is. -- 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]
