-
Notifications
You must be signed in to change notification settings - Fork 538
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
JDK 11 broke @(JavaDocJar)
& related support
#5474
Comments
What's "funny" is a7413a2 removes the And Issue #2745 doesn't appear. But, again, that's not because it's been fixed. It's because we seem to have broken On the plus side, // File: obj/Debug/generated/src/Com.Bumptech.Glide.Manager.ILifecycle.cs
namespace Com.Bumptech.Glide.Manager {
/// <summary>An interface for listening to Activity/Fragment lifecycle events.</summary>
// Metadata.xml XPath interface reference: path="/api/package[@name='com.bumptech.glide.manager']/interface[@name='Lifecycle']"
[Register ("com/bumptech/glide/manager/Lifecycle", "", "Com.Bumptech.Glide.Manager.ILifecycleInvoker")]
public partial interface ILifecycle : IJavaObject, IJavaPeerable {
// Metadata.xml XPath method reference: path="/api/package[@name='com.bumptech.glide.manager']/interface[@name='Lifecycle']/method[@name='addListener' and count(parameter)=1 and parameter[1][@type='com.bumptech.glide.manager.LifecycleListener']]"
/// <summary>Adds the given listener to the set of listeners managed by this Lifecycle implementation.</summary>
[Register ("addListener", "(Lcom/bumptech/glide/manager/LifecycleListener;)V", "GetAddListener_Lcom_bumptech_glide_manager_LifecycleListener_Handler:Com.Bumptech.Glide.Manager.ILifecycleInvoker, Scratch.Gxa2745")]
void AddListener (global::Com.Bumptech.Glide.Manager.ILifecycleListener listener);
}
} which is really cool. …but doesn't change the fact that |
Fixes: dotnet#2745 Fixes: dotnet#5474 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 bad JDK 1.8 check was later removed in a7413a2, which "fixed" (2), but a7413a2 continued to disable `_ExtractJavaDocJars`, preventing `@(JavaDocJar)` from being used. 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. 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"). We will deprecate `@(JavaDocJar)` support in a future release. `@(JavaSourceJar)` should be preferred. 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 Fixes: dotnet#5474 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 bad JDK 1.8 check was later removed in a7413a2, which "fixed" (2), but a7413a2 continued to disable `_ExtractJavaDocJars`, preventing `@(JavaDocJar)` from being used. 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. 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"). We will deprecate `@(JavaDocJar)` support in a future release. `@(JavaSourceJar)` should be preferred. 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 Fixes: dotnet#5474 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 bad JDK 1.8 check was later removed in a7413a2, which "fixed" (2), but a7413a2 continued to disable `_ExtractJavaDocJars`, preventing `@(JavaDocJar)` from being used. 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. 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)`, and remove `Xamarin.Android.Bindings.Documentation.targets` from the .NET 6 installation packages. Support for `$(_UseLegacyJavadocImport)`=False won't exist for .NET 6; `@(JavaSourceJar)` support in .NET t will *only* use `java-source-utils.jar` (a7413a2). 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: #2745 Fixes: #5474 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 bad JDK 1.8 check was later removed in a7413a2, which "fixed" (2), but a7413a2 continued to disable `_ExtractJavaDocJars`, preventing `@(JavaDocJar)` from being used. 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. 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)`, and remove `Xamarin.Android.Bindings.Documentation.targets` from the .NET 6 installation packages. Support for `$(_UseLegacyJavadocImport)`=False won't exist for .NET 6; `@(JavaSourceJar)` support in .NET t will *only* use `java-source-utils.jar` (a7413a2). 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.
Context: #5468 (comment)
Commit 380e95e inadvertently broken
@(JavaSourceJar)
and@(JavaDocJar)
support.Steps to Reproduce
a. Create a new Binding project.
b. Download
glide-3.7.0.jar
, set its Build action to@(EmbeddedJar)
.c. Download
glide-3.7.0-javadoc.jar
, set its Build action to@(JavaDocJar)
Scratch.Gxa2745.zip
Expected Behavior
The build should use the
@(JavaDocJar)
file. (Not necessarily "build successfully", but "do something with" the@(JavaDocJar)
files.Actual Behavior
The
@(JavaDocJar)
file isn't used.Issue #2745 makes for an interesting comparison point: if the file were used, the build would fail with an MSB3375, unless the underlying bug was fixed (PR #4406?!), which hasn't happened.
Discussion
However, this is a regression introduced by the introduction of JDK 11 support in 380e95e, due to buggy JDK 1.8 detection.
If we build the project, we get binding-related errors:
Sure, it errors, but at least we got to the point of building the binding!
However, if we "manually work around" the broken JDK 1.8 detection support by setting the
$(_JavadocSupported)
property to True, we in fact reproduce Issue #2745:$ msbuild /p:_JavadocSupported=True /v:diag … …/Xamarin.Android.Bindings.Documentation.targets(31,5): error MSB3375: The file "obj/Debug/javadocs/glide-3.7.0-javadoc.stamp" does not exist.
This proves three things:
$(JavaDocJar)
support.generator
output remains "less-than-ideal"The text was updated successfully, but these errors were encountered: