Hi Davide, Took a quick look at the page you are pointing to. It seems like a nice feature to have. I agree that the user experience editing across projects will be much better if Eclipse understands project dependencies rather than have '.jar' dependency.
As I was trying to explain however, it is currently not possible to implement this. The knowledge to know that some jar was produced by another project in the workspace (and could be replaced with a project dependency is not available to STS/Eclipse, because the tooling API doesn't expose enough information about projects / dependencies. IvyDE can do this because they have full access to all this info from Ivy. So to implement this for Gradle, we'd need an extension of the Tooling API. So, I can't do this alone. I'll put some more thought into it and raise a Gradle Jira request for the API extension. Without the info coming from Gradle, I could implement something that lets the user manually remap some specific jars to project dependencies. (Essentially, provide a UI so that the user can provide the requisite knowledge, lacking a way to extract it from Gradle itself). It may be something to consider, since it would be flexible in letting users customize this remapping, but if you have many project's, I can't imagine it being fun to have to manually declare all these remappings (especially, if you know that the knowledge is already essentially encoded in the gradle build files). If you, or other people on this list, think that the 'manual remapping' would be worth the effort. Go ahead and raise an STS Jira for it. We can then take the discussion further on the respective Jiras and off of this mailing list. Kris ----- Original Message ----- > @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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
