> > Regarding the use of snapshots, this isn’t impossible Henrik - I floated > this as an option. But besides the additional overhead during development, > this does not maintain reproducible builds, as the snapshot can change. >
You would reference the snapshot dependency by the timestamped snapshot. This makes it a reproducible build. We have done this with dtest-api already, and there's already a comment explaining it: https://github.com/apache/cassandra/blob/trunk/.build/build-resolver.xml#L59-L60 It introduces some overhead when bisecting to go from the snapshot's timestamp to the other repo's SHA (this is easily solvable by putting the SHA inside the jarfile). I don't see the problem of letting trunk use snapshots during the annual development cycle, if we accept the overhead of cutting all library releases before we cut the first alpha/beta. FTR, i'm sitting on the fence between this and submodules. There's many dev tasks we do, and different approaches have different pain points. The amount of dev happening in the library also matters. I also agree with Derek that linking in the source code into in-tree is a significant thing to do, just to avoid the rigamaroles of dependency management. Josh, bundling releases gets tricky in that you need to include the library sources, because the cassandra release is essentially being voted on (because it has been built) with non-released dependencies.
