https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# community-support
s
This message was deleted.
v
What do you want to do with that information? If you e. g. want to depend on all the projects, I think using 
subprojects
should be fine too and not disturb project isolation.
e
I want to use it to configure dependency analysis plugin to be able to see usages of 
projects.foo
With 
subprojects
I'm using the path to do that.
v
Which configuration option do you try to feed with that? Iirc you apply that plugin to your root project and then can also invoke 
foo:projectHealth
to only see the results for 
foo
project.
e
v
Sorry, I'm still not sure what you try to do, can you show an example? Isn't 
dependencyAnalysis { dependencies {
just for defining bundles?
e
In my dependencies block, I specify project dependencies using the accessors:
Copy code
dependencies {
  implementation(projects.foo)
}
The analysis plugin isn't able to remove them if it detects that it is unused, because it looks for 
project(":foo")
. So I'm doing:
Copy code
// Adds the project accessor form to be used when printing advice and rewriting build scripts.
subprojects.forEach { subproject ->
      val projectAccessor = <http://CaseFormat.LOWER_HYPHEN.to|CaseFormat.LOWER_HYPHEN.to>(CaseFormat.LOWER_CAMEL, subproject.path.replace(':', '.'))
      map.put(subproject.path, "projects$projectAccessor")
}
and now the plugin can properly remove them.
v
Ah, I see. Didn't know you can do some mapping there. It is not mentioned on the documentation wiki as far as I have seen. And does it make a difference whether you use the project accessors or the 
subprojects
regarding project isolation? I'd either expect both to work or both to make problems.
Also is there an open issue on the plugin to support project accessors? I didn't find one.
e
I was thinking that the accessors would be fine because they're generated. I hoped that the accessors would have a list of subproject names somewhere that is generated, which I assume wouldn't violate project isolation. That doesn't look to be the case though, so I was wondering if there was some other way.
There's an issue to support them, but it looks like it's specifically for excluding a dependency using an accessor.
v
Ah, ok, I only searched in the issues, not the pull requests and in the according issue the word "accessor" for which I searched is not present. 😄
But yeah, as the issue and also PR only focus on the 
exclude
I guess you should open another issue with your problem, so that it can hopefully be fixed at some point within the plugin. There is no possibility that I'm aware of to list the project accessors, other than using reflection. For the version catalogs there was initially also no way to list them, but it was added later. So maybe also worth a feature request to Gradle. But actually I still would assume that either both work with project isolation or both don't. But I didn't do much with project isolation so far, so I don't know.
e
Before I file an issue on GitHub, is using 
subprojects.forEach { it.path }
actually a violation of project isolation, or will it become one in the future?
j
There is already an issue for commenting use cases, and that is listed (and 
allprojects
too)
👍 1
e
Are you referring to https://github.com/gradle/gradle/issues/22514? If so, that looks like it's specifically about applying a plugin to multiple projects.
v
Btw. if you would want to go the reflection way, you probably need something like
Copy code
projects::class
    .java
    .methods
    .filter { ProjectDependency::class.java.isAssignableFrom(it.returnType) }
    .map { it.name.removePrefix("get").decapitalize() }
e
Yup. It got a little more complicated because of nested projects, which is why I abandoned that route 😅
v
Ah, right
4 Views
Open in Slack
PreviousNext
Powered by