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

Reply via email to