Those of us who have developed the in-jvm-dtest-api will know that the project’s approach to developing libraries is untenable for more complex projects. Accord makes this a pressing concern, but we would also benefit from separating utilities to their own library for use by the dtest-api and Accord, and also the dtest-api could be evolved more easily. I see basically four options:
Continue requiring a release vote for every library change prior to importing it to another project Bring libraries into the C* tree Deploy snapshots for our internal modules, that we import until release (at which publish real jars) Use git submodules I think (4) is the only sensible option. It permits different development branches to easily reference different versions of a library and also to easily co-develop them - from within the same IDE project, even. We might even be able to avoid additional release votes as a matter of course, by compiling the library source as part of the C* release, so that they adopt the C* release vote (or else we may periodically release the library as we do other releases) (1) is unworkable, as this means a release vote for every patch that affects both a library and a module that imports it. Even for the dtest-api, this has been excruciating and has lead to workarounds. (2) incurs additional development work porting changes between C* versions that share a logical library version, and the potential for the “same” version to drift unintentionally (3) makes parallel branch development trickier as each needs its own unique snapshot release, and release votes become more complicated as we require a chain of releases, one for each dependency. I might be missing something, does anyone have any other bright ideas for approaching this problem? I’m sure there are plenty of opinions out there.
