A Gradle build file describes what is needed to build our Java project. We apply one or more plugins, configure the plugins, declare dependencies and create and configure tasks. We have a lot of freedom to organize the build file as Gradle doesn’t really care. So to create maintainable Gradle build files we need to organize our build files and follow some conventions. In this post we focus on organizing the tasks and see if we can find a good way to do this.
It is good to have a single place where all the tasks are created and configured, instead of having all the logic scattered all over the build file. The TaskContainer
is a good place to put all the tasks. To access the TaskContainer
we can use the tasks
property on the Project
object. Within the scope of the tasks
block we can create and configure tasks. Now we have a single place where all the tasks are created and configured. This makes it easier to find the tasks in our project as we have a single place to look for the tasks.
Continue reading →
The IntelliJ HTTP Client is very useful for testing APIs. We can use Javascript to look at the response and write tests with assertions about the response. If an API returns a JSON Web Token (JWT), we can use a Javascript function to decode the token and extract information from it. For example we can then assert that fields of the token have the correct value. There is no built-in support in IntelliJ HTTP Client to decode a JWT, but we can write our own Javascript function to do it. We then use the function in our Javascript response handler to decode the token.
Continue reading →
Last week we had a quick glance of what GPU programming is and what kind of issues it can tackle.
Today, we will dive a bit under the hood and take a look at the logical architecture of modern chips, and show a basic strategy when to migrate part of our code over to the CUDA platform.
Continue reading →
It is good practice in Gradle to use lazy configuration. This makes builds faster as only configuration values are evaluated when needed. We should try to not let Gradle spend time on evaluating configuration values that will not be used. For example tasks that are not executed could still be configured by Gradle. If we make sure the configuration of these tasks is lazy we can save time.
Gradle gives us a lazy way to get the value of a Java system property. In our build script we can use the providers
property of type ProviderFactory
and the method systemProperty(String)
. This method returns a Provider<String>
instance that can be used to get the value of a system property in a lazy way. The method systemProperty
can also be used with a Provider<String>
argument.
Continue reading →
It is good practice in Gradle to use lazy configuration. This makes builds faster as only configuration values are evaluated when needed. We should try to not let Gradle spend time on evaluating configuration values that will not be used. For example tasks that are not executed could still be configured by Gradle. If we make sure the configuration of these tasks is lazy we can save time.
Gradle gives us a lazy way to get the value of an environment variable. In our build script we can use the providers
property of type ProviderFactory
and the method environmentVariable(String)
. This method returns a Provider<String>
instance that can be used to get the value of an environment variable in a lazy way.
Continue reading →
You never touched Groovy, nor did you jump on the Scala train.
Clojure never attracted you; and you heard about Ceylon long after the language had already died.
You are one of those old-fashioned Java folks!
But now, after all those years, you want to join the cool Kotlin kids.
So, where to start?
Let’s discover the language together by decompiling it to Java code.
Today: The things we tend to forget!
Continue reading →
When we use the IntelliJ HTTP Client we can write JavaScript for the pre-request and response handlers. If we want to access an environment variable in JavaScript we can use request.environment.get(string)
. The argument for the get
function is the name of the environment variable we want to get the value for. Environment variables can be defined in the file http-client.env.json
or in http-client.private.env.json
.
Continue reading →
The built-in IntelliJ HTTP Client is very useful for testing HTTP requests and responses. If we want to define a variable in our .http
file that is only used in this file and will not change per environment we can define it using the following syntax: @<variable name> = variable value
. The variable is an in-place variable and the scope of the variable in the current .http
file. The variable is immutable and can only be defined with a value once and cannot be overwritten. To refer to the variable we use the syntax {{}}
.
Continue reading →
Over the last year, there has been quite some fuss over using GPU’s for other
tasks than gaming. News stories about AI and cryptocurrency mining requiring
vast amounts of GPU’s; product shortages in the consumer gaming market are just
a few to name. Share prices for semiconductor design companies, particularly
Nvidia, have been soaring. Yet, on the other hand, there is little
understanding in the general software development community as to how these
techniques work, what class of problems they can solve more effectively, and
how and when to use them.
Continue reading →
The command line option --continuous
or the short version -t
enables Gradle’s continous build. For a continuous build Gradle will keep on running and will re-execute the tasks we invoked if the input or of the input of one of the depended tasks has changed. For a project with the java
plugin we can use this option for the test
task. Gradle will run the test
task and after the task has been executed Gradle will wait for any changes in the input of the task. This means if we change our Java test code in src/test/java
and save the source file Gradle will re-execute the test
task and show the output. But also if the input of other tasks changes, that the test
task depends on, the test
is re-executed. So also changes in source files in our src/main/java
directory will trigger a re-execute of the test
task, because the test
task depends on the compileJava
task, and the compileJava
task has the src/main/java
directory as input.
Continue reading →