Hi everybody, Wanted to bring up a discussion topic that I feel is important for two current pull requests regarding supporting ElasticSearch REST API [1] and MongoDB 3.x API [2]
The topic is about granularity of modules and how that sometimes determines the amount of separation but also the amount of code reuse we can have. In the MongoDB case we have two APIs - one which is legacy and deprecated (but still working and compatible with older MongoDB installations) and a new API. Both of them can be used with the same dependency, we'll just have to live with a bunch of deprecation warnings. In the ElasticSearch (ES) case we have the official ES jar which includes "Transport" and "Node" client support. In addition ES provides a JSON protocol which has some benefits - particularly that as a Java client you have less dependencies and don't need to sync with the server. So for the REST protocol we now have the PR which uses the library "Jest" that integrates with ES that way. Normally I would then say: Create four modules - one for MongoDB 2.x, one for MongoDB 3.x, one for ES transport+node client and one for ES REST client. But the trouble is that there is also a lot of duplicated code then. So I think we have in total 3 options to go for: 1) Bundle the modules together but make dependencies optional. There is a slight risk here that e.g. a future MongoDB version will delete the API which is right now deprecated. That would make our module un-compileable. But OTOH at that time we might decide to delete it as well ;-) 2) Create a 5th and 6th module: One module for shared ES code and one module for shared MongoDB code. 3) Don't worry about the duplicated code. Let's discuss or raise your favourite approaches. Best regards, Kasper [1] https://github.com/apache/metamodel/pull/67 [2] https://github.com/apache/metamodel/pull/68
