What would be your take on moving such a set of applications to a mono-repo with build process for the different deployment applications. I've been discussing this possibility with one of my leads as a solution to resolve the difficulty of debugging and of having to build dependencies, upload them to artifact repo and pull into dependent project to even test a fix. It would be a large undertaking, but would result in something that I expect w I uld be much easier to manage and the depency jars wouldn't need to be stored anywhere externally.
Just so I understand in broad strokes, are you talking about having a mega-codebase to rule them all, and then having individual builds that plucked only the dependencies they need to advance them through promotion to production?
If so, (1) I'm kinda fascinated and (2) the first thing I'd wonder about would be the impact on the build and unit test suite. I'm inferring from "jars" that this is a Java codebase, and you'd have partial compiling as an option.
Your understanding is correct. It was an idea that I'd read before and seemed pretty interesting, but I've not seen it mentioned anywhere else. I'll have to do some more research, and may have to do some build experiments to make sure that I can actually pull off what I'm considering.
Hmm... it's an interesting proposition, I'd say. Putting my code/data consultant hat back on, I think the questions that would pop into my head for evaluation would be:
Then I'd try to figure out ways to quantify projections about those things. (This was basically the essence of my niche practice -- define the important questions, quantify, and make a case.)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.