On 12/04/2013, at 2:34 AM, Kris De Volder <kdvol...@vmware.com> wrote:
> > > > It's not always as simple as matching up the (group, module, version) of a > dependency to the (group, module, version) of a publication. You've also got > to take into account whether the dependency is on a jar whose source is > mapped into the Eclipse project, and whether the project just publishes the > jar from classes built by other projects. > > So, for a completely accurate solution, you need Gradle to be involved in the > mapping. > You are probably right. I think the same is also true for the gradle -> maven > remapping. Nevertheless the people who asked for this feature seem happy with > the simplistic mapping because: > However, matching the (group, module, version) will probably work for 95% of > situations, so it's not a bad option from a practical point of view. > Exactly :-) > > If some people hit the 5% case we can see what can be done to help them. > > > Questions: > 1) Am I correct in assuming this information cannot currently be obtained via > tooling API? > > Yes. > > 2) If 1 => yes, would it be something you would consider adding? > > Yes. > > > 3) Maybe you have a better idea? (I recall a quick discussion about possibly > some way of modeling the IDE workspace and letting Gradle itself do this > remapping). > > I think this is the best solution longer term, and not just because it means > more accurate mappings. It means we know exactly which projects you're > interested in, and so can do things like use configure-on-demand to build the > models for only those projects. This also becomes useful when we start firing > change notifications out of the tooling API, as we can limit what we watch to > only those projects. > > We can go with #2 in the meantime. > Great! Is there an issue to track that? If no, should I open one or will > someone else do it. Could you add an issue? -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com