Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Xamarin.Android.Build.Tasks] build error JavaSourceJar xxxx.stamp not exist #2745

Closed
jaceDeng opened this issue Feb 17, 2019 · 1 comment · Fixed by #5479
Closed

[Xamarin.Android.Build.Tasks] build error JavaSourceJar xxxx.stamp not exist #2745

jaceDeng opened this issue Feb 17, 2019 · 1 comment · Fixed by #5479
Assignees
Labels
bug Component does not function as intended.

Comments

@jaceDeng
Copy link

Steps to Reproduce

  1. I tried to create a binding library from glide
    download glide-3.7.0-javadoc.jar glide-3.7.0.jar and set action build to JavaDocJar
  2. build binding library

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"

@Daddoon
Copy link

Daddoon commented Mar 3, 2019

This bug is still present on Visual Studio 2019 Preview 4.
I'm unable to create the JavaDoc, expect if i set AlwaysCreate="True" on the Xamarin.Android.Bindings.targets.

As it's from Visual Studio installation, it's not ideal at all.

@jonpryor jonpryor self-assigned this Jan 7, 2021
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.
@jonpryor jonpryor added this to the 11.3 Preview (d16-10) milestone Apr 13, 2021
@jonpryor jonpryor added the bug Component does not function as intended. label Apr 13, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jun 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Component does not function as intended.
Projects
None yet
3 participants