[Xamarin.Android.Build.Tasks] build error JavaSourceJar xxxx.stamp not exist #2745
Comments
|
This bug is still present on Visual Studio 2019 Preview 4. As it's from Visual Studio installation, it's not ideal at all. |
jpobst
added a commit
that referenced
this issue
Mar 16, 2020
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this issue
Jan 7, 2021
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.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this issue
Jan 8, 2021
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.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this issue
Jan 8, 2021
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.
jonpryor
added a commit
that referenced
this issue
Jan 9, 2021
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.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this issue
Jan 15, 2021
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
added a commit
to jonpryor/xamarin-android
that referenced
this issue
Jan 16, 2021
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
added a commit
that referenced
this issue
Jan 17, 2021
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.
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
download glide-3.7.0-javadoc.jar glide-3.7.0.jar and set action build to JavaDocJar
Expected Behavior
build success and binding library has original Java parameter
Actual Behavior
build error xxxx.stamp not exist
Version Information
Log File
Xamarin.Android.Bindings.targets
<Touch Files="@(JavaDocJar->'$(IntermediateOutputPath)javadocs\%(FileName).stamp')" />maybe miss the attribute AlwaysCreate="True"
The text was updated successfully, but these errors were encountered: