Today I saw the following message printed by Gradle for one of our CI builds set up on a Jenkins server:
The name ‘Gradle Tools CI build’ contains at least one of the following characters: [ , /, , :, <, >, ", ?, *, |]. This has been deprecated and is scheduled to be removed in Gradle 5.0
Guys, this is 2017, not information-technical Stone Age. You are telling me that I can’t use a space in the name of a build?!
We are trying to make domain object names in Gradle a bit more identifier-like, to fit better into the Groovy and Kotlin DSL. You can of course still put spaces in your folder names, but I recommend explicitly setting the rootProject.name in your settings.gradle file to be independent from the folder you check out in, e.g. rootProject.name = 'gradle-tools'.
Wow. When I wrote this posting it appeared to me as a minor issue. Given your reply I realize it has the potential for a larger discussion. Let me explain.
I think the “problem” starts with the fact that (a) Gradle derives a project’s name from the folder name by default and (b) that most file systems allow us to use characters (such as a space) as part of file/folder names that must not be used if such a name is taken as a (Groovy/Kotlin) programming language identifier (because of syntactic constraints on language identifiers that are more limited than syntactic constraints on file system names). This is implicit knowledge that is documented where exactly? In fact, I consider this as what is sometimes called technical debt. If you want to become more identifier-like, have you thought about approaching this from the opposite end: break the default of taking the folder name as the project name and instead make it mandatory to specify the property rootProject.name (or project.name?). This would make it clear that the folder in which a Gradle project is stored may very well have a different name than the name property. And as part of the documentation of the name property one can easily add that it must satisfy the syntactical constraints of a Groovy/Kotlin identifier.
On the other hand, what precisely is the advantage of becoming more identifier-like?
Usability mostly, e.g. consider a user trying to invoke a task in a project with a space in it. gradle projectName:taskName wouldn’t work anymore, you’d have to do escaping around the project name, which quickly becomes awkward.
I agree with the rest of your analysis, the folder name default bothers me too. It’s not quite as easy as “just failing”, because there are valid use cases where you can’t have a name yet (gradle init) and there are lots of builds out there that don’t define a name, so this would need a deprecation cycle.
We’ll consider both that alternative as well as allowing spaces again and get back to you once we’ve made a decision.
Well, no. Escaping is one of the oldest things in programming. Every decent programmer is aware of that and knows “hey, if I’m desperate about special names, I need escaping sooner or later”. I do not consider this a valid argument. Actually, escaping is nice because it provides a way to be desperate about names 
Sure. You can probably imagine that my proposal was an idea from the top of my head, rather meant to widen perspectives than to provide a complete solution.
To come back to the issue, please provide a way to be not limited to syntactic constraints of programming language identifiers when it comes to names.
Can you please provide a use case for that requirement? Assuming rootProject.name was mandatory, why would you choose a project name with space in it? Or asked the other way round: If Gradle never allowed spaces in names in the first place, what problem would allowing white spaces solve?
The use case is “I want to use a name outside the restrictions imposed on Groovy/Kotlin identifiers.” For instance, using Cyrillic, Mandarin, Arab, or other non-latin letters. (On a related thread: there are programming languages that allow using Unicode for identifiers; for instance, Haskell.)
Gradle would just be more liberal about names.
I just got bit by this “feature” too. What’s going on people? The release notes for 4.2 do mention there’s a change in the convention (see https://docs.gradle.org/4.2/release-notes.html#path-separator-characters-in-names-are-deprecated) however it does not offer an alternative; the official documentation has not been updated either (see https://docs.gradle.org/current/userguide/build_lifecycle.html#sub:project_locations).
What am I supposed to do with the Griffon build (and many other multi-project bulds) where I’ve setup modules in a two-level directory strategy? (see https://github.com/griffon/griffon/blob/development/settings.gradle).
Am a big fan of Gradle builds but recent changes have made me question how often should I update Gradle on my builds. On one side you get face slaps like this in small increments when upgrading to minor releases, on the other side you get a huge migration ahead when switching between major releases.
@Andres_Almiray This is exactly the kind of thing we had in mind (the use of / in a project name). This is a mistake people make and it causes other problems elsewhere (in tools that expect project.name == an identifier, like Eclipse). The release notes should have explained why we did what we did and not just what we deprecated, but that slipped through our review process.
It looks like this is a bug with the way we validate the project names anyways. You shouldn’t get the warning since you change your project names to something valid. I opened https://github.com/gradle/gradle/issues/3008
The include method takes the logical path of the project. The physical path is inferred from this automatically, but can be adjusted as needed. See my comment on the issue that Sterling opened.
These are allowed and will remain being allowed.
Sorry. I wasn’t aware that Java supports Unicode for identifiers 
What should I do in case of multi-module Gradle Project.
Where and how to specify the sub-project’s name?
Just FYI we have removed the space deprecation in Gradle 5.0. All the other forbidden characters are now errors.