[GitHub] [ozone] fapifta commented on pull request #3104: HDDS-6213. Pluggable OzoneManager request handling hooks

[GitBox <gi...@apache.org>]

fapifta commented on PR #3104:
URL: https://github.com/apache/ozone/pull/3104#issuecomment-1104178205

   Hi Attila,
   
   no worries, you may be on time, before we go to far down this road :)
   I am open to any better place for this module... Let me first shed light about why this exists as a separate thing.
   
   Even though we have other annotations, we do not have anything that validates those annotations, and for this annotation, we wanted to ensure some invariants about the methods that are annotated with it, as there are some expectations about the methods where they are used.
   This module defines the annotation processor that is used during the compilation of the project, not even the annotation itself. The annotation processor checks the annotated methods during compile time, and issues an error if any of the invariants are violated by the annotated method.
   
   As such, this module has to be compiled before anything else, as compilation of anything else depends on the jar created from this module. If this module is a child of the main project, then we have a circular dependency as this module would depend on the parent while the parent would depend on the module... In order to solve this I chose to separate the module from the main pom, but made it as a dependency of the main pom with that hook it in onto the build. Certain tools does not hook it in seamlessly like version:set, which is a problem, I admit, I do not have any good resolution for.
   Spotbugs and Checkstyle dependency is added to cover the module code within CI properly, this is also something I do not have a better resolution for.
   
   Dev-support in the main project dir seemed to be a good idea for one reason, this annotation processor is there to help developers to ensure the methods annotated with the annotation are correct, and do not violate the invariants, and if we want this may be optional for the regular dev cycle and it can be just mandatory in the CI level, but that I think would have just complicated things more. I am open to have any better place to build this. Also I had an other idea to have even a separate project like ozone-sdk or such, where we can put similar things, but for just this one use case that seemed to be an overkill.
   
   Let's discuss this further at anytime, even offline, or in a new JIRA where we can discuss the proper solution... I have a couple of other items that is related to this and related PRs, and I think there has to be some significant follow up work on this system, as we started to learn more about this while we started to use it in EC upgrade compat problems.


-- 
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-unsubscribe@ozone.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org