Uploaded image for project: 'Jalview'
  1. Jalview
  2. JAL-4676

Eclipse IDE detecting circular dependency in refactored gradle sub-projects

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Ready for testing
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: gradle
    • Labels:
      None

      Description

      The refactoring of gradle (and the entire repo) to use sub-projects has led to Eclipse/buildship (incorrectly) detecting a circular dependency between the jalview-app and getdown-core sub-projects.

      This is because Eclipse only sees dependencies at the project level, and not at the sourceSet/artifact level.

      The gradle refactor had separated out the main Jalview application into a sub-project jalview-app.

      It had also *introduced* our slightly bespoke getdown-launcher into a new set of sub-projects (getdown-core, getdown-launcher, getdown-ant) which are tightly based on the getdown maven structure.
      These are now compiled as part of the build process. Previously the jars were compiled when changes to getdown had been made, and copied into the old j11libs folder.

      Only getdown-core.jar is used by jalview-app, and only in a very small way.
      [The main use of getdown is the getdown-launcher.jar which is practically a standalone launching application packaged with Jalview in the jalview-launcher sub-project.]

      We have bespoke code added to getdown-core and getdown-launcher.
      [Aside: at some point this should be completely devolved so we can go back to using getdown straight as it is, with perhaps a class or two wrappers]
      Some of this bespoke code is re-use of code in certain Jalview classes, e.g.
      jalview.bin.GetMemory, jalview.bin.HiDPISetting, jalview.util.LaunchUtils, ... (you can see the full set by looking at the `launcherUtils` sourceSet found in `jalview-app/build.gradle`).
      These classes can compile without the rest of Jalview present.
      In order to avoid duplication, they are defined in a separate sourceSet called launcherUtil in jalview-app, and the jar product of these are then set as a dependency for getdown-core.

      Jalview itself uses the getdown-core classes simply for:
      1) Swapping a new version of getdown-launcher.jar into place [getdown-launcher can't do this itself]; and
      2) Looking up the user-space appdir to use. This is bespoke code we added to getdown.

      This means that getdown-core depends on *some* classes from jalview-app, and jalview-app's main sourceSet depends on getdown-core (but only in a very limited way).

      Whilst this compiles quite happily by gradle on the command-line, Eclipse/Buildship only sees the project level dependencies and so classes this as circular.

        Attachments

          Activity

            People

            Assignee:
            soares Ben Soares
            Reporter:
            jalviewadmin Jim Procter
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: