Skip to content

Conversation

@jonpryor
Copy link
Contributor

Fixes: #2745

Issue #2745 noted that @(JavaDocJar) didn't work; attempting to use
it would result in an MSB3375 error:

…/Xamarin.Android.Bindings.Documentation.targets(31,5): error MSB3375: The file "obj/Debug/javadocs/glide-3.7.0-javadoc.stamp" does not exist.

This issue was subsequently hidden by 380e95e, which disabled the
_ExtractJavaDocJars target unless JDK 1.8 was being used.

There were two problems with 380e95e:

  1. The _ExtractJavaDocJars target didn't need to be disabled!
    It just unzips the .jar; it does not require JDK 1.8.

  2. The check for JDK 1.8 was bad, and was never True.

The only documentation-related functionality that needed to be
disabled because of JDK 11 was @(JavaSourceJar), which got a better
fix in commits a7413a2 and 0e95ec7 [not relevant for d16-9].

Fix the _ExtractJavaDocJars target so that it properly runs when
there are any @(JavaDocJar) items, then fix the _ExtractJavaDocJars
target so that it doesn't emit an MSB3375 error.

Note: @(JavaDocJar) is still problematic: it involves parsing
Javadoc HTML, which contains numerous "dialects" (it's why the JDK 11
commit skipped @(JavaSourceJar) support: trying to update our HTML
scrapers was "too fiddly").

Deprecate @(JavaDocJar).

Fix the $(_JavadocSupported) test so that it is no longer always
false, by moving it's definition into a _GetJavadocSupported
target. This allows $(_JdkVersion) to be interpreted after
it is set.

Update the BindingBuildTest.cs infrastructure so that instead of
having .jar files encoded in Base64, we instead use
@(EmbeddedResource)s for the .jar files. A new UpdateResources
target will update the appropriate .jar files.

Fixes: dotnet#2745

Issue dotnet#2745 noted that `@(JavaDocJar)` didn't work; attempting to use
it would result in an MSB3375 error:

	…/Xamarin.Android.Bindings.Documentation.targets(31,5): error MSB3375: The file "obj/Debug/javadocs/glide-3.7.0-javadoc.stamp" does not exist.

This issue was subsequently hidden by 380e95e, which disabled the
`_ExtractJavaDocJars` target unless JDK 1.8 was being used.

There were two problems with 380e95e:

 1. The `_ExtractJavaDocJars` target didn't need to be disabled!
    It just unzips the `.jar`; it does not require JDK 1.8.

 2. The check for JDK 1.8 was bad, and was *never* True.

The only documentation-related functionality that needed to be
disabled because of JDK 11 was `@(JavaSourceJar)`, which got a better
fix in commits a7413a2 and 0e95ec7 [not relevant for d16-9].

Fix the `_ExtractJavaDocJars` target so that it properly runs when
there are any `@(JavaDocJar)` items, then fix the `_ExtractJavaDocJars`
target so that it doesn't emit an MSB3375 error.

Note: `@(JavaDocJar)` is still problematic: it involves parsing
Javadoc HTML, which contains numerous "dialects" (it's why the JDK 11
commit skipped `@(JavaSourceJar)` support: trying to update our HTML
scrapers was "too fiddly").

Deprecate `@(JavaDocJar)`.

Fix the `$(_JavadocSupported)` test so that it is no longer always
false, by moving it's definition into a `_GetJavadocSupported`
target.  This allows `$(_JdkVersion)` to be interpreted *after*
it is set.

Update the `BindingBuildTest.cs` infrastructure so that instead of
having `.jar` files encoded in Base64, we instead use
`@(EmbeddedResource)`s for the `.jar` files.  A new `UpdateResources`
target will update the appropriate `.jar` files.
@jonpryor jonpryor merged commit 45d6dd5 into dotnet:d16-9 Jan 17, 2021
@github-actions github-actions bot locked and limited conversation to collaborators Jan 24, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant