Hey! We currently have a chunk of our app on a dif...

# gradle

[Ricardo C.]

Hey! We currently have a chunk of our app on a different repository as a library. App repository is modularized but the library one isn’t. The usage of library is spread through almost all app modules.
Since we’re quickly iterating on the library, each time we publish a new version, this implies an almost full rebuild of the app. We’re losing a ton of time on this process.
So we’re looking to also modularize the library repository and only depend on the appropriate smaller artifacts on the app. This would also imply that each smaller artifact has its own version number instead of having a general one for the whole library, so it doesn’t invalidate the build cache on the app. But this would make it a huge pain to manage and publish.
This library is for internal usage only, so we can manage how we want it as long as it stays on a different repository.
Do you folks have any suggestion on how to better handle this?
Thank you!

[jendrik]

If the versioning is the pain of the solution you have in mind, you can also consider including the library repository (or parts of it) as included build(s) instead of publishing. Then you will always build from source. But since it sounds like you are using the (remote) build cache, that may be fine performance wise. Then you will always build against the latest version of the library from source. You can then also build a branch of the App against a branch of the Library.

The “annoying” part might be that then you always need to clone and pull the Library repo when working on the App. There is this plugin that could be helpful: https://melix.github.io/blog/2021/11/multirepo-dev-made-easy.html

[Ricardo C.]

Thanks for answering!
We are not using remote build cache (it’s something we still need to investigate). That’s why we’re trying to minimize rebuilt modules, because everyone has to do it upon changes.
I’ve taken a look at that plugin but it kinda seemed that it would be good for development but that in the end we would still need to generate binaries. And generating binaries would force us to manage a version number for each binary.
Is always building from source, without binaries, a good practice?

[jendrik]

Is always building from source, without binaries, a good practice?

I think that really depends on the project and the workflow. Especially regarding the versioning problematic. And I think no one has the one right answer for that. Big question since “software modularisation” was invented. 🙂 Things to consider for example:

• If you build binaries, you can easily version and use different version in parallel in different microservices for example. But then you have to deal with (in)compatibility of the versions and the version management in general.
• If you don’t want to use different versions in parallel in production, always building from source can avoid version management complexity. Although you may have different “versions” (or different variations) by branches in the repositories. So if you have different repos, you might need to introduce some branching model you follow everywhere - e.g. have a ‘release’ and a ‘main’ branch in all repos that work with each other.
If you do not use the remote cache though, not building everything from source is also a performance questions. So if you do not have this, I probably won’t switch to that in you setup. Things probably get even slower.

[Fleshgrinder]

Even with remote build cache included builds are a pain. You always run all tests across the board, well, unless you forget to wire the tests tasks for your included builds in your wrapping build. In that case probably nobody is ever running those tests. That's what happened to us. IntelliJ also has various issues with included builds, especially, again, with the nested tests. I would recommend to follow the package principles by the letter and create multiple repositories where the things go together that belong together. If SemVer is a pain simply switch to CalVer.

https://hynek.me/articles/semver-will-not-save-you/
https://calver.org/

Simply ensure that it's properly SemVer compatible:

date -u '+%Y.%-m%d.%-H%M%S'