Passing information from project to subprojects using Kotlin

Help/Discuss
1

I have a project that contains several subprojects. Each subproject is a java-library.

rootProject.name = "MoneydanceGradle"
include("mrbutil")
include("SecurityQuoteLoad")

I need to have configurable classpath that is used by all subprojects. I have tried to declare variables in the main project and use them in the subprojects but I am finding it difficult to understand which approach to use.

According to this post https://discuss.gradle.org/t/settings-properties-define-variable-use-in-root-project-of-multiproject/6852 I should use the gradle object. This post uses Groovy, I am using Kotlin.

Would the Kotlin equivalence of ‘gradle.ext.foo=“bar”’ be ‘gradle.foo by extra(“bar”)’?

I will be executing the subprojects on an individual basis, e.g. ‘gradlew :securityquoteload:jar’ which means the build.gradle.kts file of the main project is not processed. Can I put the definition of the variables in settings.gradle?

Any help appreciated
Thanks

2

That post you refer to is 10 years old, so chances are very high the information is obsolete as Gradle is pretty evolving. :slight_smile:

You should practically never use ext or extra properties.
They are almost always just a work-around for not doing things idiomatically.
Each time you use them, you should feel dirty. :smiley:

If you want to share build logic among several projects in the build, you should use convention plugins, for example implemented as precompiled script plugins.

3

Thanks @Vampire, i have infact built a script under buildscript which sets the common info which is present for all subprojects.

It is quite interesting to learn Gradle. The user manual and tutorials are OK but they specify api artifacts through links, some of which doen’t exist or delve into the class definition without much explanation. I therefore go to google which normally ends up at Stack Overflow or some times this forum.

Anyway, thanks for your time.
Mike

4

The user manual and tutorials are OK

Imho they are even pretty good, especially as doc for a software, but ymmv of course. :smiley:

but they specify api artifacts through links, some of which doen’t exist

I don’t get what you mean.
Can you elaborate?
Maybe it is a doc bug that should be reported / fixed, or maybe you just misunderstood something.

or delve into the class definition without much explanation.

In the samples this is maybe sometimes the case, but the docs should explain things pretty detailed usually. If some part is too unclear, I recommend you open a feature request to make some part of the docs more clear or understandable, so the Gradle folks eventually can improve it.

I therefore go to google which normally ends up at Stack Overflow or some times this forum.

Yeah, well, both of these sources need to be considered with a grain of salt, as well as blog entries. Especially you have to consider the age / version of Gradle for which they are. And some bad practices like ext usage have very wide-spread usage but are seldomly the “proper” way. :slight_smile:

5

Hi @Vampire, don’t get me wrong on the documentation, it is good for OpenSource. I have been going through it trying to understand Gradle and have run into issues. Sometimes the documentation introduces terms without any explanation, for example in Command Line Interface, Project Reporting mentions Task Groups, this hasn’t been described. There are other examples of this and it makes me think I am missing some prerequisite knowledge.

On the ‘links doesn’t exist’ I clicked on a link and got a html 502, I will try to find it again and report as specified.

Using the online version of the manual I can only search within the page so I also have the PDF version in which I can search the whole manual, unfortunately the PDF version does not match the online version. A detailed Index would be useful.

I will starting noting the issues and raise them as you suggest. Anyway moving on, the next issue is placing resources into non-standard directories within a jar.

7

I have been going through it trying to understand Gradle and have run into issues.

If that is the case, I recommend opening a feature request or pull request to improve the docs, so that the next reader might have a better experience. :slight_smile:

Sometimes the documentation introduces terms without any explanation, for example in Command Line Interface, Project Reporting mentions Task Groups, this hasn’t been described.

But they are described right there, aren’t they?
I mean, you certainly do not describe what a “group” is and that a “task group” is a “group of tasks” seems just too natural to me.
It talks there about gradle tasks where when you execute it the groups are shown.
It also shows an example of how to list the tasks of a specific group, which should also make it easier to correlate the term to the output.
And it also shows right after that, you can also see the task group in the help task output for a specific task.

On the ‘links doesn’t exist’ I clicked on a link and got a html 502, I will try to find it again and report as specified.

A 502 can have many reasons, from a bad proxy configuration, over some misconfigured firewall, or unhappy virus scanner, …
Most of these are way before you even hit any Gradle server.
So if you get a 502, just try it again a bit later, or try to find out where the 502 is actually coming from.
Most often this is not caused by Gradle servers.

Using the online version of the manual I can only search within the page so I also have the PDF version in which I can search the whole manual, unfortunately the PDF version does not match the online version. A detailed Index would be useful.

The same as the PDF version should be available as online as Gradle User Manual: Version 8.4. But both have the problem, that some of the single-page pages are not included unfortunately, which is reported at Improvements for the single-page documentation. · Issue #16760 · gradle/gradle · GitHub and hopefully gets fixed some day.
The search box on the online docs in the upper left if you use the /current/ docs and not a version specific on is usually quite good though to find things that are missing from the single-page version.

Anyway moving on, the next issue is placing resources into non-standard directories within a jar.

Just configure the jar task as you need it. Or maybe better configure the processResources task, so that not only the jar but also other task needing resources finds them where they need to be like the run task if you use the application plugin for example.

8

I suggest we leave the documentation issue as we have our own views, thank you for all of your suggestions. I am sure as I work it out the documentation will become clearer.

On the position of resources I have put the following:

sourceSets {
		main {
			resources {
				srcDirs ("src/main/java/com/moneydance/modules/features/"+project.name+"/resources")
				output.resourcesDir = file ("build/classes/java/main/com/moneydance/modules/features/"+project.name+"/resources")
			}
		}
}

That puts the resources where I want them, i.e ‘com/moneydance/modules/features/“+project.name+”/resources’ however it also puts them into the root directory of the jar. Not an issue just wasteful. I will try using a copy task.

9

That’s a thing you should definitely not do.
Besides that the output... line belongs one level up,
you configure a directory that is within the output directory of the compileJava task and thus created tasks with overlapping output, which is one of the worst things you can do.

You disturb up-to-date checks, might end up with stale results, wrong cache entries, and so on.

10

You probably want something like

sourceSets {
    main {
        resources {
            srcDirs("src/main/java")
            include("com/moneydance/modules/features/${project.name}/resources/**")
        }
    }
}