Obtaining maven-style coordinates for published artifacts via tooling API

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Obtaining maven-style coordinates for published artifacts via tooling API

kdvolder
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.
 
Questions:
1) Am I correct in assuming this information cannot currently be obtained via tooling API?
2) If 1 => yes, would it be something you would consider adding?

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).

If it were up to me I would go for option 2 right now. This seems the easiest thing to implement and also makes it 'symmetrical' with how we already handle maven projects. Also the feature can be configured or turned on-off via IDE UI preference pages. But we can certainly discuss about this.

Kris

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Obtaining maven-style coordinates for published artifacts via tooling API

Adam Murdoch

On 10/04/2013, at 2:31 AM, Kris De Volder <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Obtaining maven-style coordinates for published artifacts via tooling API

kdvolder




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
Reply | Threaded
Open this post in threaded view
|

Re: Obtaining maven-style coordinates for published artifacts via tooling API

Adam Murdoch

On 12/04/2013, at 2:34 AM, Kris De Volder <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: Obtaining maven-style coordinates for published artifacts via tooling API

kdvolder
Issue: http://issues.gradle.org/browse/GRADLE-2750


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