Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore[build]: convert facades/PC to gradle to kts #4175

Merged
merged 4 commits into from Oct 20, 2020

Conversation

keturn
Copy link
Member

@keturn keturn commented Oct 2, 2020

This converts the gradle config from groovy to kotlin.

This PR is intended to be a near line-for-line port. Hold any further changes for another branch that won't be so cluttered by the conversion.

blocking #4157, as it needs to make changes to these JavaExec tasks.

How to test

Run gradlew :facades:PC:tasks for the list of tasks.

  • test the Terasology run tasks
  • test the Terasology dist tasks
    • dists should include jar files for all the modules you have sources checked out for in /modules/

Comment on lines 47 to 65
ext {
// Default path to store server data if running headless via Gradle
localServerDataPath = 'terasology-server'
// Default path to store server data if running headless via Gradle
val localServerDataPath by extra("terasology-server")

// General props
mainClassName = 'org.terasology.engine.Terasology'
subDirLibs = 'libs'
templatesDir = new File(rootDir, 'templates')
rootDirDist = new File(rootDir, 'build/distributions')
// General props
val mainClassName by extra("org.terasology.engine.Terasology")
val subDirLibs = "libs"
val templatesDir = File(rootDir, "templates")
val rootDirDist = File(rootDir, "build/distributions")

// Read environment variables, including variables passed by jenkins continuous integration server
env = System.getenv()
// Inherited props
val dirNatives: String by rootProject.extra
val distsDirectory: DirectoryProperty by project;

// Read environment variables, including variables passed by jenkins continuous integration server
val env: MutableMap<String, String> = System.getenv()!!

// Version related
val startDateTimeString = dateTimeFormat.format(Date())!!
val versionFileName = "VERSION"
val versionBase by lazy { File(templatesDir, "version.txt").readText().trim() }
val displayVersion = versionBase

// Version related
startDateTimeString = dateTimeFormat.format(new Date())
versionFileName = 'VERSION'
versionBase = new File(templatesDir, "version.txt").text.trim()
displayVersion = versionBase
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't strictly line-for-line compatible because I only kept some of these as gradle "extra" properties. Most of them I left as local variables.

I don't believe it's a problem for the normal build environment, since there's nothing else in the build that interacts with them, but maybe it could be a concern if something like Jenkins has an alternate configuration that sets or uses them differently?

@keturn
Copy link
Member Author

keturn commented Oct 2, 2020

Reviewing by file on GitHub tells you the .gradle.kts is an entirely new file, but if you review by commit it'll actually show a diff.

@keturn keturn marked this pull request as draft October 3, 2020 17:10
@keturn
Copy link
Member Author

keturn commented Oct 3, 2020

marking as Draft while I fix a couple things with the distribution tasks

@keturn keturn marked this pull request as ready for review October 3, 2020 17:44
@keturn
Copy link
Member Author

keturn commented Oct 3, 2020

I confirmed that the server task writes a config.cfg with the values from -PextraModules and such

and that the dist tasks make their zip files including module jars.

there might be some things involving version files or various BUILD_* environment variables that didn't get exercised in my development environment here.

Copy link
Member

@skaldarnar skaldarnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked over the changes and can confirm this is more or less a direct translation from Groovy to Kotlin DSL. Left a few comments, so please have a look.

I did not test the changes locally, though. Still setting up my system after hardware upgrade...

implementation project(':engine')
implementation group: 'org.reflections', name: 'reflections', version: '0.9.10'
implementation(project(":engine"))
implementation(group = "org.reflections", name = "reflections", version = "0.9.10")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a side note: https://github.com/ronmamo/reflections is available in 0.9.12 now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been for a while, but there are some widely reported issues with 0.9.12 (and some for 0.9.11) so I've been afraid to mess with it.

facades/PC/build.gradle.kts Show resolved Hide resolved

dependsOn rootProject.moduleClasses
dependsOn(":moduleClasses")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, so everything else seems to become more (type-)safe, while you reference the dependency via a plain string there? Is there another way to do this in the Kotlin DSL?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's some tension going on in gradle-config-land. In one direction, you have Kotlin making things more type-safe. In the other direction, Gradle has this configuration-avoidance initiative to do lazy evaluation for certain types of things so it doesn't have to figure out the entire multi-project configuration tree before it's able to run a single task. That's discouraged direct links between sub-projects in many ways.

on second thought, I'm not sure how much the configuration-avoidance API has to do with this specific example.

from Kotlin's perspective, these are instances of Project. Project, as a Class, doesn't have a property named moduleClasses. build.gradle.kts files configure projects but they do not define new classes for each of them. Things like rootProject.moduleClasses only work with dynamic run-time attribute-lookup trickery.

We certainly could say something along the lines of rootProject.tasks.get("moduleClasses") but that's not any different than what we have here in terms of providing assurance that "moduleClasses" is a safe reference.

...and also the Gradle API is really big and provides a bunch of ways to get references to things and I certainly haven't learned everything about what's supposed to be the current best practice.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Long-term, the “safe” way involves not knowing about the tasks of other projects at all. You declare a dependency like "I depend on things from "org.terasology.engine:engine" and need assets of type <Jar> that conform to bytecode_level=JAVA_1_8" or something like that, the dependency-resolver does its thing and checks to see if that project exports anything that matches those criteria.

args "-homedir"
jvmArgs ["-Xmx1536m"]
args = listOf("-homedir")
jvmArgs = listOf("-Xmx1536m")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to make this adjustable in the future via some kind of command line argument...

Comment on lines 373 to 380
configure<IdeaModel> {
module {
// Change around the output a bit
inheritOutputDirs = false
outputDir = file('build/classes')
testOutputDir = file('build/testClasses')
outputDir = file("build/classes")
testOutputDir = file("build/testClasses")
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still need this with the new idea setup introduced recently?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no but no matter how many times people have asked me that none of them have ever removed it 😉

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It can affect gestalt source module loading when you compile and run it via idea.
(And it compability with gradle build, it use same output dir, instead standart build//classes)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

facades/PC/ doesn't have modules in it, so for the stuff that applies only to this sub-project we don't have to worry about the gestalt loader.

facades/PC/server.build.gradle Outdated Show resolved Hide resolved
Copy link
Member

@skaldarnar skaldarnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot start the server, but starting the game and building the distribution works fine! 👍

facades/PC/server.build.gradle Outdated Show resolved Hide resolved
Co-authored-by: Tobias Nett <skaldarnar@googlemail.com>
@keturn keturn merged commit 52a0a52 into develop Oct 20, 2020
@keturn keturn added this to the v4.1.0 milestone Oct 20, 2020
@Cervator Cervator deleted the chore/facade-gradle-kts branch October 25, 2020 01:04
@Cervator Cervator added the Category: Build/CI Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc. label Oct 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Build/CI Requests, Issues and Changes targeting gradle, groovy, Jenkins, etc.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants