Community
Participate
Working Groups
I am changing code in a class which is contained in a plug-in project. After doing two no-op changes - add space, save ; add space, save - the class starts getting compilation errors and also other random compilation errors appear in the project.
Created attachment 279858 [details] Screenshot of compilation errors Added screenshot (and sorry, hit submit too early, will add the rest of the details)
The full code of the project in question is at https://github.com/apache/sling-ide-tooling . I am importing them as Maven projects (some are plain Maven, some are Maven + Tycho, therefore PDE is used in Eclipse ). I have tried the following, but the problem was not fixed: - disabling the Maven Builder for the affected project - deleting .settings/.classpath/.project and reimporting all projects - upgrading to Eclipse 2019-09 The problem is only fixed by cleaning the affected project ( and returns shortly thereafter). In the attached screenshot it's visible that the error is present on the method invocation, but not on the type name and not on the import. I am not sure why that is. A good class that always triggers the problem when edited is ServerUtil (add whitespace then save, repeat ). Another problem that appears is that when launching the active plug-ins as an Eclipse applications the eclipse-ui fails to start withlogged event An error occurred while automatically activating bundle org.apache.sling.ide.eclipse-ui (536). The root cause is the compilation errors found in org.apache.sling.ide.eclipse.ui.internal.Activator.<init>, e.g. AbstractUIPlugin cannot be resolved to a type ServiceTracker cannot be resolved to a type SerializationManager cannot be resolved to a type SerializationManager cannot be resolved to a type ServiceTracker cannot be resolved to a type FilterLocator cannot be resolved to a type FilterLocator cannot be resolved to a type Again, these are not reflected in the editor. I'd be happy to try and debug this further but have no idea what to do next.
What does your classpath look like in that case (esp the PDE container)? Can you try to shrink down the project to the very minimal state to reproduce?
(In reply to Mickael Istria from comment #3) > What does your classpath look like in that case (esp the PDE container)? > Can you try to shrink down the project to the very minimal state to > reproduce? Do you mean the .classpath file? It's <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> <classpathentry kind="src" path="src/"/> <classpathentry kind="output" path="target/classes"/> </classpath> Shrinking down the example is not going to be easy TBH, we refactored it quite a lot recently to allow splitting out Eclipse from non-Eclipse projects to make it easier to build integrations for other IDEs. One interesting part is that the compilation problems usually happen for in-project dependencies, not for cross-project ones.
(In reply to Robert Munteanu from comment #4) > <?xml version="1.0" encoding="UTF-8"?> > <classpath> > <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> > <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> > <classpathentry kind="src" path="src/"/> > <classpathentry kind="output" path="target/classes"/> > </classpath> I think the content of the Plugin depedencies container as it appears in UI is more interesting. > Shrinking down the example is not going to be easy TBH, we refactored it > quite a lot recently to allow splitting out Eclipse from non-Eclipse > projects to make it easier to build integrations for other IDEs. Just removing as many classes and as many dependencies as possible to make this problem reproducible would be great. Also, please clarify whether some dependencies are loaded in the IDE or not. > One interesting part is that the compilation problems usually happen for > in-project dependencies, not for cross-project ones. I'm not sure I get what you mean here ;)
Created attachment 279859 [details] Screenshot of project dependencies (In reply to comment #5) > (In reply to Robert Munteanu from comment #4) > > <?xml version="1.0" encoding="UTF-8"?> > > <classpath> > > <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> > > <classpathentry kind="con" path="org.eclipse.pde.core.requiredPlugins"/> > > <classpathentry kind="src" path="src/"/> > > <classpathentry kind="output" path="target/classes"/> > > </classpath> > > I think the content of the Plugin depedencies container as it appears in UI is > more interesting. Ack, attached. > > Shrinking down the example is not going to be easy TBH, we refactored it > > quite a lot recently to allow splitting out Eclipse from non-Eclipse > > projects to make it easier to build integrations for other IDEs. > > Just removing as many classes and as many dependencies as possible to make this > problem reproducible would be great. > Also, please clarify whether some dependencies are loaded in the IDE or not. I can try to create a new, smaller, module in the same project that exhibits the problem, that should not take too much time. Creating a standalone project that reproduces the problem is a different thing :-) > > > One interesting part is that the compilation problems usually happen for > > in-project dependencies, not for cross-project ones. > > I'm not sure I get what you mean here ;) I wasn't very clear, sorry. What I meant is that the problem happens of classes inside the same project. So if I modify ServerUtil ( twice ) then the compilation error are related to the Activator class defined in the same project. So it's not necessarily an issue with cross-project dependencies.
I started to take a look but lost a lot of time trying to build the project. Question 1: why do I get a workspace with tons of compile errors after import using the m2e wizard? Yes, I installed the m2e-tycho connectors ... So I gave a try to building using build.sh, looked convenient enough, but: I got plenty of dependency issues due to Import-Package. Interestingly, they could be avoided by replacing Import-Package with a corresponding Require-Bundle, why? After piecemeal fixing half a dozen bundles, I gave up on this strategy and decided to try replacing "mvn verify" with "mvn install", e voila, I got the next error: apache-rat-plugin didn't like this stuff. Commenting the corresponding sections in pom.xml (aren't we all "happy" how commenting an XML block containing comments simply doesn't work ...) Next, tycho-surfire-plugin *crashed*: org.apache.sling.api.SlingException: Can't create the JCR event listener. ... Caused by: javax.jcr.LoginException: Can neither derive user name nor principal names for bundle org.apache.sling.jcr.resource [144] and sub service observation But perhaps when tests tried to start, maybe build had done enough already to go back to Eclipse and investigate our issue. At this point the workspace has 2597 errors, the first 100 being "Access restriction"... hmmmmm OK, I found /sling-ide-tooling/target-definition/org.apache.sling.ide.target-definition-dev.target and tried setting this as the active target platform. OK, this actually corresponds with the readme in github. Wow, now I'm down to 78 errors, and luckily ServerUtil is not affected by one of them. No I can start.
And now for some bad news: With the workspace prepared during comment 7 I don't see any of the problems. I can edit ServerUtil with no spurious errors occurring. Then I had a look at org.apache.sling.ide.eclipse.ui.internal.Activator. Yes it had compiler errors, but all where of the "Access restriction" flavor. The PDE quickfix to export those packages from their respective plugins made the errors go away. Terminally. => WORKSFORME. Can you reproduce the problem with a pristine Eclipse package from downloads? Which package, which version? Otherwise please attach the full list of features/versions installed in Eclipse. Additionally, I could imagine that project import creates different configurations, to double check please attach a zip file with all .project, .classpath files and content of .settings/ folders.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
