How can we download .gradle file from package

Pre-requisite : .gradle file is available in a package either along with .aar file or as a single file in the package.

Context: Implementation downloads the dependencies into the cache if repositories are well define.

Ask: Is there any way to download ,gradle file into the cache so that it can be referenced in the different project ?
Does implementation line downloads all the .aar files along with resources (.gradle, .txt, etc all the files in the folder)

Assumption: package is available along with other packages which are accessible.

Goal is to apply the .gradle file from the package in the different project.

What is the .gradle file you are talking about?
A .gradle file is Groovy DSL build script, not something that should be available in a repository.
Gradle only downloads the defined artifacts for a variant that is resolved.
Additional files that are available in the repository are not retrieved.
You can request any specific artifact for a dependency if you choose so, but if you request a specific artifact you do not get dependencies for example.

Usually, if a dependency provides different artifacts as different variants, you would use attributes to get the variants you are interested in, but that is a rather complex topic and information here is too sparse to know whether this is applicable here.

Thanks for the response @Vampire
To illustrate, we want to publish a resolution strategy file (i.e., resolutionstrategy.gradle) so it can be utilized by different projects that aren’t part of the same repository. For example, the resolutionstrategy.gradle file could be packaged and made available either as a separate package or alongside a .aar file.

This package would be downloaded into the cache, and the path would be referenced in the project, similar to the following:

gradle

apply {
    from("${System.getProperty("user.home")}/.gradle/caches/modules-2/files-2.1/com.xx/resolutionstrategy.gradle")
}

The problem we’ve encountered involves crashes due to dependency version mismatches. A resolution strategy is one way to address this (with a version catalog as the next step, though our current focus is on the resolution strategy).

The resolution strategy will only detect errors in the code being compiled. Since it can’t catch errors in a .aar file, we plan to share the resolution strategy file with other modules so issues can be detected earlier.

Actually, legacy script plugins (the things you apply with “apply from”) have many quirks and are quite discouraged, so you should strongly reconsider that approach.

The proper way would be that you write a convention plugin (doesn’t matter whether you implement it as precompiled script plugins, normal binary plugin in any JVM language, …) that you then publish somewhere and then apply to the projects where that convention should be effective.

Please provide an example where a plugin can function as a resolution strategy, aiming to achieve the same results as applying the resolution strategy file.

I don’t have one, but almost anything you can do in a build script, or in a legacy script plugin like you intended to use, you can also do in a normal plugin or precompiled script plugin.

Let me try to understand.
below is the link to sample precompiled script plugin

Can we say that simply replacing the whole code with resolution strategy file in the above plugin will serve same purpose ?

Thanks in Advance for helping with more optimzed approach

I’m not going to review that whole code, but probably.
Except that you maybe cannot paste 1:1 if your other file is Groovy DSL and you use a Kotlin DSL precompiled script plugin.

OK, one more query,
Does precompiled script plugin works for both (1. uses Groovy 2. uses Kotlin DSL) kind of projects?

A precompiled script plugin - be it written in Groovy DSL or Kotlin DSL doesn’t matter - is just syntactic sugar over writing a normal plugin.

Whether you apply it to a Groovy DSL build or Kotlin DSL build does not matter in any way.

The example project you posted is only marginally helpful for your case btw. because it generally shows how one could write a precompiled script plugin, but it is done in buildSrc which is only for organizing / centralizing build logic within the build it is contained in. You want to do it in a dedicated plugin project and publish the plugin so that your other builds can consume it.