[GRADLE-2341] unify gradle.build and settings.gradle? Created: 08/Jun/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-rc-3
Fix Version/s: None

Type: Improvement
Reporter: wujek srujek Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

So there are three files: build.gradle, settings.gradle, and gradle.properties. Whereas I can understand that the latter deals with settings for the whole build system, I would like if build.gradle and settings.gradle could be unified.
An example of why I think it's confusing now is setting project name and its version:
1. you have to use settings.gradle, otherwise the project directory will be used as the name - different users might check out projects in different directories, so it is not really unique
2. you have to set the version in build.gradle

In contrast, maven allows me to configure the groupId, artifactId (name) and version all in one central place. (Mind that I don't hold maven config as the role model, it's just that this particular issue is handled by it better, IMHO.)

 Comments   
Comment by wujek srujek [ 15/Jun/13 ]

Hi. It's been a year without as much as a comment. What do you think about such unification?

Comment by Andreas Tschabuschnig [ 16/Sep/13 ]

I can see, that having here multiple files might be strange, but keep in mind, that the settings.gradle file gets read and executed in a different phase than the build.gradle file. Therefore you would need to have a separate block within the build.gradle file, which defines the settings. Additionally the settings.gradle file is used to identify the root project. Not having a settings.gradle file would mean having to read (and analyze) every build.gradle file just to check if it is also a "settings" file.

As you can see, the settings.gradle file is more than just another build file and the proposed change would mean major refactoring. Also the name of a project should never (or only rarely) change anyway, putting it in a separate file could actually be an advantage

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 12:19:16 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.