[Xamarin.Android.Build.Tasks] JAVAC0000 error code #3445
Conversation
There was a problem hiding this comment.
Looks good!
Seeing the change related to StringAssertEx.Contains(), I now know that I've written a couple tests that aren't checking all the expected assertions. I wonder if the behavior of StringAssertEx.Contains() to skip the rest of the test by calling Assert.Pass() is required for any tests right now. That seems like a tricky behavior. If no one beats me to it, I'll plan to create a PR to experiment with what happens to all the tests if StringAssertEx.Contains() and StringAssertEx.DoesNotContain() are modified to just return in instead of calling Assert.Pass().
For tracking "deletebinobj" progress, we wanted to make sure we have proper error codes for any failure that would be symptomatic of a "deletebinobj" problem. `javac` failing is one place that developers can't easily cause a build failure without using `AndroidJavaSource`. If we get a `JAVAC0000`, likely something went wrong with the Xamarin.Android build system. I also fixed up the test that was checking these error messages: it was using `StringAssertEx.Contains` that calls `Assert.Pass`: some of the assertions at the end of the test were skipped.
jonathanpeppers
force-pushed
the
javac-error-code
branch
from
2dd38d8
to
29f2a4c
Compare
| @@ -78,6 +78,8 @@ at com.android.dx.command.Main.main(Main.java:106) | |||
|
|
|||
| public string JavaMaximumHeapSize { get; set; } | |||
|
|
|||
| public virtual string DefaultErrorCode => null; | |||
There was a problem hiding this comment.
@jonathanpeppers, @brendanzagaeski we have a bunch of tooling which derive from JavaToolTask and will probably us this right? We should probably put in a work item/issue to make sure they all have proper MSBuild Error codes.
For tracking "deletebinobj" progress, we wanted to make sure we have proper error codes for any failure that would be symptomatic of a "deletebinobj" problem. `javac` failing is one place that developers can't easily cause a build failure without using `@(AndroidJavaSource)`. If we get a `JAVAC0000`, likely something went wrong with the Xamarin.Android build system. I also fixed up the test that was checking these error messages: it was using `StringAssertEx.Contains()` that calls `Assert.Pass()`: some of the assertions at the end of the test were skipped.
|
A new preview version has now been published that includes a fix for this item. Fix included in Xamarin.Android 10.0.0.40. Fix included on Windows in Visual Studio 2019 version 16.3 Preview 3. To try the preview version that includes the fix, check for the latest updates in Visual Studio Preview. Fix included on macOS in Visual Studio 2019 for Mac version 8.3 Preview 3. To try the preview version that includes the fix, check for the latest updates on the Preview updater channel. |
|
Release status update A new Release version has now been published that includes the fix for this item. Fix included in Xamarin.Android 10.0.0.43 Fix included on Windows in Visual Studio 2019 version 16.3. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/. Fix included on macOS in Visual Studio 2019 for Mac version 8.3. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. |
For tracking "deletebinobj" progress, we wanted to make sure we have
proper error codes for any failure that would be symptomatic of a
"deletebinobj" problem.
javacfailing is one place that developers can't easily cause abuild failure without using
AndroidJavaSource. If we get aJAVAC0000, likely something went wrong with the Xamarin.Androidbuild system.
I also fixed up the test that was checking these error messages: it
was using
StringAssertEx.Containsthat callsAssert.Pass: some ofthe assertions at the end of the test were skipped.