@Kris your idea seems to me very clean and reasonable. Please take also a look at documentation for IvyDE "Dependencies resolution in workspace" feature as additional "inspiration" ( http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/workspace.html ). What we are discussing about somewhat resemble that feature.
Cheers Davide PS: they also has so e support for WTP projects ( http://ant.apache.org/ivy/ivyde/history/latest-milestone/cpc/wtp.html ) but I just thaven't tested it (not yet). kdvolder wrote: > > 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. > > -- 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-tp4497854p4505525.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
