Community
Participate
Working Groups
We see a strange discrepancy between a full build and an auto-build (when a resource is saved and automatically compiled). We see this compile error on a full build: CSS.System cannot be resolved ProcessComplianceOutput.java line 251 Even though this class *is* available on the build path. When this file is modified and saved, it *does* compile without errors..... The CSS.System is a *package* The class being imported is CSS.System.EventsHelper, but the error indicates that the package is the problem. Other classes in this package suffer from the same problem. However, classes in CSS.EDIExport package (same jar) are resolved fine. This problem does *NOT* occur when the source folder is *NOT* a linked resource
Which build are you running? Is any other tool modifying the linked folder?
I'm running 2.1 RC2, and a colleage is seeing the same behavior in 2.1 M5. The linked folder is a Clearcase managed folder on a server, but at the time of this test, nobody was modifying it. The jar with the classes that can't be resolved during a full build is an external jar on the build path.
Do you have anything relevant in the .log file?
no, nothing in the log that seems to relate to this problem.
Can you search all the folders on the buildpath to see if any include the package CSS.System? What happens if you move the external jar inside the workspace?
CSS.* only appears in the jar in question. Moving the jar into a lib folder inside the project, not linked and added with 'Add jar' makes no difference. The only thing (that I've found) that makes this work is to *NOT* use a linked source folder.... It's almost as if 'System' is treated specially or something, because other packages in the same jar are resolved fine.
This is very wierd. Is there any chance you can provide a small testcase in a project by itself pointing at the external jar file?
I've been trying to create a small project reproducing the problem, but so far I've been unable to. The project where this occurs is huge. Update: Another project not using linked source folder, but with the entire project on the remote clearcase monitored server is now also showing the same behavior. It boils down to: 1) full build fails with unresolvable package CSS.System, 2) editing a file with the above error to trigger an auto build makes the error go away, 3) other packages/classes in the same jar resolve fine regardles of the kind of source folders. I also tried unpacking the jar containing CSS.System into a folder and adding it as a class folder to the project's build path, no relief...
Can you provide a sample of one of the errors? Try copying a problem method into a type by itself. System is a well know type name in java.lang so its possible the compiler is getting confused. I have defined a package named CSS.System with some types & placed them in a jar file on my path, but I have no problem resolving the type names.
here's one: package com.psc.css.business.export.edi837; // other imports import CSS.System.EventsHelper; import com.vitria.fc.meta.EventDef; //other imports public class BatchProcessing { public static final EventDef errorEventDef = (EventDef)(EventsHelper.getMetaObject().findDef("ErrorEvent")); // other stuff } this gives the error: The import CSS.System cannot be resolved BatchProcessing.java Is that what you were looking for? The above is an excerpt from a file I do not currently have checked out, so it read-only. I have the EXACT SAME line in another file that I am currently editing and thus auto-compiling all the time, and there it works fine....???
No luck, it works fine for me. Can you take this excerpt and put it in its own independent project pointing at the jar file and have it fail? If so can you please add that project + jar file as an attachment to this PR.
No luck here either. Tried several different project setups, with and without linked folders, etc. Interestingly, if I highlight the offending class in the import statement in the project with the error, and use 'Search declarations' using the workspace as the scope, it finds the class file in the right jar.... Still, the build doesn't find it until I modify the source file with the import statement.
Could it be related to the read-only file? When you tried to reproduce it, did you set one of the file to be read-only?
yes I did, forgot to mention that, but I did make the class importing the CSS.System.EventsHelper read-only. No difference.....
Ok let's start again. 1. This is very reproduceable on every full build, right? 2. Is your workspace one large project? How many source files are in the project & in how many source folders? How many output folders: only 1 or 1 per source folder? 3. How many source files have 'strange' errors after a full build? Are all the errors the same (ie. import statements which cannot resolve CSS.System)? Or are their other packages which cannot be found? 4. It doesn't matter where the problematic jar file is relative to your workspace or whether its expanded into a folder, correct?
1. This is very reproduceable on every full build, right? yes. very 2. Is your workspace one large project? How many source files are in the project & in how many source folders? How many output folders: only 1 or 1 per source folder? this project has one toplevel source folder (src) and one output folder (classes). There are 73 packages containing a total of 612 java files. The build path has about 35 jars on it. There are other projects too, but those are not involved in this scenarios. This project does not have any dependencies on other projects or vice-versa. 3. How many source files have 'strange' errors after a full build? Are all the errors the same (ie. import statements which cannot resolve CSS.System)? Or are their other packages which cannot be found? All errors are related to the CSS.System package not resolving and this occurs in 7 different files in different packages 4. It doesn't matter where the problematic jar file is relative to your workspace or whether its expanded into a folder, correct? I've tried jar inside workspace with 'add Jar' and 'add external jar' I've not tried adding the source to the project's source folder and actually building it... (these are CORBA stubs built elsewhere) ------- Here's another scenario under which the errors dissapear: 1) open the readonly file in an editor (has the error) 2) use clearcase to check out the file 3) Eclipse detects change and shows dialog asking to reload 4) click reload, eclipse reloads, compiles and error goes away No change or modification is required, simply a change from read-only to read-write is enough...
Highly suspect this is a dup of bug 35128, however this seems to be only full build scenario failing, where 35128 is only incremental scenario failing.
Frank - I can post you a patch which you can try to see if it improves this issue for you ?
PLEASE! I'd love to try it
Please get the patch at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/patches/org.eclipse.jdt.core_2.1.0.zip
your patch fixed the issue. THANK YOU!
Excellent, we will keep trying to understand this very codepath (your steps are a little different from bug 35128). Marking as duplicate. *** This bug has been marked as a duplicate of 35128 ***
Frank: We updated the patch. Can you try it again and let us know that the new one works? thanks
still works, thanks again. I keep being amazed at the turnaround and responsiveness of this buf fixing process for eclipse. Keep up the good work!
This bug is partially back in the 2.1 general release. When I use clearcase external to eclipse to check out a file, eclipse detects the change, I click ok to reload it and Eclipse goes ahead and recompiles the file, no problems. However, the *EDITOR ONLY* starts showing the same compile problems as mentioned in the original bug report. The task list and explorer do not show the problem, only the editor.
Kent, would the SearchableEnvironment be causing grief here ?
The original bug we had & fixed was inside the LookupEnvironment of the Compiler. All other name environments are called by the LookupEnvironment to find types on disk. I suspect that this is something else. Frank: Since this happens only in the editor, any luck it happens everytime you browse the type? Can you reduce the testcase to something small?
I'm not sure I can reduce it to something small, but the following is the exact scenario: 1) I'm looking at a java source while it is read only (checked in) and there are no errors/warnings in the task list nor markers in the editor. 2) I use the clearcase explorer outside eclipse to check out this file and thus make it read/write 3) Eclipse detects the change and pops up the dialog to reload the file 4) It compiles the class and now shows markers in the editor for all CSS.System stuff, but the builder itself (i.e. tasklist) shows no errors. These markers do not go away upon checkin. I'm uncertain as to when they went away and why (since they're not there now, they must have dissapeared at some point after I submitted the initial reopen report)
Frank: Can you still reproduce this problem consistently? Does it happen to numerous types or just a few? Does it happen to the same ones all the time?
Yes, it's consistent, but only with types that are in the CSS.System package and only in the editors, the builder doesn't trip anymore.
So are these all the types which are defined in the CSS.System package or all the types which import this package?
the behavior occurs in classes importing the CSS.System.* stuff. These are CORBA IDL stubs generated elsewhere and available in a jar on the build path.
Deferring post 3.1
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
