With new shared version numbers, what about creating a BOM? ...what about a mono-repo?

[bsara]

Now that all of the projects share the same version going forward, it would be super nice if we had a BOM to clean up our build files. Gradle supports creating and consuming BOMs nowadays. Also, on that same note, now that all of the different projects share the same version, moving everything into a single mono-repo might be appropriate? I'm personally not a huge fan of mono-repos, but it might make sense now that this is essentially a "framework" or "platform" of libraries that even share the same version numbers.

[oliemansm]

The versions of which libraries would be managed by the BOM? Would that be all dependencies of these libraries, or ...? I don't have any experience creating BOM, so any help in that area would be great.

I'm also not really a fan of a single mono-repo. One of the major things I don't like about them is the fact that all issues and discussions are in one place. Guess you can label and filter them to solve that problem. Upside would be that the release process would be simplified and all versions would always be in sync automatically. @vojtapol Thoughts?

[bsara]

Your points on mono-repos are a reason that I'm not a fan either. The separation that these projects have is quite nice when it comes to getting help and general discussions.

There are two ways that you could go about creating a "BOM" (or get the same functionality). One is to actually create a BOM dependency that can be applied in the dependencies of your build file. The other is to create a gradle plugin that applies dependency constraints. The latter doesn't create a BOM and can only be used in Gradle projects, but overriding the default version (in case a newer/older version is needed by someone) is much more simple than using a BOM. Creating a BOM would also work for Maven build files.

Spring Boot provides both ways that I've just mentioned. Either using the io.spring.dependency-management gradle plugin or using the org.springframework.boot:spring-boot-dependencies BOM in the dependencies of the build file.

Basically, regardless of the direction you decide to go, you would create the BOM file and specify the version of dependencies for all of the gql kickstart dependencies that could be needed (graphql-java-tools, graphql-servlet, graphql-spring-boot-starter, etc.). Then, no more specifying the same version number over and over again on all of the dependencies in your build file...just like when using the spring boot starters.

[bsara]

Also, not all of the projects need to be in the same repo to create the BOM.

[vojtapol]

I like the idea of BOM and would welcome that change. I also agree I am against a monorepo at least for now. Mainly because it seems to be a much bigger change the BOM. We could always consider that later.

[BlasiusSecundus]

It seems that adding a BOM subproject is quite easy, see the linked PR below. Although I could only test it with Maven Local, but it should work with real repositories too.

#552

[bsara]

Thanks @BlasiusSecundus for adding the BoM!

Though, it seems that it isn't on maven central...am I just looking too early or did it not get published?

[oliemansm]

@bsara You're a bit too quick! :) It always take a while before it's fully synced to Maven Central and you can find it there. Shouldn't take longer than a couple of hours though.