It seems that this could be very useful. (Davide is not the first person I see asking this kind of question :-).
It seems to me that neither Gradle nor the IDE is in the perfect position to do this right... but if Gradle and the IDE work together we may be able to get a nice solution. What I'm thinking is, an "ExternalDependency" as returned by the Gradle project model in the tooling API should have some type of identifying 'key' associated with it (similar to how maven etc. identify/resolve deps). Also a project should have this type of identifier associated with it (i.e. the key it uses to 'publish' to the repo). Then when we update/refresh dependencies, we can check whether projects that exist in the IDE workspace match those returned by "ExternalDepencies" and then represent those as project dependencies instead of jar entries in the classpath container. I'm almost certain that Gradle already has all this info... but it isn't available from the tooling API. If it were, then it would be pretty easy to for the IDE to 'connect the dots' so to speak, because the IDE knows what the user has in their workspace. Kris PS: Yes, it seems also like a good idea suggested by Szcepan to make something in the IDE that lets a user declare that some project corresponds to some jar and do these changes... but it more or less means the user has to use some GUI tools to basically redeclare for the IDE what Gradle builds scripts already declare for Gradle builds. So while its better than nothing (and something I'm really considering now :-) I think we can do better than that. ----- Original Message ----- > Since I'm refactoring our modules and transforming each of them in a > single > gradle project, I started considering them as single projects and > linking > them only through compile dependencies. > At a certain point I thought I'd have to switch to a multi-module > build and > search for a way to obtain optional project dependencies (in a > scenario > where a developer checked out some modules and wants to modify them) > while > the scenario where the developer didn't checkout only a certain > module and > wants to resolve its dependencies through the dependency manager was > always > covered by the maven repo. > Now: it's clear that I've not read enough about project > deps/multi-module > builds, but from your words I guess adding mavenLocal() to > repositories and > invoking the install command should be enough to share a packaged > artifact > in a local repo. The missing bit would be a way to automate the call > to > install command on save from IDE. Maybe STS has enough hooks fo that. > I'll > take a closer look. > > Cheers > Davide > > Szczepan Faber wrote: > > > > > > Not sure what specifically would you like to know :) Consider a > > large, > > hierarchical project consisting of 50+ modules. It should be easy > > to > > check out / work with / build only the selected subproject(s). This > > may mean the 'project dependencies' are satisfied via some repo > > instead of being a part of a multi-module build run. > > > > > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/Is-it-possible-to-elect-a-local-gradle-project-to-satisfy-other-projects-deps-tp4497854p4499287.html > Sent from the gradle-user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
