IMO, according to consistent concept, shardingsphere-spring should be shardingsphere-jdbc-spring.
At 2020-05-16 00:33:22, "[email protected]" <[email protected]> wrote: >I just decoupled dependency between `shardingsphere-spi` module and >`shardingsphere-sql-parser` module in pull request[1]. So we can merge >`shardingsphere-spi` into `shardingsphere-infra` module as a package now. > >Another problem is about module `shardingsphere-spring`, it is for >`shardingsphere-jdbc` only, how about move it as a subproject? > >After change, the new modules should be: > >``` >shardingsphere-sql-parser >shardingsphere-db-protocol >shardingsphere-infra >shardingsphere-jdbc > -- shardingsphere-jdbc-core > -- shardingsphere-spring >shardingsphere-proxy >shardingsphere-transaction >shardingsphere-scaling >shardingsphere-features > -- shardingsphere-sharding > -- shardingsphere-master-slave > -- shardingsphere-encrypt > -- shardingsphere-shadow >shardingsphere-control-panel > -- shardingsphere-orchestration > -- shardingsphere-opentracing > -- shardingsphere-metrics >shardingsphere-integration-test >shardingsphere-distribution >``` > >[1] https://github.com/apache/shardingsphere/pull/5633 > >------------------ > >Liang Zhang (John) >Apache ShardingSphere & Dubbo > > >[email protected] <[email protected]> 于2020年5月15日周五 下午5:17写道： > >> Keep shardingsphere prefix is a good idea, the new modules should be: >> >> ``` >> shardingsphere-spi >> shardingsphere-sql-parser >> shardingsphere-db-protocol >> shardingsphere-infra >> shardingsphere-jdbc >> shardingsphere-proxy >> shardingsphere-spring >> shardingsphere-transaction >> shardingsphere-scaling >> shardingsphere-features >> -- shardingsphere-sharding >> -- shardingsphere-master-slave >> -- shardingsphere-encrypt >> -- shardingsphere-shadow >> shardingsphere-control-panel >> -- shardingsphere-orchestration >> -- shardingsphere-opentracing >> -- shardingsphere-metrics >> shardingsphere-integration-test >> shardingsphere-distribution >> ``` >> >> I plan to finish renaming them on this weekend (because there are less >> pull request at that time). >> >> ------------------ >> >> Liang Zhang (John) >> Apache ShardingSphere & Dubbo >> >> >> Zhiyi Yan <[email protected]> 于2020年5月15日周五 下午2:28写道： >> >>> I prefer use prefix 'shardingsphere', it looks more complete and clear. >>> >>> >>> ---------------------- >>> Zhiyi Yan (Zhyee) >>> Apache ShardingSphere >>> >>> >>> KimmKing <[email protected]> 于2020年5月15日周五 下午1:28写道： >>> >>> > Haoran & Xiaoyu: >>> > >>> > >>> > There is one thing shoule be clarified: Whose Prefix. >>> > The word Prefix has three meanings: >>> > 1. directory name in repo root dir >>> > 2. sub module name in pom file and maven artifactId field >>> > 3. binary jar file name and related release tar.gz file name >>> > >>> > >>> > So, we should point which one is the Actual Meaning exactly in your >>> post. >>> > >>> > >>> > For the point 1, prefix is not an important issue. >>> > For the point 2, the prefix is already in groupId, such as >>> > org.apache.shardingsphere, and the whole maven coordinate is like >>> > org.apache.shardingsphere:orchestration-center-etcd:5.0.0. As you know, >>> if >>> > we add another prefix in modue name, it will be >>> > >>> org.apache.shardingsphere:shardingsphere-orchestration-center-etcd:5.0.0. >>> > There is one more duplicated shardingsphere word. >>> > For the point 3, jar file name is usually the same with module name and >>> > version, and the assemebly tar.gz file should have a shardingsphere >>> prefix >>> > to show the owner, such as apache-shardingsphere-proxy-5.0.0-bin.tag.gz. >>> > >>> > 在 2020-05-15 12:48:02，"Myth" <[email protected]> 写道： >>> > >I prefer hold the prefix `shardingsphere`, >>> > >becaues >>> > > 1. the uniform prefix feels neat . >>> > > 2. make people understand the ownership and mean of the module >>> > more. >>> > >module names that are too long should not be a concern, and it not long >>> > > >>> > > >>> > >thanks. >>> > > >>> > > >>> > > >>> > > >>> > >------------------ 原始邮件 ------------------ >>> > >发件人: "Haoran Meng"<[email protected]>; >>> > >发送时间: 2020年5月15日(星期五) 中午12:36 >>> > >收件人: "dev"<[email protected]>; >>> > > >>> > >主题: Re: Aggregate and redesign modules for ShardingSphere 5.x >>> > > >>> > > >>> > > >>> > >Hi, Liang >>> > > >>> > > >>> > >Point 1 : >>> > > >>> > >I prefer hold the prefix `shardingsphere`, if some moudles >>> > name with ` >>> > >shardingsphere` prefix are too long , i suggest may be we >>> can >>> > consider >>> > >optimizing the module name first. >>> > > >>> > >I think without prefix is simpler, but with prefix is more tidy. >>> > > >>> > >Point 2 : >>> > > >>> > > `scaling` is independent ，but it doesn't look like the same >>> > level as >>> > >others. >>> > > >>> > >Thanks! >>> > > >>> > > >>> > >zhaojun <[email protected]> 于2020年5月15日周五 上午10:06写道： >>> > > >>> > >> LGTM, it looks jdbc and proxy is light enough after pluggable >>> > platform >>> > >> complete. >>> > >> >>> > >> Regards, >>> > >> cherrylzhao >>> > >> ------------------------------------------------------- >>> > >> Email：[email protected] >>> > >> Jun Zhao(cherrylzhao) Apache ShardingSphere >>> > >> >>> > >> >>> > >> [email protected] <[email protected]> 于2020年5月14日周四 >>> > 下午10:35写道： >>> > >> >>> > >> > Hi all, >>> > >> > >>> > >> > Apache ShardingSphere has lots of new features for new >>> version >>> > 5.x. >>> > >> > It is better to aggregate and redesign modules. >>> > >> > >>> > >> > The current modules are: >>> > >> > ``` >>> > >> > shardingsphere-spi >>> > >> > shardingsphere-sql-parser >>> > >> > shardingsphere-database-protocol >>> > >> > shardingsphere-underlying >>> > >> > sharding-jdbc >>> > >> > sharding-proxy >>> > >> > sharding-core >>> > >> > sharding-spring >>> > >> > sharding-orchestration >>> > >> > sharding-opentracing >>> > >> > sharding-metrics >>> > >> > sharding-transaction >>> > >> > sharding-scaling >>> > >> > master-slave-core >>> > >> > encrypt-core >>> > >> > shadow-core >>> > >> > control-panel >>> > >> > shardingsphere-integration-test >>> > >> > >>> > >> > ``` >>> > >> > >>> > >> > There are serval points need to be adjusted: >>> > >> > >>> > >> > 1. There are 2 diff prefixes for `shardingsphere` and >>> > `sharding` we need >>> > >> > to unify. `sharding` is a feature name, and `shardingsphere` >>> is >>> > too long, >>> > >> > so I prefer remove all prefixes. >>> > >> > 2. We have lots of features and may add more, so it is >>> better to >>> > >> aggregate >>> > >> > them to a parent modules. >>> > >> > 3. The orchestration related modules can be include in >>> > control-panel >>> > >> > module. >>> > >> > 4. It is better to rename shardingsphere-underlying to infra >>> > module >>> > >> because >>> > >> > of it is more shortly and more make sense. >>> > >> > >>> > >> > So the draft of new modules are: >>> > >> > >>> > >> > ``` >>> > >> > spi >>> > >> > sql-parser >>> > >> > db-protocol >>> > >> > infra >>> > >> > jdbc >>> > >> > proxy >>> > >> > spring >>> > >> > transaction >>> > >> > scaling >>> > >> > features >>> > >> > -- sharding >>> > >> > -- master-slave >>> > >> > -- encrypt >>> > >> > -- shadow >>> > >> > control-panel >>> > >> > -- orchestration >>> > >> > -- opentracing >>> > >> > -- metrics >>> > >> > integration-test >>> > >> > distribution >>> > >> > ``` >>> > >> > >>> > >> > Any suggestion? >>> > >> > >>> > >> > ------------------ >>> > >> > >>> > >> > Liang Zhang (John) >>> > >> > Apache ShardingSphere & Dubbo >>> > >> > >>> > >> >>> > > >>> > > >>> > >-- >>> > >Haoran Meng >>> > >[email protected] >>> > >>> >>
