----- Original Message ----- > 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. Kris
