Details
-
Type:
Epic
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.11.3.0
-
Fix Version/s: 2.12
-
Component/s: documentation, gradle
-
Labels:
-
Environment:Any build environment (mainly macOS, Linux but should ensure compatibility with Windows)
-
Epic Name:Gradle build refactor
-
Urgency:Urgent
Description
The current build.gradle is too big and unwieldy.
The original gradle build was made to mimic the ant build processes for familiarity. It has grown around that and is now too big to not be embarrassing. Several gradle issues need to be addressed:
sub-projects: There are distinct parts of the build process that could be framed as sub-projects. This will help maintainability and delineation between components of the build process.
gradle 9: Currently we are not gradle 8 or 9 compatible. We should be as this is the latest stable release.
Eclipse/buildship configuration: Our build.gradle contains a lot of code to make up for some of buildships previous shortfalls. Possibly some of these can now be removed or avoided.
gradle wrapper script: This was avoided in the first instance over concerns about compatibility with different OSes and no apparent necessary advantage that it brought. This would be useful and would avoid need for developer to have correct gradle installed (a later gradle will channel an older version with the gradle wrapper).
Directory structure: Again the directory structure was kept largely the same as the ant build process to preserve developer familiarity. build.gradle and gradle.properties could be made simpler by using a default gradle directory structure for source, tests and build artifacts.
Execution optimizations: Not many of these are working as intended since gradle moved up to version 7. These could save a lot of time for developers (probably less so on the build server) so should be fixed.
jalview-getdown as a separate project or even as a separate (linked?) repo?
Java2script as a gradle plugin.
JSTest incorporated.
The original gradle build was made to mimic the ant build processes for familiarity. It has grown around that and is now too big to not be embarrassing. Several gradle issues need to be addressed:
sub-projects: There are distinct parts of the build process that could be framed as sub-projects. This will help maintainability and delineation between components of the build process.
gradle 9: Currently we are not gradle 8 or 9 compatible. We should be as this is the latest stable release.
Eclipse/buildship configuration: Our build.gradle contains a lot of code to make up for some of buildships previous shortfalls. Possibly some of these can now be removed or avoided.
gradle wrapper script: This was avoided in the first instance over concerns about compatibility with different OSes and no apparent necessary advantage that it brought. This would be useful and would avoid need for developer to have correct gradle installed (a later gradle will channel an older version with the gradle wrapper).
Directory structure: Again the directory structure was kept largely the same as the ant build process to preserve developer familiarity. build.gradle and gradle.properties could be made simpler by using a default gradle directory structure for source, tests and build artifacts.
Execution optimizations: Not many of these are working as intended since gradle moved up to version 7. These could save a lot of time for developers (probably less so on the build server) so should be fixed.
jalview-getdown as a separate project or even as a separate (linked?) repo?
Java2script as a gradle plugin.
JSTest incorporated.
