Not using a root project

I frequently create projects without a root project. I’m not aware of any downsides to doing this but it occurs to me that there might be some. My premise for not using root projects is that I prefer projects that just do one thing and have only one reason to change (SRP for those who care). I realize that 99% or more of the industry probably use root projects because they also use more than one content module or that’s just how it is done. And this sets up the dilemma: “when in Rome” vs “SOLID”; which one is better for independent developability and deployability. I am comfortable bucking the trend unless there is some crucial technical reason why not having a root project can cause a serious problem.

I frequently create projects without a root project.

That’s, well, let’s call it quite unlikely.
Because this is impossible.
You always have a root project.
It might be empty and without a build script.
But nevertheless it will always be there.

I’m not aware of any downsides to doing this but it occurs to me that there might be some.

Afair, only that it imho is non-sense to create a subproject just for the fun of it, unless you have a reason to do so. But that is more a style- and preference-question.

My premise for not using root projects is that I prefer projects that just do one thing and have only one reason to change (SRP for those who care).

I don’t see how these tow sentences halves have anything to do with each other.
Where is the difference whether you have something in the root project or in a subproject?
Given it is the same content, it should not change anything at all regarding SRP.

And this sets up the dilemma: “when in Rome” vs “SOLID”; which one is better for independent developability and deployability. I am comfortable bucking the trend unless there is some crucial technical reason why not having a root project can cause a serious problem.

I don’t understand the dilemma, nor the “better for” qualifiers.
What difference does it make whether you put your stuff into the always existing root project,
or into a subproject, besides that you have a useless parent project that just does nothing?

@Vampire how would you describe a Gradle project that has one build.gradle.kts file, one settings.gradle.kts file and one source set folder and some boilerplate Gradle files? To me, this is a Gradle project without a root project. I’m guessing you see it as only a root project. Good guess?

Depends on the contents of the settings script.
If it has no include(...) statements, then it is a build with one project which is the root project.
If it has any include(...) statements, then it is a build with +1 projects, no matter how many build scripts physically exist.

If what you meant was that you usually put your stuff directly to the root project and do not put it into a subproject, then the question where the difference should be remains, just that in my opinion it is the setup that makes more sense. If other projects instead put their stuff into a subproject, this is probably because the init task nowadays tends to create it in that layout and many tutorials are using that layout. Probably because it is easier to add sibling projects in the future without needing to move the stuff from the root project to a subproject. But imho that is non-sense and I just do the move if really necessary.

@Vampire I did in fact mean that I usually put stuff into the root project and that there are no subprojects, which is to say that I do not follow the recommended Gradle setup. The question I should have asked is: what are the consequences, if any, of not following the recommended Gradle setup, i.e. having only a root project with a settings file, a build file, boilerplate files and a single source set containing main and test folders for Kotlin source files?
My experience is that there are no consequences in any of the hundreds of such projects I have created. But that does not mean that there will be no consequences so I have reached out to the Gradle community to see if any leaders or experts in this community can definitively answer my question. A corollary question might be: while my approach works fine now is there any reason to fear Gradle might change in the foreseeable future to require at least one subproject?

I did in fact mean that I usually put stuff into the root project and that there are no subprojects

Great, then as I said, you imho do the exact right thing. :slight_smile:

which is to say that I do not follow the recommended Gradle setup.

Where is this recommended?
It is afair just the init task that with some settings creates such a structure.
And afair it is just to make it easier to add sibling projects in the future which in my opinion is not a strong enough reason.

The question I should have asked is: what are the consequences, if any, of not following the recommended Gradle setup

You are following the setup I recommend if you only need and have one project.
I’m not aware of any practical drawbacks in any regard.
This is mostly just a question of preference.

A corollary question might be: while my approach works fine now is there any reason to fear Gradle might change in the foreseeable future to require at least one subproject?

I’m not authorative, but I could not imagine a single reason why such a change should ever be even considered.

That’s the answer I was looking for. Thank you.

Here’s the quote from the Gradle User Guide on the recommended project structure I alluded to previously.

1 Like

Here’s the quote from the Gradle User Guide on the recommended project structure I alluded to previously.

Ah, right, forgot that they added that (imho questionable) recommendation. :smiley:
And if I use the init task, I usually use --type basic or --use-defaults which do not follow that recommendation yet, but just produce an empty build script and settings script in the root project, so exactly what the two of us like to have. :slight_smile:

That’s the answer I was looking for. Thank you.

And even if they would make such a change, it would probably be quite easy to just move all stuff one directory down, add the include in the settings script, and be done basically.