Hi all,
this is a very interesting topic indeed.
Having a look at your options Kasper I'd discard the third one "Don't worry
about the duplicated code", this is not an option for me :)
I'd create kind of a "commons" package within the ES and MongoDB module and
then specific modules for each version of the connector, the structure
would like something like this:
metamodel
.......
|-- mongodb
|-- commons
|-- mongo2
|-- mongo3
|-- elasticsearch
| -- commons
| -- estransportnode
| -- esrest
.....
Kind regards,
Alberto Rodriguez
Vía de las dos Castillas, 33, Ática 4, 3ª Planta
28224 Pozuelo de Alarcón, Madrid
Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
<https://twitter.com/StratioBD>*
2015-11-04 10:57 GMT+01:00 Kasper Sørensen <[email protected]>:
> 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
>
