[jira] [Commented] (KAFKA-12757) Move server related common and public classes into separate module(s).
[ https://issues.apache.org/jira/browse/KAFKA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342272#comment-17342272 ] Satish Duggana commented on KAFKA-12757: [~junrao] I am not aware of cases like common classes depending on server side APIs. But I wanted to call out about the dependency limitation so that others know about it and discuss any such cases if they have. > Move server related common and public classes into separate module(s). > -- > > Key: KAFKA-12757 > URL: https://issues.apache.org/jira/browse/KAFKA-12757 > Project: Kafka > Issue Type: Improvement >Reporter: Satish Duggana >Priority: Major > > There are two sets of classes that we want to pull out here for server > common/api classes. > 1. All the common classes used by server modules. > 2. All the public server side classes exposed to users. Some of these > classes are storage-api, security, quotas etc. > Couple of approaches that we can consider here: > 1. Both sets of classes will be added in server-common module but common > classes will have a package prefix as org.apache.kafka.server.common. But > public classes will continue to have the existing package names. We will > generate javadocs for these public classes. > Pros > - Users and server modules will be depdent on a single module for both > common and public apis. > - Both common classes and api classes can be dependent on each other. > Cons > - Not a clean separation between common classes and public classes. > 2. Common classes used by server modules will be added in server-common > module. We will create another module called server-api for server side > public classes. > Pros > - It gives a neat separation between common and public classes. > - Maintaining the growth of these modules will be easy. > Cons > - We can not have common and api classes to be dependent on each other which > will cause circular dependency. > > Please feel free to modify/add other approaches in modularizing these > classes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-12757) Move server related common and public classes into separate module(s).
[ https://issues.apache.org/jira/browse/KAFKA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342023#comment-17342023 ] Jun Rao commented on KAFKA-12757: - [~satish.duggana]: The implementation of server side APIs may depend on common classes. Will the common classes ever depend on APIs? > Move server related common and public classes into separate module(s). > -- > > Key: KAFKA-12757 > URL: https://issues.apache.org/jira/browse/KAFKA-12757 > Project: Kafka > Issue Type: Improvement >Reporter: Satish Duggana >Priority: Major > > There are two sets of classes that we want to pull out here for server > common/api classes. > 1. All the common classes used by server modules. > 2. All the public server side classes exposed to users. Some of these > classes are storage-api, security, quotas etc. > Couple of approaches that we can consider here: > 1. Both sets of classes will be added in server-common module but common > classes will have a package prefix as org.apache.kafka.server.common. But > public classes will continue to have the existing package names. We will > generate javadocs for these public classes. > Pros > - Users and server modules will be depdent on a single module for both > common and public apis. > - Both common classes and api classes can be dependent on each other. > Cons > - Not a clean separation between common classes and public classes. > 2. Common classes used by server modules will be added in server-common > module. We will create another module called server-api for server side > public classes. > Pros > - It gives a neat separation between common and public classes. > - Maintaining the growth of these modules will be easy. > Cons > - We can not have common and api classes to be dependent on each other which > will cause circular dependency. > > Please feel free to modify/add other approaches in modularizing these > classes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KAFKA-12757) Move server related common and public classes into separate module(s).
[ https://issues.apache.org/jira/browse/KAFKA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17341829#comment-17341829 ] Satish Duggana commented on KAFKA-12757: cc [~junrao] [~ijuma] > Move server related common and public classes into separate module(s). > -- > > Key: KAFKA-12757 > URL: https://issues.apache.org/jira/browse/KAFKA-12757 > Project: Kafka > Issue Type: Improvement >Reporter: Satish Duggana >Priority: Major > > There are two sets of classes that we want to pull out here for server > common/api classes. > 1. All the common classes used by server modules. > 2. All the public server side classes exposed to users. Some of these > classes are storage-api, security, quotas etc. > Couple of approaches that we can consider here: > 1. Both sets of classes will be added in server-common module but common > classes will have a package prefix as org.apache.kafka.server.common. But > public classes will continue to have the existing package names. We will > generate javadocs for these public classes. > Pros > - Users and server modules will be depdent on a single module for both > common and public apis. > - Both common classes and api classes can be dependent on each other. > Cons > - Not a clean separation between common classes and public classes. > 2. Common classes used by server modules will be added in server-common > module. We will create another module called server-api for server side > public classes. > Pros > - It gives a neat separation between common and public classes. > - Maintaining the growth of these modules will be easy. > Cons > - We can not have common and api classes to be dependent on each other which > will cause circular dependency. > Pl feel free to add if you want to discuss other approaches in modularizing > these classes. > -- This message was sent by Atlassian Jira (v8.3.4#803005)