Skip to content

Tag: Dependency injection

A tale of Dependencies, Maven, Eclipse and Wasting Time

This should have been easy.

Last week I started doing some refactoring on my OPP code and took the opportunity to start using dependency injection. I downloaded Guice, added it to my libraries project, installed it in my local maven repo, referenced it from my interpreter project, and started using it. From the eclipse environment, everything looks fine – no project with errors. So I ran my unit tests and Bingo! My tests are failing because of a missing dependency to javax.inject.Provider. Ok, this is simple, just add this to the MANIFEST.MF and things should work. And since this is a dependency of the interpreter project, and not only the tests, I’m adding this to the interpreter project.

Run the test again – green. But I still have to do one more check, as I have been burned before by eclipse managing dependencies that are later not identified by Maven. So after changes like this I always do a maven build external to eclipse to see that things didn’t break.

And yes, something was broken. The tests again don’t compile because of the missing dependency. What could be the problem…

After trying many solutions, adding and removing the dependency from one project and moving it to another, I found that by adding the dependency to the library project where the actual Guice library is located fixed all the problems. My takeaway from this waste of time is:

  1. We have solved very complex problems: we have geo-redundant cloud services, advanced machine learning, unlimited storage, and whatnot. But we are still managing code dependencies manually and in a very fragile way.
  2. The IDE doesn’t always behave as a build system behaves. This is both good and bad. Good since if you had to do a full build every time you changed a file instead of eclipse doing incremental compiling, your coding time would be reduced a lot. Bad because you can’t trust on the status of your projects in the IDE and must have some external build and CI done for every change you do. But you probably already know that.
  3. At the end, if things work in one place they will work in the other. Just do a systematic search of all the options you have and apply them one by one. This may not be the optimal thing to do, but when everything else fails, this is the only option.

Happy coding.