[GRADLE-348] Let the name of the build script determine the name of the project Created: 05/Jan/09  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Improvement
Reporter: Hans Dockter Assignee: Unassigned
Resolution: Won't Fix Votes: 2

Issue Links:
Related to GRADLE-777 rename build.gradle Resolved
Related to GRADLE-335 Gradle Hudson plugin issue Resolved


This would also make it easier to work with multiple gradle build scripts in an IDE.

Comment by Jon Cox [ 23/Jan/09 ]

It might be more useful to let the project directory's name
be the default name of the project.

Comment by Adam Murdoch [ 23/Jan/09 ]

That is what we do right now. The main problem with this approach is that often the user does not have control over the name of the root directory, such as when the build is being executed by a CI server.

In addition, using the file name would encourage people to call their build files something other than build.gradle, which I think is a major goodness.

Comment by Jon Cox [ 24/Jan/09 ]

The CI server angle was something I hadn't considered.
Thanks for the info.

Comment by Mathias Kalb [ 07/Jan/11 ]

Is it possible to use the subproject name as a part of the "build.gradle" name.


This should be optional.

Comment by Sandu Turcan [ 03/Apr/11 ]

I sort of like the simplicity of the current naming convention.
If the build file has to be the same as the project name, then how do you have a project named 'settings' or 'init'?

Comment by Hans Dockter [ 04/Apr/11 ]

This is only what the default should be. Right now you can already set the build script names to be the project names. You can use the settings.gradle for this. Our idea is to apply this as a default pattern only for subprojects. So there would be no name conflict with the root build script name, which would be still build.gradle. In any case, whether we will do this is not decided yet. And if we change it, you will always be able to easily switch back to the current behaviour.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:27:52 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.