-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide alternative for flat project structure #18644
Comments
Would it be an option to make the planned optimizations with respect to file watching dependent on the condition that no such projects are included? I'm happy with the performance that Gradle offers today, but I have a big problem if this feature goes away. The general use case that I outlined in #13891 was this: I have projects A and B and a common project C. All of these projects live side by side in the same VCS repository. A and B include C in their settings files. In this way, C becomes a fully integrated part of both A and B. This allows me, for example, to traverse the tree of project dependencies and collect output directories for a fat JAR file. Also, I can depend on different configurations of a project. Many other similar use cases for tightly integrating with a project are not possible with a composite build. |
I just see one option for me.... I will not update gradle version to 8. My projects will stuck in version 7. |
@ingokegel Based on your #13891 (comment), the source of the problem is that project |
@donat Yes, that is entirely correct. |
Apart from the duplicate resource problem Stefan mentioned, can somebody give me concrete examples of how Eclipse handles flat project structures better? |
What I see in a project I sometimes contribute too, which uses Maven and git in a hierarchical project structure, is that, apart from the duplicate resource problem, SCM decorations are inherited by the root project. If you have the flat structure, instead, the master project only shows outgoing changes if there are indeed changes in master or in any of its subfolders, of course. |
A little FYI. The problem with duplicate entries in the resources dialog seems to be fixed in Eclipse 4.18: https://bugs.eclipse.org/bugs/show_bug.cgi?id=568780 |
@donat I tried to follow the "duplicate" chain for that bug, I think the most relevant is https://bugs.eclipse.org/bugs/show_bug.cgi?id=490899, which is however marked as a duplicate of the one you're pointing to. But I'm a bit confused on how a releng bug for ECF could fix this? :-\ I'm clearly missing something. Also, I find the following bugs are still open: |
I need some advice on how to prepare for Gradle 8 with these changes.. Our project structure looks something like this: Right now I use a reference in our settings.gradle for something in group1 or group2 to access the libs in /libs/, like: and this works fine and imports great into Eclipse/VSCode. How exactly do I get this working with a composite build? Do I need to do something with symlinks (is that even possible?). The group1 and group2 of code is a separate group of services from each other, but they use code in our shared libraries and we use local references. Some help would be appreciated since this is a bad enough issue we won't be able to move to Gradle 8. |
Quick Search however still has the duplicated resource problem: https://bugs.eclipse.org/bugs/show_bug.cgi?id=559340 |
Please do NOT remove the flat project structures. |
At least, not so fast!!!! Please reconsider doing that in a further version!!! |
tl;dr -- this breaks multiple repository support.I became aware of this today. Sorry for the long post. We have a couple of large projects that revolve around this functionality. Removing this would be a nightmare for us and require a re-architecture of our project build structure. We're using gradle 6 currently. Let me try and describe our setup. Our build system and developers are using the same gradle files. We use individual gradle projects for the CI build system and then "umbrella" gradle projects set up as multi-project builds for development, using dependency substitution for source replacement. We also have a common standard set of custom utility jars and 3rd party things that both of these segments use as dependencies. Importantly, our source code is in multiple repositories, which I think is the biggest miss here. My concerns... First, as of last summer IntelliJ didn't yet have good enough support for composite builds -- we couldn't get our projects to compile properly this way due to I think the way IntelliJ imported gradle. While a bit of a tangent, it is ominous that current functionality is already deprecated in 7.x and slated for removal in 8.0 before we've been able to get composite builds even working in our more advanced setup. It's on our list to revisit because this seems to be the way things are progressing. Second, multiple repository support. Using a project with multiple repositories all under a single root means you are forced to integrate your version control system into your gradle project setup. For example, something like this is an issue:
Another multi-repo example (that we also do) is an independent, but also in-house, set of libraries. These are versioned and maintained independently, yet may be needed for debugging or need related source changes within the same project for new features or fixes. Our current developer builds can optionally include source or artifacts for these depending on their local setup. This change breaks that ability as the file hierarchy is now forced. Finally, let me try and give you an overview of the folder hierarchy we are pulling all together in our core project. It's not an ideal setup but it's been fine. Here is the basic directory structure: // dev/group/mainGroup/* our "umbrella" root project is in the mainGroup folder. It looks for source in the other folders, each of these having one or more repositories which themselves possibly have multiple projects in them. Some of the root build dependencies are within it's own repository, as subfolders, which is great. However it also reaches into the other folders in many cases, replacing artifact dependencies as source when configured to do so. Depending on the job of a developer, using artifacts can greatly increase compilation and build times. Without the common libraries included, I count 19 sub-projects in that main project as of today. This change seems to lean away from more complex enterprise-like setups and towards small projects. It seems unnecessarily restrictive. I don't understand why sub-project roots can't be watched via the FS watchers in the same way the root project gets watched. I don't see an immediate reason this needs to be forced into a hierarchy other than it's easier to write that way for gradle's internals. What am I missing? |
Thanks to everyone for proving us feedback and explaining all the use-cases how the flat project is used. We decided to roll back and remove the deprecation from the flat project structure. |
@donat Thank you listening for feedback and rolling back the flat project depreciation! Huge relief. |
@donat
EDIT: It seems we're still somehow using 7.3 and so this message is still here.
EDIT2: For anyone else having this problem update your gradle, or if using gradlew, something like this (check for the latest version): |
FYI the latest version of the upgrade guide contains up-to-date information: https://docs.gradle.org/current/userguide/upgrading_version_7.html#non_hierarchical_project_structures |
@donat Hey, thanks for that, the older version documentation of course still says it's deprecated. It'd be really useful if 7.1, 7.2, and 7.3 documents could be updated to have a warning box or the like saying that from 7.4 this is no longer deprecated and people should upgrade. Otherwise the messages are quite cryptic and without coming here you don't know this has been reversed. |
I understand, but the general policy is that we don't modify any resources - binaries or documentation - for previous releases. |
Hi @donat on our company, we have a structure like this for mobile apps:
Where Then, within project(":lib1").projectDir = file("../../modules/lib1/") This is not exactly the same case as the We are still seeing a warning:
We are still on gradle 7.3.3, is this deprecation also being removed on gradle 7.4? I would also like to know if this structure makes compilation time slower, and if there is any hierarchical structure that you would recommend to improve performance on compilation time of thanks in advance 🙏 |
The deprecation message should disappear after you upgrade to Gradle 7.4. There can be performance implications of using a flat project structure. If not all files are located under the project root, the filesystem watching module needs to monitor more folders. |
After reading the above, i am still confused. So is includeFlat not recommended to be used? What should the alternative recommendation then, if i still wanted to have "flat project structure" |
In Gradle 7.1 Gradle deprecated the
includeFlat
statements in the settings file: #13891. When the decision was made, the team did not consider how widespread is the usage of these features. There are several reports on the deprecation issue explaining the usefulness when working with a large codebase, especially when the Eclipse IDE is being used.The intended replacement for
includeFlat
is composite builds. We should revisit why composite builds don't work for those users and whether we can improve that feature to cover the missing use-cases.The text was updated successfully, but these errors were encountered: