[
https://issues.apache.org/jira/browse/KAFKA-12757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Satish Duggana updated KAFKA-12757:
-----------------------------------
Description:
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.
was:
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 depdency.
Pl feel free to add if you want to discuss other approaches in modularizing
these classes.
> 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)
