IssueTracker

for reference, this is the output if i run it from command line with the invoked.from.ide parameter:

[databinding] {"msg":"View and \u003cinclude/\u003e ids in data bound layouts must be unique. \u0027@+id/view2\u0027 is shared by another view or an \u003cinclude/\u003e tag.","file":"src/main/res/layout/abs_spinner_adapter_test.xml","pos":[{"line0":24,"col0":8,"line1":26,"col1":47}]}

Clicking on an error in the build output window used to work, but it looks like it broke for some reason. We should fix this ASAP as otherwise the feature feels busted, and it's one of the more visible data binding features going into 3.5 so I'd like it to land well.

This is happening because the reported file path is relative to a different path than what Studio thinks the current directory is.

In my case, I have an XML located in a project called "bitmaps" in a module called "app":

/usr/local/google/home/davidherman/AndroidStudioProjects/bitmaps/app/src/main/res/layout/fragment_image_detail_item.xml

Data binding is reporting the path as "src/main/res/layout/fragment_image_detail_item.xml" but the build output window thinks the current directory is the path of the parent project: "/usr/local/google/home/davidherman/AndroidStudioProjects/bitmaps"

So the final path is

"/usr/local/google/home/davidherman/AndroidStudioProjects/bitmaps/src/main/res/layout/fragment_image_detail_item.xml"

missing the "app"

Investigating how to get the right path....

Hung, this may have nothing to do with you at all, but I have a feature which used to work but stopped working, and it seems to do with paths. I know there was recently your change about relativizing directories - did we change absolute paths to relative paths in that change?

Actually, Hung, it seems more and more like the recent Relativizable file stuff is the culprit. When I set my AGP to an older version, I saw absolute paths and the Build Output window worked again.

After working with Yigit, I tried to re-absolute the file path when encoding the error:

  class ScopedException {
    private String createEncodedMessage() {
        ScopedErrorReport scopedError = getScopedErrorReport();

        // We want the encoded message to use an absolute path, since this an error
        // that external programs will use to locate the issue, and they may not know the
        // current module as context.
        EncodedMessage encoded = new EncodedMessage(super.getMessage(), new File(scopedError.getFilePath()).getAbsolutePath());
        ...
    }

but this didn't work, because even here, "getAbsolutePath" returned the directory of the project, not the submodule.

I'm thinking the best solution here is to have scopedError return a RelativizableFile instead of a String, e.g.

        EncodedMessage encoded = new EncodedMessage(super.getMessage(),
scopedError.getRelativizableFile().getAbsoluteFile())

I'll try that, but I may not finish today, and I'll be out until Thursday next week.

Actually, this is looking more complicated than I thought. Hung, any guidance here would be appreciated.

If it's possible for someone else to fix the databinding compiler to return absolute paths in "createEncodedMessage", then please don't wait for me to come back. I worry that by not being here next week, I'll already be causing this bug to miss the next canary.

Sorry that we don't have any tests right now that would have notified us earlier about this behavior. I'll open a bug against myself to add an integration test, maybe a UI test?

Final notes before I head out, from talking with Yigit.

Basically, we either need to get an absolute path in ScopedException#createEncodedMessage OR we need a relative path which is relative from the project path, not the submodule path.

We were thinking it would probably be easier to change the relative path root vs passing the absolute path all the way through.

Right, I would also prefer changing the path root.

Both the producer and consumer of the relative path need to agree on the same base directory. Since the IDE (consumer) is using the root project directory as base, I will change the Android Gradle plugin side (producer) to use the same.

Hung, is this something you were planning to do? If so, what's the ETA?

If I do it, is it as simple as changing this line?

https://googleplex-android-review.git.corp.google.com/c/platform/tools/base/+/6369974/12/build-system/gradle-core/src/main/java/com/android/build/gradle/tasks/MergeResources.java#688

or can you give me more context so I know what to chase down? Thanks!

Yes, that should be it. (We'll need to update some tests in tools/data-binding too to reflect this change---it will be clear what they are when we run PSQ.)

Would you have time to write a CL and add me as reviewer?

(Otherwise, I plan to get to this early next week, I'm working on something else right now.)

Sure, SGTM, I'll give it a shot. Thanks Hung!