0

I am writing an application that I've split into multiple jars including re-usable infrastructure libraries, each has their own versions (BOM managed) and git repositories. I'm doing this for a number of reasons.

  1. some of these would be reusable if I decided to start writing a completely different application, and I may decide to release them as open source.
  2. by making them different modules, as they stabilize I will not have to re-build code over and over again, the modules APIs will stabilize
  3. prevent myself from improper layering and dependencies by ensuring there isn't any class path compile time visibility in some cases.

however this has left me with some development overhead. Mainly these problems

  1. I have something like a dozen repos cloning them if on a fresh install is annoying.
  2. I can't view or refactor code together in intellij while making changes to upstream libraries as needed. note: these aren't changing together all the time, just need to improve upstream first sometimes, but would be useful to do it in context.
  3. even if I open all the repositories in intellij at once, it doesn't treat them as interdependent, thus renaming one class wouldn't update references, etc appropriately. It wants me to mvn install them first.
  4. if I need to release multiple modules, I have to go into each module and type mvn release, I don't see a good way to do it for the modules that have changed since last release at once (they would still have different versions).

I've thought about making a multi-module repo, but then I still have the repo problem, and doesn't seem to make sense since I release them with their own versions. Every time I've seen git submodules used (including my own attempts) they caused more problems than they solved. I could just write some shell scripts or makefiles or something, but that seems like a last resort.It's possible that I should just bear through the early pain while things stabilize.

Is there a good tool(s) that will solve my problems?

3
  • 3
    This is the classic tradeoff of splitting a project into independent modules, and there's no easy shortcut: either you get the benefit of modularization (especially independent versioning of those modules) or you get everything in one place (although I'm surprised that IntelliJ doesn't recognize the dependencies). For what it's worth, Google stores everything in a single source repository, although their entire development process is quite different from what most of the world does.
    – kdgregory
    Feb 9, 2017 at 13:07
  • @kdgregory it recognizes dependencies, just not that you have the same module open, so things like hotswapping code, and renaming don't work as they would in a multi-module. Feb 9, 2017 at 14:14
  • Regarding issues 2 and 3, I have a very similar situation and it works fine when configured correctly in eclipse. I'd be surprised if intellij is unable to handle it... maybe you need to look into how to configure it? If not, you could consider switching to eclipse to resolve those issues. Nov 7, 2017 at 1:23

2 Answers 2

1

This might be a subjective answer, but I find that git submodules, combined with a good Makefile, can initialize code in a fluid way even from IntelliJ.

Makefiles have the subtle but awesome feature of skipping build rules that point to an existing path or folder. This is largely a (welcome) holdover from the C days of yore, when compiling meant turning a .c into a .o. To clean and recompile, you’d just delete your .o’s, and run make again.

By mapping in your submodules as targets, you can init them automatically only when they’re missing, with basically no logic but the git commands themselves. Make also ships on basically every OS by default, which is a nice plus.

0

If the operating system you use for development supports it (all I know do, someway), use symlinks to have the IDE consider the source code directories of the dependencies as part of the project.

You will need to use configuration and build files that are aware of what you're doing while you're developing.

In testing, and in deployment, there should not be any symlinks, and the formal dependency management process should take over.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.