On 10/04/2013, at 2:31 AM, Kris De Volder <kdvol...@vmware.com> wrote:
> Reposted from > http://forums.gradle.org/gradle/topics/obtaining_maven_style_coordinates_for_published_artifacts_via_tooling_api > --- > These questions are in reference to > https://issuetracker.springsource.com/browse/STS-2834 > > This is right now the highest voted issue for Gradle STS tooling. > > As far as I know it is not possible to get information from Gradle Tooling > API about the artifacts that a project creates/publishes. > > I was able to implement something that detects when a given Gradle > dependencies with given version (where version is an instance of class > org.gradle.tooling.model.GradleModuleVersion) corresponds to an existing m2e > project in the workspace. If so then the jar dependency is replaced by the > tools with a project dependency. > > Issue STS-2834 essentially is asking for the same feature to be implemented > for Gradle -> Gradle dependencies (not just Gradle -> Maven). > > I believe that in order to do this we (tools) would need to be able to ask > Gradle tooling API for information about the artifact(s) published by a > project, more specifically, we need somehow to be able to obtain a > GradleModuleVersion for any given Gradle project that publishes a jar with > compiled classes. With this information it would then be possible to remap > Gradle jar dependencies to Gradle projects. 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. 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. > > 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. -- 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
