[XABT] Allow deployment artifacts to specify multiple JavaDependencyVerification JavaArtifact libraries.

[jpobst]

Fixes: #9013

Today, our Java Dependency Verification feature is built around our recommended practice of 1 binding library per project. This is reflected in the fact that JavaArtifact and JavaVersion only support a single library:

<PackageReferenceInclude="Xamarin.Kotlin.StdLib"Version="1.7.10"JavaArtifact="org.jetbrains.kotlin:kotlin-stdlib"JavaVersion="1.7.10" />

However a user may choose to place multiple Java libraries in a single package (or project), and we have no way to express that. Instead of using JavaArtifact/JavaVersion to specify a Java dependency, we will only use JavaArtifact and we will update the specification to include the artifact version: org.jetbrains.kotlin:kotlin-stdlib:1.7.10. Additionally, this attribute now allows multiple Java artifacts to be specified by separating them with a comma, semicolon, or newline.

This change affects @(PackageReference), @(ProjectReference), @(AndroidLibrary), and @(AndroidIgnoredJavaDependency).

Examples:

<PackageReferenceInclude="Xamarin.Kotlin.StdLib"Version="1.7.10"JavaArtifact="org.jetbrains.kotlin:kotlin-stdlib:1.7.10" />
<ProjectReferenceInclude="..\My.Other.Binding\My.Other.Binding.csproj"JavaArtifact="my.other.binding:mylib:1.0.0,my.other.binding:helperlib:1.0.0" />
<AndroidLibraryInclude="mydependency.jar"JavaArtifact="my.library:dependency-library:1.0.0" />
<AndroidIgnoredJavaDependencyInclude="com.google.errorprone:error_prone_annotations:2.15.0" />

Existing support for looking at NuGet package tags to automatically find Java libraries contained within has also been updated to support multiple artifact tags. Note that separate tags are expected, not a single tag with multiple artifacts specified:

<!-- Correct -->
<PackageTags>
artifact=my.other.binding:mylib:1.0.0
artifact=my.other.binding:helperlib:1.0.0
</PackageTags>
<!-- Incorrect -->
<PackageTags>
artifact=my.other.binding:mylib:1.0.0,my.other.binding:helperlib:1.0.0
</PackageTags>

[jonathanpeppers]

Regarding all of the different delimiters options, should we use ; as the standard MSBuild delimiter? Could ; be used as the top-level delimiter?

I'm wondering if we can use MSBuild to parse/split the top-level data, and not have to do that ourselves.

[jpobst]

Regarding all of the different delimiters options, should we use ; as the standard MSBuild delimiter? Could ; be used as the top-level delimiter?

I don't really have a preference here, but this conflicts with @jonpryor's request to support newlines.

[jonathanpeppers]

I tried to ask if there is a standard way for us to split like MSBuild does:

• https://discord.com/channels/732297728826277939/732310858776182866/1270469832080359506

I will ask the same question in Teams, maybe we could get a better answer there.

[jonathanpeppers]

I asked in Teams, but there isn't a standard thing for splitting MSBuild item metadata.

So, we can delimit on whichever character(s) we like.

[jonpryor]

@jonathanpepperswrote:

should we use ; as the standard MSBuild delimiter? Could ; be used as the top-level delimiter?

My concern is legibility: I find "very long lines" difficult to read.

Earlier this year I was looking into some stripe-binding related question, and had a reason to play with @(AndroidMavenLibrary), resulting in a .csproj with 43@(AndroidMavenLibrary) items. Were I to reference this project from another project, this would presumably require a %(ProjectReference.JavaArtifacts) value with 43 items (!):

 <ProjectReferenceInclude="..\stripe_terminal\stripe_terminal.csproj"JavaArtifacts="com.google.code.gson:gson:2.10.1;com.google.dagger:dagger:2.51;com.jaredrummler:android-device-names:1.1.9;com.neovisionaries:nv-i18n:1.29;com.scottyab:rootbeer-lib:0.1.0;…"

(My <CallTarget/> suggestion would mean that %(JavaArtifacts) isn't needed at all…, but that's not done here.)

I don't find the above to be readable, and it's not even complete yet!

Staying within MSBuild, we could introduce another item group:

<ItemGroup>
<_StripJavaArtifactInclude="com.google.code.gson:gson:2.10.1" />
<_StripJavaArtifactInclude="com.google.dagger:dagger:2.51" />
<_StripJavaArtifactInclude="com.jaredrummler:android-device-names:1.1.9" />
<_StripJavaArtifactInclude="com.neovisionaries:nv-i18n:1.29" />
<_StripJavaArtifactInclude="com.scottyab:rootbeer-lib:0.1.0" />
<!-- … -->
<ProjectReferenceInclude="..\stripe_terminal\stripe_terminal.csproj"JavaArtifacts="@(_StripJavaArtifact)"
/>
</ItemGroup>

Which works, but as soon as you have multiple items which require %(JavaArtifacts), you need to introduce new names for each such "containing" item.

This is why I was advocating for newlines and trimming/ignoring whitespace, which would allow "inlining" things:

 <ProjectReferenceInclude="..\stripe_terminal.csproj"JavaArtifacts=" com.google.code.gson:gson:2.10.1 com.google.dagger:dagger:2.51 com.jaredrummler:android-device-names:1.1.9 com.neovisionaries:nv-i18n:1.29 com.scottyab:rootbeer-lib:0.1.0 …"
/>

Additionally, MSBuild default behavior of turning ;-separated strings into an item group doesn't help us, as %(JavaArtifact) is a string, not an item group.

I thus believe we should split on ;, ,, and whitespace (space, tab, newline, etc.).

[jonpryor]

Do we actually want to do this? What if the same project name is used multiples but for different paths: Lib1/Helper.csproj, Lib2/Helper.csproj, …?

[jonpryor]

Given that we're now standardizing on "group:id:version" within %(JavaArtifacts), should we use that here as well?