Yes this is what I’m suggesting - except we already have a separate repository for accord and several other systems (like dtest api, sidecar etc), and for these it makes sense to have a separate repository for shared functionality.On 17 Mar 2025, at 07:20, Jon Haddad wrote:It should be possible t
That gets my vote as well Joan Haddad
On 17/3/25 8:19, Jon Haddad wrote:
It should be possible to modularize the code without breaking it into
separate repos. I don't know how to do it with ant, but with Gradle
[1] you use subprojects. I think Maven calls them multi module
projects [2]. The
It should be possible to modularize the code without breaking it into
separate repos. I don't know how to do it with ant, but with Gradle [1]
you use subprojects. I think Maven calls them multi module projects [2].
They're just folders in the same repo that are treated as dependencies.
For exampl
I can only speak for myself, but the overhead of managing the accord submodule has been fairly low. It does mean opening two PRs when a change touches both projects (which is often the case for accord), but I think for utility classes this would be infrequent anyway.I think any modules within Cassa
Definitely supportive of modularizing code but from a developer
productivity standpoint we should discuss the overhead of managing changes
across multiple repos.
On Sun, Mar 16, 2025 at 4:26 AM Benedict Elliott Smith
wrote:
> I want to break out at least one or two shared library projects. Both
I want to break out at least one or two shared library projects. Both accord
and in-jvm-dtest-api should share code with the Cassandra main project,
particularly executors/futures/collections/concurrency utilities. This is
something that has caused me some recurring friction over the past few ye
> I've gotten the impression that there's not a lot of enthusiasm for breaking
> apart the main Cassandra module, but I have wondered if it'd be worth making
> an exception for the interfaces plugins are supposed to code against
Oh, there's *plenty* of enthusiasm. There's been a shortage of conse
This has been on my mind for a while, and I think it's a great idea.
Someone shouldn't need all the C* internals just to implement an interface.
On Thu, Mar 6, 2025 at 1:08 PM Joel Shepherd wrote:
> Splitting this out from the CEP-36 thread.
>
> I agree: dependency collisions at run-time are a p
