Announcement Announcement Module
Collapse
No announcement yet.
Dependecies on projects imported from a different Eclipse workspace Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dependecies on projects imported from a different Eclipse workspace

    I'm struggling with two issues in my Eclipse/STS/Gradle setup.

    1. Is it possible to specify a dependency on a project imported in the current workspace from a different one? This means that the workspace directory does not contain the project files and the STS gradle plugin should abstract from the real file locations.

    2. Is there a recommended setup in case of projects split over multiple git repositories? Say that I have:
    repo1/ProjectA depends on ProjectB
    repo1/ProjectB depends on ProjectC
    repo2/ProjectC

    thanks!
    Andrea

  • #2
    > 1. Is it possible to specify a dependency on a project imported in the current workspace from a different one? This means that the workspace directory
    > does not contain the project files and the STS gradle plugin should abstract from the real file locations.

    It depends. Are the projects part of the same gradle multi-project build?

    If yes then currently it is not possible. If a project is imported to the workspace all the projects in the multiplroject build it depends on must also be imported or you will have missing dependencies / compilation problems.

    I beleave the Gradle devs have plans to support this, so that you could only import a subset of projects and then it would automatically model the project dependencies as if they are external jar dependencies. But currently there's no support for this in neither the tools or the Gradle tooling API that our tools are built upon.

    If no (i.e they are separate projects each with their own build scripts)... then the answer is 'yes, sort of'.

    If those projects are separate and one depends (say A) on the other (say B) then really project B should probably build and publish a jar artifact (and probably a source jar as well) to some repository (e.g. local maven repo in your home directory). Project A then needs to declare a dependency on the artifact published by B.

    You need to then build project B and have it publish the jar. The jar will then be usable from project A as one of the jars in the 'Gradle Dependencies' when project A's dependencies are refreshed.

    You may want to read these Gradle docs for some background on dependency managment and publising artefacts:
    - http://www.gradle.org/docs/current/u..._tutorial.html
    - http://www.gradle.org/docs/current/u...anagement.html
    - http://www.gradle.org/docs/current/u...anagement.html

    For your second question... I think the answer is pretty similar. I.e. those projects are 'separate'. So you should probably connect them to eachother by having one project consume artifacts built and published by the other.

    This actually makes sense. Since they are in different repos. They don't get versioned together by your SCM (i.e. git). Say project A depends on B. It possible to make changes to project B that require changes to project A. So it is good practice to be more precise and actually specify what version (or version range) of project B is acceptable/required by project A.

    Kris
    Last edited by Kris De Volder; May 31st, 2013, 11:56 AM. Reason: Spelling / Grammar

    Comment


    • #3
      Hi Kris,

      Thank you for the advices on my question. From your answer I understood that consuming artifacts is the key to solve the kind of situations I'm struggling with.

      My case is the latter of separate projects each with their own build scripts, where one (say A) depends on the other (say B). The reason I wanted to import the project B into A's workspace is that I often modify them in parallel.

      Would it be possible to configure gradle STS so that, when I edit something in project B, Eclipse compile it automatically into the local artifact that A depends on, on-the-fly, without requiring me to run any build/publish task (so that the edits are visible from A)?

      Thanks!
      Last edited by andreab; May 31st, 2013, 09:07 PM. Reason: mistake

      Comment


      • #4
        > Would it be possible to configure gradle STS so that, when I edit something in project B, Eclipse compile it automatically into
        > the local artifact that A depends on, on-the-fly, without requiring me to run any build/publish task (so that the edits are visible from A)?

        No unfortunately there is no support for that. We don't yet have a mechanism in the tooling to 'auto trigger' gradle builds or tasks when resources in the workspace change. This is certainly an interesting/useful feature. In fact there is an open issue on our issue tracker about this.
        You could add your vote to that issue if you want.

        The issue is here: https://issuetracker.springsource.com/browse/STS-2829

        Another feature that has been requested and may help a lot with your use case is this one:
        https://issuetracker.springsource.com/browse/STS-2834

        This essentially ask for some automatic conversion of 'jar' dependencies to project dependencies. That would cut out the need to build the jar altogether. So that would be an even better solution for you use case (and this use case is arguably quite common).

        Unfortunately, this feature can't be implemented yet because it needs some info from Gradle tooling API on published artifacts for a project. When Gradle provides it, implementing this 'remapping' feature will be high on my priority list.

        Unfortunately presently there's really nothing I can recommend to automate things better. You'll have to run the tasks manually to publish jars when you make changes to a project.
        Last edited by Kris De Volder; Jun 3rd, 2013, 11:36 AM. Reason: Referred wrong STS issue ticket.

        Comment

        Working...
        X