Hi Martin,
thank you for the effort and link to your project.
IMHO, the problem is much larger than resolving any arbitrary artifact from a repository.
For native binaries, the problem is (long story short):
-
there is no packaging spec or a mapping of target platform, operating system (toolchaing etc.) to artifact suffix, classifier etc. (at this point I would refer to e.g. nar-maven-plugin or Gentoo CHOST specification)
-
if one can resolve an artifact using any custom/arbitrary mechanism it still cannot participate as native binary dependency (headers, linking etc.) - either directly (in component) nor through prebuiltLibraries)
-
for publishing, with changes introduced in 2.9 one cannot collect a binary/ies anywhere else than in model block. But there is no way how to refer it from outside it (see my post How to reference a task defined in model block from outside it?). The only way I came up with is to reference such a task from a sibling “assembly” project (again, an ugly hack)
I am aware of the documentation chapter 69.7. Limitations and future direction stating that:
The majority of the development to date has been focused on proving the efficacy of the approach, and building the internal rule execution engine and model graph mechanics. The user facing aspects (e.g the DSL, rule source classes) are yet to be optimized for conciseness and general usability. Likewise, many necessary configuration patterns and constructs are not yet able to be expressed via the API.
which is not only a sort of disclaimer but a true description of current state 
So if I summarize my situation:
- using “incubating” features which means it changes a lot during time
- documentation covers only simple scenarios
- there are no answers to my questions on the forums for a long time
- I still have limited ability contribute to gradle (but I am working on it
)
I must say I am frustrated a lot by working with the combination of Gradle & native binaries (but not giving up :D)