Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2834

Detect Gradle project dependencies to other Gradle projects located in workspace and ...

    Details

    • Type: New Feature New Feature
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0.RELEASE
    • Fix Version/s: None
    • Component/s: GRADLE
    • Labels:
      None

      Description

      This a variant of issue STS-2405 for project dependencies between
      Gradle projects (rather than between maven and Gradle projects).

      Another variant is STS-2836

        Activity

        Hide
        Kris De Volder (c) added a comment -

        Will take another look at this in 3.2.0 timeframe. I don't think I'll be able to implement something yet, but the goal is to at least get a better idea on what's needed and lodge a tooling API extension request.

        Show
        Kris De Volder (c) added a comment - Will take another look at this in 3.2.0 timeframe. I don't think I'll be able to implement something yet, but the goal is to at least get a better idea on what's needed and lodge a tooling API extension request.
        Hide
        Kris De Volder (c) added a comment -
        Show
        Kris De Volder (c) added a comment - Gradle forum and dev-list discussion relevant to this issue here: http://forums.gradle.org/gradle/topics/obtaining_maven_style_coordinates_for_published_artifacts_via_tooling_api
        Hide
        Gethin James added a comment -

        Thanks Kris for pursuing this through the various Gradle forums/mailing list/issue tracker.
        You asked for the tooling information so you can "remap Gradle jar dependencies to Gradle projects". I'm wondering if a common case would be the other way round, ie. remapping Gradle project dependencies to jars?

        In a typical multi-project build it would be common to have several Gradle project dependencies. I think I'd like to import individual projects into STS (and not have to import every Gradle project dependency at the same time). If STS encountered a project dependency then it could remap it to a jar dependency? If you subsequently import the dependent project then it would no longer do the remapping.

        I believe this is how the maven plugin works! It sounds quite complicated, does that make sense?

        Show
        Gethin James added a comment - Thanks Kris for pursuing this through the various Gradle forums/mailing list/issue tracker. You asked for the tooling information so you can "remap Gradle jar dependencies to Gradle projects". I'm wondering if a common case would be the other way round, ie. remapping Gradle project dependencies to jars? In a typical multi-project build it would be common to have several Gradle project dependencies. I think I'd like to import individual projects into STS (and not have to import every Gradle project dependency at the same time). If STS encountered a project dependency then it could remap it to a jar dependency? If you subsequently import the dependent project then it would no longer do the remapping. I believe this is how the maven plugin works! It sounds quite complicated, does that make sense?
        Hide
        Kris De Volder (c) added a comment -

        Yes, it makes a lot of sense. I even think that Gradle folks are thinking about stuff like that. I can't point you to a online discussion about this, but I recall a conversation with Hans where he talked about being able to import project subsets and Gradle would choose if a project dependency should be 'jar-ified' to treat it more like external dependency in such a case.

        So, yes, that does make sense. It does however not seem like something that would be easy/possible to implement on the tooling side. It will need some way for the tooling to specifiy the subset of projects they are 'interested in importing' and then it would be up to grade to ensure jars are built for the other projects.

        The tools by themselves don't really have a way of finding or creating the 'substitute' jar.

        This kind of feature would require tools and Gradle to 'cooperate'. Tools need to tell Gradle what projects they want to see as projects in the workspace... and Gradle needs to do the work to create the jars for the others.

        Show
        Kris De Volder (c) added a comment - Yes, it makes a lot of sense. I even think that Gradle folks are thinking about stuff like that. I can't point you to a online discussion about this, but I recall a conversation with Hans where he talked about being able to import project subsets and Gradle would choose if a project dependency should be 'jar-ified' to treat it more like external dependency in such a case. So, yes, that does make sense. It does however not seem like something that would be easy/possible to implement on the tooling side. It will need some way for the tooling to specifiy the subset of projects they are 'interested in importing' and then it would be up to grade to ensure jars are built for the other projects. The tools by themselves don't really have a way of finding or creating the 'substitute' jar. This kind of feature would require tools and Gradle to 'cooperate'. Tools need to tell Gradle what projects they want to see as projects in the workspace... and Gradle needs to do the work to create the jars for the others.
        Hide
        Kris De Volder (c) added a comment -

        Gradle issue blocking progress on this issue: http://issues.gradle.org/browse/GRADLE-2750

        Show
        Kris De Volder (c) added a comment - Gradle issue blocking progress on this issue: http://issues.gradle.org/browse/GRADLE-2750
        Hide
        Lance added a comment -

        FYI, the blocking issue GRADLE-2750 has been fixed in gradle (trunk) and will be available in the next release (gradle-1.12)

        Show
        Lance added a comment - FYI, the blocking issue GRADLE-2750 has been fixed in gradle (trunk) and will be available in the next release (gradle-1.12)
        Hide
        Kris De Volder (c) added a comment -

        Yes, thanks for the info. Removing the 'toolingapi-blocked' tag from this issue now.

        Show
        Kris De Volder (c) added a comment - Yes, thanks for the info. Removing the 'toolingapi-blocked' tag from this issue now.
        Show
        Lance added a comment - http://www.gradle.org/docs/release-candidate/release-notes#tooling-api-exposes-information-on-a-project's-publications http://www.gradle.org/docs/release-candidate/javadoc/org/gradle/tooling/model/gradle/ProjectPublications.html

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Kris De Volder (c)
          • Votes:
            24 Vote for this issue
            Watchers:
            25 Start watching this issue

            Dates

            • Created:
              Updated:
              First Response Date: