Interesting discussion. I do not have any strong opinions about what approach we choose. I just want to say that the way we build is already a bit complex, we have an Ant-based build of the core project, which is coerced to produce Maven artifacts, then we have a submodule with a Gradle-based project as well. So whatever we go with here should be something which somehow fits the picture for the sake of not making it even more complicated.
For that reason, Mick's suggestion of yet another submodule is quite sound to me. It would be isolated / self-contained, we can also make the necessary changes to have it releasable, plug it to a build pipeline ... We can also take that project as is and just basically copy it over to a sub-module and do nothing else, practically. However, I would like to eventually see that the build systems converge and we could rewrite it later on to Gradle to copy how Accord has it. On Thu, Jan 1, 2026 at 4:22 PM Josh McKenzie <[email protected]> wrote: > > And if it's still considered too painful maybe we should revisit whether it's > still what we want to be using it for accord. > > Why hello there scope creep. My name is Josh: to Hell With Thee. :D > > (i.e. let's take that to a separate thread if it becomes A Thing in this > thread). > > So: > > That's the whole benefit of the git submodule, for us it is in-tree 🤷 > > Could you provide a concrete example of this? This doesn't match my mental > model but I haven't really done any dual-branch w/submodule work outside CI. > A submodule is still effectively a 2nd repo and artifact so a change means > managing 2 diffs, 2 sets of CI, 2 reviews, and 2 merges. You're going from A > -> A` and B -> B` instead of just A -> A`. > > I'll dig into the CI and submodule inconsistency stuff maybe next week when > I'm back in the office and get JDK21 across the line. > > On Wed, Dec 31, 2025, at 12:29 PM, Mick wrote: > > And if it's still considered too painful maybe we should revisit whether it's > still what we want to be using it for accord. > >
