-
Notifications
You must be signed in to change notification settings - Fork 1
Use ecj from maven #1
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
Conversation
@guw here is the PR. |
The test indeed fails. |
I'll try to find time in the next days to fix the change. |
Thank you! You cannot print to See Debugging here: I also updated the Bazel Eclipse plug-in to allow working with the bzlmod toolchain repo. You can grab the latest at https://eclipseguru.github.io/bazel-eclipse/latest/ |
While preparing with the debugging steps, I'm not noticing a
Anyway I'll debug tomorrow, I do have the |
It defaults to "all" when not specified. Line 94 in 52b4334
|
Here is a URI of a binary type we visit:
We turn this into:
And then fail to match this against:
I'm not sure why there are 3 slashes instead of 2... |
Three slashes are ok for file URIs. It's The more brittle part is the conversion back to relative paths. Bazel expects them all to be sandbox relative. We have this for detecting the base path. This should remove Line 417 in 52b4334
|
if (answer.getBinaryType() != null) { | ||
URI binaryTypeUri = answer.getBinaryType().getURI(); | ||
String uri= binaryTypeUri.toString(); | ||
String prefix = "jar:file://"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might not hurt putting a comment in here, with a link to https://github.com/eclipse-jdt/eclipse.jdt.core/blob/87368ab46448493820f5bcba6d2442ecb25267c3/org.eclipse.jdt.core.compiler.batch/src/org/eclipse/jdt/internal/compiler/classfmt/ClassFileReader.java#L165 (to give context what the expected URI format should be)
At least during the test (i.e. compiling the test class),
Where the actual file is:
I.e. the leading slash must be removed in some way, but I don't know if we can just do that (since I have no knowledge of what |
The handling of the slash is independent from Bazel. That's an URI/ECJ thing. The URI is constructed by ECJ. Thus, we need to apply the reverse logic to get back to the original path. The URI is created here: URI uri = URI.create("jar:file://" + toUri(zip.getName()).getRawPath() + "!/" + filename); the "extra" slash is added by ECJ here: String p = absoluteNormalFilePath.replace(File.separatorChar, '/');
if (!p.startsWith("/")) {
p = "/" + p;
} Bazel executes all actions within a sandbox. This is to ensure they only access declared inputs. The sandbox path is something internal. Normally this isn't a problem with most tools because all paths within the sandbox are relative from the working directory. However, ECJ converts all paths to absolute, canonical real paths. Thus we need to convert them back to relative paths for reporting. Otherwise IDEs (eg., IntelliJ) and other tools parsing the output wouldn't be able to match the jar locations. This is working with Lines 224 to 227 in a0014d5
|
From an implementation perspective, we might be able to ignore the extra slash and just attempt to find |
OK, I debugged also the old version of the code:
Before the
And after:
|
That is unexpected. The one in the produced jdeps file starts at Example on my Mac:
|
@guw does it make more sense for you to take a look? I don't know which values are expected and which are not. In addition I can't get
|
Maybe I'm invoking the debugging from the wrong folder? I do it in the root of the I guess I can in the folder you mentioned... Then again there are 2:
|
OK, when I What gets added to
What gets added on my branch
Still though, no idea what criteria we should use to remove the leading slash. Maybe its enough to just remove it, considering the check |
Ah ok, yes. It's all relative to the working directory. If the logic adapts to the folder it's working. |
I'm comfortable with adjusting the expected (supported) prefix to |
Thank you for merging this @guw ! We'll start using the repo now for our builds, instead of: https://github.com/salesforce/bazel-jdt-java-toolchain |
Absolutely. Please keep sending patched if you need additional features. |
@guw the README is now outdated: https://github.com/eclipseguru/bazel-jdt-java-toolchain/blob/main/README.md The section about compiling This one too maybe is outdated: https://github.com/eclipseguru/bazel-jdt-java-toolchain/blob/main/ecj-test/test-compile.sh Do you have time to update it or should I try? |
Totally forgot about it. If you have time please don't hesitate! |
See original issue: salesforce#34