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

Build failure: TypeFilter cannot be resolved to a type #534

Closed
bsolar17 opened this issue Feb 4, 2024 · 4 comments · Fixed by #535
Closed

Build failure: TypeFilter cannot be resolved to a type #534

bsolar17 opened this issue Feb 4, 2024 · 4 comments · Fixed by #535

Comments

@bsolar17
Copy link

bsolar17 commented Feb 4, 2024

I'm trying to build on MacOS and I'm having the following compilation failure:

[ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:4.0.3:compile (default-compile) on project com.microsoft.java.debug.plugin: Compilation failure: Compilation failure:
[ERROR] /Users/bsolar/Projects/java-debug/com.microsoft.java.debug.plugin/src/main/java/com/microsoft/java/debug/plugin/internal/CompletionProposalRequestor.java:[324]
[ERROR]         return declaringType != null && org.eclipse.jdt.ls.core.internal.contentassist.TypeFilter.isFiltered(declaringType);
[ERROR]                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ERROR] org.eclipse.jdt.ls.core.internal.contentassist.TypeFilter cannot be resolved to a type
[ERROR] 1 problem (1 error)
@Redy1908
Copy link

Redy1908 commented Feb 4, 2024

Same problem

@Libadoxon
Copy link

Same on Linux, from want I can tell this is caused by a dependency change. Though then one has to ask themselves why the dependencies are not pinned to ensure reproducibility. This shouldn't be too much of a hassle but I'm not a Java dev so I might be wrong there. As a workaround you can comment of the right side of the if condition, so that the code looks like that:

return declaringType != null /*&& org.eclipse.jdt.ls.core.internal.contentassist.TypeFilter.isFiltered(declaringType)*/;

This at least allows the package to build but probable unfixes the issues mentioned in the code (Jdtls 1212)

@bsolar17
Copy link
Author

bsolar17 commented Feb 5, 2024

Though then one has to ask themselves why the dependencies are not pinned to ensure reproducibility. This shouldn't be too much of a hassle but I'm not a Java dev so I might be wrong there.

I think this is due to this file. E.g:

<unit id="org.eclipse.jdt.source.feature.group" version="0.0.0"/>

My understanding is that version="0.0.0" means "use the latest version", which of course is not reproducible.

@Libadoxon
Copy link

My understanding is that version="0.0.0" means "use the latest version", which of course is not reproducible.

You're probable right, hope that this changes. While I can of course understand that that would create extra work, I still think its very important for a version to always build. A compromise maybe would be to only pin the dependencies for every release to ensure at least reproducibility there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants