Open jasells opened 3 months ago
This approach relies entirely on the meta-data tags in the binding-.nupkg to resolve all the native libs, but if we update this tag, a roll-up package could be supported from consumer-side only as well.
Something like this would not be a breaking change:
<!-- Include format is {GroupId}:{ArtifactId} -->
<ItemGroup>
<AndroidMavenLibrary Include="com.squareup.okhttp3:okhttp" Version="4.9.3" SourcePackageRef="[Nuget.Package.Id]"/>
</ItemGroup>
Possibly, a similar approach could work for project-refs as well?
This repository is obsolete, as this is now part of .NET 9 Previews, but this is a useful case we should consider supporting.
Filed as https://github.com/xamarin/xamarin-android/issues/9013.
This tool currently assumes only 1 native library per NuGet package dependency. This does follow the 1:1 convention for Android-binding packages. However when simply trying to include native dependencies without bindings, there are times when it is much more convenient to provide a "roll-up" NuGet that provides an entire "framework" of native packages.
For example: Ktor. https://mvnrepository.com/artifact/io.ktor
You can see my roll-up here, where there are ~20 native packages I need to roll up into a singel, or maybe 2-3 packages instead of 1:1 NuGet:jar.
In this case, none of these native libs generated bindings, as they are only needed to support a 3rd-party lib I am integrating into my Maui app.
The main issue with that 3rd party lib is it provides some full-stack functionality, which is how the whole Ktor framework gets pulled in as a dependency... but that's another topic...
Back to the point:
The MavenBindings build task seemed pretty straight forward, after looking at the code a bit. I was able to mod it locally to support consuming a single roll-up .nupkg that contains multiple native libs (the Ktor roll-up package linked above) with multiple meta-data tags (1 tag per native lib).
I think this would be a valuable use-case. I can push my branch/open PR if there is interest. I'm torn what to do since this local version does exactly what I need, but I am not sure what .Net9 roadmap is and if this use-case is intentionally going to not be supported, I'm going to have to think on how to proceed.
Here's the branch that I have working locally. (some extra debugging log statements are still there, but can be removed) https://github.com/jasells/Prototype.Android.MavenBindings/tree/support-roll-up-packages
I suppose, the only other option would be to use the MavenNet package to create some tool that looked for all the native
io.ktor
packages and generated a .csproj for each... and package them all individually that way for "framework" scenarios. But this is working well, and I like the roll-up package, since I can just find-replace the old version string to update and publish the v-next NuGet.