Community
Participate
Working Groups
3.4 RC1 1. On the 'User Libraries' preference page import a corrupt user library (see bug 230217 for steps). 2. create a Java project 'P' and add that user library ==> build path problem is created: Project 'P' is missing required library: 'C:\tempx\NotesBuddy.zip' For the user it is not clear why this library should be required. Better would be to say that it is missing from user library 'xyz'.
See also bug 171136
Instead of using the project name, we could use the container's description in the message. Srikanth, please have a look at this.
Here is a much simpler way to reproduce the problem: 1. Create a file c:\bogus.userlibraries with the following content: <?xml version="1.0" encoding="UTF-8"?> <eclipse-userlibraries version="2"> <library name="improperlybuiltlibrary" systemlibrary="false"> <archive path="c:/bogus/non-existent/path/jarfile.jar"/> </library> </eclipse-userlibraries> 2. On a fresh workspace, do window + preferences + java + buildpath + user libraries + import(c:\bogus.userlibraries) 3. Create a project P and from the context menu do -> build path + add libraries + user libraries + improperlybuiltlibrary + OK 4. You should see a build path problem report : Project 'P' is missing required library: 'C:\bogus\non-existent\path\jarfile.jar'
Created attachment 119358 [details] Patch with fix and test The concerned methods have been changed so that the name of the container gets tunnelled through and gets used in the diagnostic: for example, we now say: "Project 'P' is missing required library: 'C:\non\existent\library' (contained in 'improperlybuiltlibrary')". At first sight, it appeared that a few more diagnostics issued in ClasspathEntry.validateLibraryEntry would also have to change in similar lines (for example, classpath_unboundSourceAttachment), but upon further analysis, these code paths containing the said other diagnostics never gets taken (i.e sourceAttachment parameter is always null). Jerome, please review and help take it to commit. Thanks!
>"Project 'P' is missing required library: 'C:\non\existent\library' (contained >in 'improperlybuiltlibrary')". I still don't like the wording as 'P' is not missing anything, instead the library it references is not correctly setup. I would say something like: The (user) library 'name goes here' references non existing library 'full library path goes here'. Also, I would not mention the project (name) in the message at all since we normally also don't do this, e.g.: The project was not built since its build path is incomplete. Cannot find the class file for java.lang.Object. Fix the build path then try building this project
> --- Comment #5 from Dani Megert <daniel_megert@ch.ibm.com> > 2008-12-03 05:55:54 -0400 --- > >"Project 'P' is missing required library: 'C:\non\existent\library'(contained > >in 'improperlybuiltlibrary')". > I still don't like the wording as 'P' is not missing anything, instead the > library it references is not correctly setup. Personally, I think it is clear enough as it is, but I am open to considering your suggestion. Jerome, please chime in with your thoughts so we can finalize on this. > I would say something like: > The (user) library 'name goes here' references non existing library 'full > library path goes here'. This message is certainly good, though personally I don't necessarily agree with the "don't mention project name" part. Again, can't say I feel strongly about that. > Also, I would not mention the project (name) in the message at all since we > normally also don't do this, e.g.: For what it is worth, there are several counter examples in the same area :(class path validation): classpath_cannotReadClasspathFile = Unable to read ''.classpath'' file of project ''{0}'' classpath_cannotReferToItself = Project ''{0}'' cannot reference itself classpath_cannotUseDistinctSourceFolderAsOutput = Source folder ''{0}'' in project ''{2}'' cannot output to distinct source folder ''{1}'' classpath_cannotUseLibraryAsOutput = Source folder ''{0}'' in project ''{2}'' cannot output to library ''{1}'' classpath_closedProject = Required project ''{0}'' needs to be open classpath_couldNotWriteClasspathFile = Could not write ''.classpath'' file of project ''{0}'': {1} classpath_cycle = A cycle was detected in the build path of project ''{0}'' classpath_duplicateEntryPath = Build path contains duplicate entry: ''{0}'' for project ''{1}'' classpath_illegalContainerPath = Illegal classpath container path: ''{0}'' in project ''{1}'', must have at least one segment (containerID+hints) classpath_illegalEntryInClasspathFile = Illegal entry in ''.classpath'' of project ''{0}'' file: {1} classpath_illegalLibraryPath = Illegal path for required library: ''{0}'' in project ''{1}'' classpath_illegalLibraryArchive = Illegal type of archive for required library: ''{0}'' in project ''{1}'' classpath_illegalExternalFolder = Required library cannot denote external folder: ''{0}'' for project ''{1}'' classpath_illegalProjectPath = Illegal path for required project: ''{0}'' in project ''{1}'' classpath_illegalSourceFolderPath = Illegal path for required source folder: ''{0}'' in project ''{1}'' classpath_illegalVariablePath = Illegal classpath variable path: ''{0}'' in project ''{1}'', must have at least one segment classpath_invalidClasspathInClasspathFile = Invalid build path in ''.classpath'' file of project ''{0}'': {1} classpath_invalidContainer = Invalid classpath container: ''{0}'' in project ''{1}''
>For what it is worth, there are several counter examples in the same area >:(class path validation): Sure, however this problem (or to be more precise: the source of this problem) is not directly related to the project. It would even be OK to report a problem against the workspace root when there's no project in my workspace because the library itself is broken no matter whether I use it on a project or not.
> --- Comment #7 from Dani Megert <daniel_megert@ch.ibm.com> > 2008-12-03 06:28:53 -0400 --- > >For what it is worth, there are several counter examples in the same area > >:(class path validation): > Sure, however this problem (or to be more precise: the source of this problem) > is not directly related to the project. It would even be OK to > report a problem > against the workspace root when there's no project in my workspace because the > library itself is broken no matter whether I use it on a project or not. Fair enough. I'll wait for all the review feedback to arrive and take it forward accordingly.
I think I agree with Dani that the project name is not needed in this case since the library is really missing from the container. Also the marker is attached to the project and the Problems view shows the project name. So we would not loose information. However as you found out in comment 6, we are not consistent. That might be worth opening a separate bug report. So I would remove the project name as Dani suggested. Also for the other diagnostics like classpath_unboundSourceAttachment, I see a code path to this one. We just don't have a test for it (which is bad). For example, I believe that org.eclipse.jdt.core.JavaConventions.validateClasspathEntry(IJavaProject, IClasspathEntry, boolean) leads to checking the source attachment.
> --- Comment #9 from Jerome Lanneluc <jerome_lanneluc@fr.ibm.com> > 2008-12-03 10:16:51 -0400 --- > I would remove the project name as Dani suggested. OK, I can organize this. > Also for the other diagnostics like classpath_unboundSourceAttachment, I see a > code path to this one. We just don't have a test for it (which is bad). For > example, I believe that > org.eclipse.jdt.core.JavaConventions.validateClasspathEntry(IJavaProject, > IClasspathEntry, boolean) leads to checking the source attachment. I had looked into this scenario before concluding the said code paths to be not reached. There is indeed a test case org.eclipse.jdt.core.tests.model.ClasspathTests.testClasspathValidation05() that invokes the method org.eclipse.jdt.core.JavaConventions.validateClasspathEntry with checkSourceAttachment srt to true. But control still doesn't reach the validateLibraryEntry method. By tweaking the test somewhat I can reach the point of interest. I'll work on introducing variants for this message also.
Created attachment 119607 [details] Patch with review comments incorporated - Changed the error message per earlier comments - Fixed a few other messages to mention the container name so the context and the connection is clearer to the user - Added several tests to exercise the different code paths and elicit the various new form diagnostics.
(In reply to comment #11) > Created an attachment (id=119607) [details] > Patch with review comments incorporated > > > - Changed the error message per earlier comments > - Fixed a few other messages to mention the container name so the context > and the connection is clearer to the user > - Added several tests to exercise the different code paths and elicit the > various new form diagnostics. > Unfortunately, with this patch the following test fails on Linux: org.eclipse.jdt.core.tests.model.ClasspathTests.test232816b() Rerun org.eclipse.jdt.core.tests.model.ClasspathTests org.eclipse.jdt.core.tests.model.ClasspathTests test232816b(org.eclipse.jdt.core.tests.model.ClasspathTests) junit.framework.ComparisonFailure: Failed to find marker. ----------- Expected ------------ The user library 'SomeUserLibrary' references non existing library 'C:\non\existent\bogus\library.jar' ------------ but was ------------ --------- Difference is ---------- expected:<[The user library 'SomeUserLibrary' references non existing library 'C:\non\existent\bogus\library.jar']> but was:<[]> at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertStringEquals(TestCase.java:230) at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertEquals(TestCase.java:206) at org.eclipse.jdt.core.tests.model.AbstractJavaModelTests.assertMarkers(AbstractJavaModelTests.java:686) at org.eclipse.jdt.core.tests.model.AbstractJavaModelTests.assertMarkers(AbstractJavaModelTests.java:659) at org.eclipse.jdt.core.tests.model.ClasspathTests.test232816b(ClasspathTests.java:269) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.runTest(SuiteOfTestCases.java:100) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.superRun(SuiteOfTestCases.java:84) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$1.protect(SuiteOfTestCases.java:72) at junit.framework.TestResult.runProtected(TestResult.java:124) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.run(SuiteOfTestCases.java:81) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:574) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:195) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:366) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:550) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:505) at org.eclipse.equinox.launcher.Main.run(Main.java:1237) at org.eclipse.equinox.launcher.Main.main(Main.java:1213)
Also I'm wondering if the new API IJavaModelStatusConstants.INCOMPATIBLE_JDK_LEVEL_IN_CONTAINER is really needed. If it is, shouldn't it be used like INCOMPATIBLE_JDK_LEVEL (see JavaProject.createClasspathProblemMarker(IJavaModelStatus) for example)
Created attachment 119748 [details] Patch with linux failure & review comment addressed. > --- Comment #12 from Jerome Lanneluc <jerome_lanneluc@fr.ibm.com> > 2008-12-05 11:22:35 -0400 --- > (In reply to comment #11) [...] > Unfortunately, with this patch the following test fails on Linux: > org.eclipse.jdt.core.tests.model.ClasspathTests.test232816b() Dumb mistake, sorry. This should be fixed now. > --- Comment #13 from Jerome Lanneluc <jerome_lanneluc@fr.ibm.com> > 2008-12-05 11:25:36 -0400 --- > Also I'm wondering if the new API > IJavaModelStatusConstants.INCOMPATIBLE_JDK_LEVEL_IN_CONTAINER is > really needed. > If it is, shouldn't it be used like INCOMPATIBLE_JDK_LEVEL (see > JavaProject.createClasspathProblemMarker(IJavaModelStatus) for example) Both points are correct - I have eliminated the new symbol altogether now. Please take a look again and let me know if anything is still amiss.
Comment on attachment 119748 [details] Patch with linux failure & review comment addressed. Fix and tests are good
Fix and tests released for 3.5M4
Verified for 3.5M4 using I20081208-1800
