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.
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
Issue Links
- blocks
-
JAL-4644 Refactor directory structure of Jalview development tree to match modern gradle expectations
-
- In Progress
-
- mentioned on
(4 mentioned on)