Git submodules vs dependency management?

Question

Where I work, we use a tool called apache Ivy for dependency management. However, I have recently been working on a project of my own with multiple repositories, therefore, I am using a git superproject to maintain all of them. The git submodules has been great for me and so far I strongly prefer them over Ivy. Here are the main things I like about them over Ivy:

• Anytime you make a changes to two or more repositories that are dependent on each other, you can just commit to the superproject so it is apparent what is dependent on what. In Ivy, you have to do an entirely new release which is annoying.
• It is much easier to track your changes better in a superproject. To my knowledge, Ivy doesn't keep very good track of you changes to a release.
• Git has much more support than Ivy
• You only have to understand one tool, GIT!!!

However, my company refuses to touch git submodules/superprojects. I have also been doing some research and it appears that a lot of people do not like git submodules and it is not considered good as a "dependency management" tool. Can anyone help me understand why?

Answer 1

Probably the killer feature of dependency managers like Apache Ivy is transitive dependencies resolution and conflict management. This is not doable using git submodules.

From Apache Ivy features page:

Imagine a component that's often reused by a software team, and that this component has dependencies of its own. Without a good dependency management tool, each time this component is reused, all its dependencies must be repeated. With Apache Ivy, it's different: simply write a dependency file once for the component, and benefit from the work already done anytime this component is reuse.

Another features that I consider important are:

• downloads already compiled packages, instead of having to compile them every time

• dependencies reports

That all said, I would only suggest git submodules when your dependency tree is really and compiling dependencies code is cheap.