-
Notifications
You must be signed in to change notification settings - Fork 95
Better gradle project conventions #1684
Discussion from #1670, regarding gradle (sub)project conventions from @niloc132:
Two thoughts:
- If this is a good idea, why don't we apply for all projects across the repo? (and while we're at it, the standard project naming convention is "foo:bar" not "foo-bar", for a foo/bar/*.gradle, right? why do we break that convention?) The fact that it isn't suggests to me that we should think very carefully about implementing this, like worrying about local file(s) auto creating new projects that we werent expecting - forcing the user to edit setting.gradle (and sometimes root build.gradle).
- Which brings me to the next point - the root build.gradle is growing a lot with each new project, and the addition of modsAreDockerRegistry to subtract out projects that are uninteresting for some other uses seems to add to the problem. Is there no better way to do this, to opt-in rather than opt-out? esp since these projects at this time all have the common feature of being in the docker-registry project? :proto started off this way, but then didn't work because we actually only have one real proto project, the other two don't run protoc at all.
All reactions
Replies: 3 comments
Regarding auto-creation of :docker-<x> projects from the docker/registry/<x> directories (and now also checking gradle.properties file):
In an effort to "simplify" the amount of overhead a user needs to do to create a registry project, it gets auto-created. IE, they don't need to modify settings.gradle or build.gradle to add a new registry project - and then it also implies the "proper naming" for various derived bits from <x> (deephaven/<x>:local-build, Docker.registryFiles("<x>"), :docker-<x>). IE a "by convention" approach instead of "by configuration" approach.
I took this approach because I think there is only one important piece of project-level configuration: the simple name <x>. (The imageName and imageId are registry-level configurations.) If we want developers to be able to configure the directory, the project name, the image name that gets built locally, and how to reference registry files with a pretty name, we can provide those levels of configuration directly, but I don't think it makes things any simpler. If we want instead to keep the simple name <x> as the only configurable bit, but provider helper methods to lookup the built image name and project name so we don't have to rely on the "by convention" looseness, I would be in support of that.
All reactions
I think moving into an opt-in rather than opt-out approach is good. I think trying to pare down our root build.gradle is a good goal for better maintainability long term. I've tried to establish some ways to do that via buildSrc plugins; for example, java-publishing-conventions.
Getting rid of modsAreBasic for example, and ensuring each subproject explicitly opts into being a java project would be a good change IMO.
All reactions
Regarding subproject naming, :foo:bar vs :foo-bar: I think providing an intermediate parent project is a nice approach when we have an opt-in model, and/or when the parent project can be the layer applying configuration appropriate for the subprojects.
Right now, I've opted to do :foo-bar so I don't have to add :foo into modsAreBasic.
Places of consideration:
engine/, extensions/, docker/, docker/registry/, proto/, log-factory/, extensions/, web/, java-client/.