Community
Participate
Working Groups
Opening my Eclipse workspace with the new Eclipse 4.11 release I am seeing a few imported packages decorated with error markers when there is no explainable problem. I refer you to this New & Noteworthy entry: https://www.eclipse.org/eclipse/news/4.11/pde.php#manifest-editor-marker That N&N entry says, "The Manifest editor's dependency tab now displays error markers for all unsatisfied dependencies." These are NOT problems, as far as I know. This is code that works, and I can assure you that there are no unsatisfied dependencies. I believe that this is a bug. At least, it's a bug based on how I'm using the PDE to build OSGi bundles. I shall attach a screen shot. I shall attempt to reproduce this problem in a test case.
Created attachment 277942 [details] Screenshot
Not sure if related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=511127
Julian/Andrey, Is this related to bug 511127?
(In reply to Vikas Chandra from comment #3) > Julian/Andrey, Is this related to bug 511127? Most likely yes. I wonder however if the nls package in the screenshot is really missing or not exported or not on the classpath of the declaring bundle, so that the error is *valid* one.
"...if the nls package in the screenshot is really missing or not exported or not on the classpath of the declaring bundle, so that the error is *valid* one." The nls package: - Exists. - Is exported. - And is on the bundle's .classpath. I shall attach a screenshot that demonstrates these facts.
Created attachment 277948 [details] Second screenshot This screenshot shows that the "com.sas.ct.util.nls" package exists within the "com.sas.ct.util" bundle, that it's an exported package, and that it is on the bundle's .classpath via the "src" <classpathentry>.
I have confirmed that this DOES NOT happen with the following build: Eclipse SDK Version: 2018-12 (4.10) Build id: I20181206-0815 OS: Windows 10, v.10.0, x86_64 / win32 Java version: 1.8.0_102
(In reply to Simon Archer from comment #5) > "...if the nls package in the screenshot is really missing or not exported > or not on the classpath of the declaring bundle, so that the error is > *valid* one." > > The nls package: > > - Exists. > - Is exported. > - And is on the bundle's .classpath. > > I shall attach a screenshot that demonstrates these facts. Simon, may I ask you to install my small Plug-in Dependencies Explorer plugin, here is link to github https://github.com/iloveeclipse/plugindependencies, in the readme is the update site and in the wiki small "how to". If you install it, open the Plug-in Dependencies Explorer, select "Running platform" target and check there the packages that are "wrong" in the manifest editor : are there any errors/warnings reported? You can use filter to quickly locate the package/bundle. I forgot to ask: do you have any errors in the log?
Thanks Andrey, I'll try now. I shall report back.
Created attachment 277952 [details] Plug-in Explorer Screenshot In the screenshot I attempted to show you: - The project "com.sas.ct.app.console" with it Manifest Editor open showing the error marker against the imported package "com.sas.ct.util.nls". - The project "com.sas.ct.util" that contains, and exports, the package "com.sas.ct.util.nls", which contains a single abstract class named AbstractL10nMessages. - The Plug-in Explorer view, focused on the project "com.sas.ct.app.console", and drilled down to the Imports and "com.sas.ct.util.nls".
Using the Plug-in Explorer I am unclear why I see so may "Dependency cycle detected" errors. The architecture of the code has been verify carefully designed to separate interfaces from their implementations. As a result there are few class-to-class couplings. Granted, there are a few packages of classes that are shared with other types, and the package "com.sas.ct.util.nls" is one such package.
Created attachment 277953 [details] The console log from the Plug-in Explorer. I am attaching the console log from the Plug-in Explorer with the hope that it provides an overview of my entire Eclipse workspace.
(In reply to Simon Archer from comment #11) > Using the Plug-in Explorer I am unclear why I see so may "Dependency cycle > detected" errors. > > The architecture of the code has been verify carefully designed to separate > interfaces from their implementations. As a result there are few > class-to-class couplings. Granted, there are a few packages of classes that > are shared with other types, and the package "com.sas.ct.util.nls" is one > such package. The cycles check is a simple one, basically it tries to parse all dependencies including imported packages, recursive, and if on this path the bundle itself appears, I report a cycle. I must confess, I cannot guarantee it is 100% correct, but so far I haven't seen any false positives. It may happen you export same package in multiple bundles or have fragments or some other weird dependencies. Interesting here is: are any warnings/errors reported for the packages itself? What do you mean by "packages that shared with other types"? Are all such packages shown with error markers in manifest editor?
OK, so I have been poking around and trying to find some sort of unholy dependency that I can break to resolve the apparent cycle. I stumbled upon a discovery... The problem is being triggered by the "com.sas.ct.util" project's fragment project "com.sas.ct.util.test", which houses the host's unit tests. Of course the PDE is treating each fragment as an extension to the associated host project, so it seems reasonable for PDE's dependency analysis to include fragments. But keep reading... :-) But, since fragments are by definition OPTIONAL, it strikes me that including them in static dependency analysis could lead to some false error markers, which is what I believe is happening here. In my case, I isolated the problem down to the "com.sas.ct.util.test" fragment project importing the package "org.hamcrest", creating a cycle somehow. When I remove the "org.hamcrest" imported package from the fragment project the error marker on other projects that import packages that have been exported by "com.sas.ct.util" (the host) go away! In conclusion, I fear that the new Manifest Editor error markers against Imported Packages that was introduced with Eclipse 4.11 is overly aggressive and is producing false-positives. Also, the Eclipse convention has always been that each error marker has an associated problem shown in the Problems view. This is NOT the case for the new error markers that I'm seeing. My wish list: 1. Fix the false-positive error markers, although I accept that this might not be possible. But I fear that including fragments in the dependency analysis is the cause of the problem. Unfortunately I was not able to reproduce the problem with a few sample projects. 2. Ensure that every error marker has an associated entry in the Problems view. This, I feel is more than a wish-list item, it's absolutely required by the conventions of the Eclipse Platform. 3. Provide PDE preferences to allow error markers to be changed to Ignore, Warning, or Error, just like many other compiler options.
The error decorator in the dependencies tab is not supposed to be a new inspection, it should just mirror the existing error markers on the file. So your case is a false positive. Can you share your projects causing the error (without any Java/source files)?
Simon, is this problem also fixed via bug 545634?
>.My wish list: I suggest you raise new defects for wishlist 2) and wishlist 3). ( with a sample project attached). This defect will pursue 1).
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.
