Break down Jedis to several submodules (in current Repo)

[HeartSaVioR]

Recently we're talking about drop supporting features at 3.0.0 because of simplification.

We can define the 'core' to Jedis (with JedisPool), and remains could be 'subproject'. (I mean subproject to Maven's submodule, for example, https://github.com/apache/storm)

For example, you can see JedisCluster consists of Jedis, and it does work with no modification to Jedis itself. (Sorry but one thing, parsing ERR message from Jedis.) So it can be changed to 'subproject' with small changes.

Currently JedisCluster, JedisSentinelPool, ShardedJedis (which we're planning to drop) could be one of subproject, and I think AsyncJedis could be, too. (Pipeline could be one of things but it's similar to Transaction which should be in core, so it seems better to leave Pipeline 'core'.)

Then we finally have artifacts 'jedis-core', 'jedis-cluster', 'jedis-sentinel', 'jedis-sharded' (maybe dropped), 'jedis-async' (not yet ready), etc, with 'jedis-parent' pom.

It's great for separating concerns while modifying each of subproject, and we can run tests faster by running tests within modified subproject. (We can run whole tests from root directory, too. Maybe we should do it when we're modifying 'core'.)

ps. Please don't misunderstand that we'll take less care of submodules (maybe named to plugin). It's all about structure, not intended to change focusing. We have to focus all subprojects while it is in Jedis repo.

[nykolaslima]

Totally agree with that.

We need to define what is gonna be the core, but I think it should be everything supported by Redis. I don't know if we will have much advantages breaking jedis-cluster and jedis-sentinel to sub-projects. I agree that we must have sub-modules but not for this cases.

[HeartSaVioR]

Please note that for maintaining from a few developers with a long time, Jedis has to adopt only 'communication between Redis'. That's one of reasons why we're planning to drop supporting ShardedJedis at 3.0.0.

Based on my perspective about Jedis, I understand that you don't agree with breaking down features to submodule.

Thanks for your opinion!

[HeartSaVioR]

Maybe I misunderstood you. The point is 'separation of concern'. You don't have to concern Jedis / JedisPool class when modifying JedisCluster. So does JedisSentinelPool. Based on that we can run unit tests for each feature. Maybe restructuring could achieve similar things. It would be amazing, too.

[nykolaslima]

I understand you. I just wondering, this separation in sub-modules would make the development/testing/releasing much more harder?

My concern is about if the trade offs worth.

[HeartSaVioR]

My first thought is "Is it really better to add dependency (I mean Netty) which is only for AsyncJedis?" My answer is not, "No, we would be better to separate project or submodules"

Maybe without AsyncJedis it's better not to break down submodules. So I'm fine to not changing JedisCluster and JedisSentinel, but AsyncJedis has to.

ps. We can relocate Netty so that users can use their Netty, but I think it's a workaround.

[HeartSaVioR]

Related to #824 In addition to #824's title, seems like it's time to discuss package structure.

[nykolaslima]

@HeartSaVioR I agree with you.

I'll try to draft something and give you a feed. Next week we have holidays in Brazil(Carnival), after that I'll post my opinions here.

[HeartSaVioR]

@nykolaslima OK, we also have holidays in South Korea (Korean New Year) so I may be offline, too. :)

[allanwax]

I think there is an advantage, now, that Redis can build without additional tools on a standard *nix box. If by module you mean that maven is now required then I'd say no. If you merely want to break the structure up into logical components then that's fine. Being able to wget, make, make install on any system is an advantage.

[github-actions[bot]]

This issue is marked stale. It will be closed in 30 days if it is not updated.