I hope this is the right place for these considerations. If not, please tell me where I should better write them.
I reflected a lot on this "dependency management-less" mode after you implemented it. Recently I had the opportunity to work on a multiproject which is smaller than the one for which I bombarded you with issues (), but with interesting characteristics. I even pushed myself towards the direction to completely disable STS to handle my imported Eclipse projects, to see what it would mean. I could do this because the multiproject is made up of only 3 subprojects (+ the master one) and I could use a flat layout for it. This allowed me to:
- import projects into the workspace using the "import existing project into the workspace" wizard: this is impossible when you use the hierarchical multiproject layout
- avoid to cope with many other annoyances the hierarchical layout imposes due to the lack of hierarchical project structure support in Eclipse
Anyway, apart from this, I think I could make myself a better idea on what it means to work without STS handling my dependencies.
First of all, I found a little annoyance: http://issues.gradle.org/browse/GRADLE-2293. Similar problems have been already fronted and fixed by you in STS (do you remember
STS-2174?) and they come into play when the projects are shared into an SCM.
Another "small" problem ("small" because I think it will be solved when http://issues.gradle.org/browse/GRADLE-2123 is fixed) is that dependencies of a 'war'+'eclipse-wtp' project are currently configured in a way that prevent Gradle from providing the sources of the JARs on which my Eclipse WTP project depends on. This is actually the area in which the "dependency management-less" mode was more promising for me to solve complex project setups that are described in
STS-2186 and whose resolution in STS would need some work that also needs propaedeutic improvements on Gradle's counterpart, partially discussed recently by you and Szczepan Faber on http://issues.gradle.org/browse/GRADLE-1777.
But the major problem, for which I don't think there will ever by an effective solution in "dependency management-less" mode, arises again when you are sharing your projects in a SCM repository: when you let Gradle "eclipse" and "eclipse-wtp" plugins alone to handle dependencies, they configure your Eclipse project classpath with hard references to JAR files in your local filesystem. This means that if team member A and team member B check out the same shared Eclipse project on their systems, they must issue a "Refresh dependencies" on the project after checking it out (and this is not a problem) and the result of this operation leads to two different .classpath files (and maybe others, when WTP is involved) on A's and B's local working copies. This is bad, since unwanted changes are always generated whenever a dependency refresh is issued by any team member.
This is not the case when STS dependency management is enabled, because apart from sharing an Eclipse setup where the STS container is in the projects' build path, JARs are then resolved dynamically by STS and no hard references to the local physical location of JARs are saved in the shared project files.
This is an extremely important plus of the "dependency management-enabled" mode and I don't think there is any easy way to fix the "dependecy management-less" mode to handle this use case in the right way, other than adopting an approach similar to the one STS is already providing with its "Gradle Dependencies" container (and hence with the "dependency management-enabled" mode).
In a "Gradle-ideal" world, maybe one may think about the possibility to just share Gradle projects and source files and let "gradle eclipse" to generate all the necessary Eclipse project setup for you whenever you check out your project from the SCM repository, without sharing the generated Eclipse project configuration files. However, I don't think this is a viable solution, since there are a lot of other project configuration aspects (like: build path inclusion/exclusions, formatter and convention settings, other Java editor settings and in general any project-specific configuration overriding) that can (or even must) be shared among the team members and hence Eclipse project configuration data must be shared together with the Gradle project and source files (unless you accept to miss all these features).
For now, this is the result of my experiments. I'd like to know what you think about it... and I hope I have given my contribution to retain you from evaluating the drop of the "dependency management-enabled" mode in STS