Todays query is, I have a config like this:

dependencies {
   implementation(project(":project1"))
}

// I have a working publishToMavenLocal
// I have MavenLocal setup with a filter to only lookup group="com.mydomain.myproject"
// I have MavenCentral blocked/excluded for group="com.mydomain.myproject"
//  assume this project operates in this group namespace

// I am trying to convert the original config at the top of this command into:

val CONFIG_BOOLEAN = true  // picked up from gradle.properties
fun DependencyHandler.myproject(path: String): ProjectDependency {
   if(CONFIG_BOOLEAN) {
      val p = path.removePrefix(":")
      // I am after a compatible GAV that will resolve the location of this dependency from MavenLocal
      //   by performing a standard Maven resolution on the Dependency descriptor, how do I instantiate what is needed ?
      return ??????(group=project.group, module=path, version=project.version)
   } else {
      return project(path)
   }
}

// So this is a Kotlin extension function I am attempted to provide into the DSL that will modify behaviour
//  from configuration and resolve the dependency from an internal project or resolve it from MavenLocal.

dependencies {
   implementation(myproject(":project1"))
}

The purpose of this is to use a trick from Maven days, to not have Gradle build all projects when you are not making side-effect changes to most projects, it should instead use the pre-created JAR from Maven Local to resolve dependency.

why would you need this? gradle has incremental builds

How might we try to achieve an incremental build with 200 projects, and maybe 300Mb of data on only a 16Gb laptop. This is not really my project status, but it highlight that even with incremental builds sometimes the development just want 10 project to be incrementally built and the rest to resolve from a JAR, to cut all the CPU time in gradle processing.

you should get this behavior for free with a remote build cache set up

Hmm $HOME/.m2 is the original build cache, I'd prefer it to just looks there and not use the network

well, gradle has its own caches.. local maven is considered bad practice in the gradle world

I don't mind what manages filestore of JARs, if it was IVY or Gradle that part is not important, but the optimization I am making has been working in the Maven world for decades. I have used build cache in CI like environment with gradle, is that not enabled by default for 8.5. Will try with the properties setting in place and see if that changes anything. Thanks for the link/reminder to check it is seamlessly enabled by default I can of course split my project up, like not a mono-repo strategy and maybe rename some groupId accordingly, but right now that is not the step to take, just want faster iteration that such a split would provide in the local setup, I don't need gradle to evaluate many projects at all (not even for incremental and file timestamp checks) just want it to consume the output artifacts as assuming everything is fine.

I think what you have in https://gradle-community.slack.com/archives/CAHSN3LDN/p1719480042276529?thread_ts=1719478007.019279&cid=CAHSN3LDN should work. I would say that no type safety is okay in this case since it’s likely going to be a temporary solution until you adopt The Gradle Way™️.

maven != gradle, so you just shouldn't blindly migrate your strategies over and expect them to work exactly the same or be as efficient (see the case-for-maven-local docs, warning about slow builds when using maven local). Again, if your builds are properly configured, gradle will cache "everything". This includes build configuration to cover your "I don't need gradle to evaluate many projects at all" concern. But to be fair, that's not always easy to achieve at this time, so it might be easier with your approach in your case.

is that not enabled by default for 8.5

No, build cache is not enabled by default, as badly configured inputs / outputs of tasks would cause poisened cache entries and thus wrong and non-deterministic build results. You do not need to use a remote build cache, just enabling build cache would already enable the local build cache.

Thanks for your input everyone. So with build cache enabled via gradle.properties that does improve performance and with an auto managed local file store. From this I've been able to more clearly see which subprojects are the sticking points to performance and fix configurations or re-write functionality into a custom task that works with the build cache feature (it stops mutating a state everytime it is run, which then causes consumer project rebuild cascades to mutate their output artifacts as well) So total incremental build time it back into acceptable durations again :)