search

jpobst / Prototype.Android.MavenBindings

Prototype of MSBuild tasks to facilitate binding of Java libraries from Maven repositories
MIT License
5 stars 3 forks source link

Can't consume a NuGet containing multiple native libs #13

Open jasells opened 3 months ago

jasells commented 3 months ago

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.

jasells commented 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?

jpobst commented 2 months ago

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.