Community
Participate
Working Groups
When we try to assign a classpath variable assigned to dir inside project one dir up from output (classes) dir, we find this breaks search and refactoring tools. Furthermore, while we were able to do this in Eclipse 1.0, Eclipse 2.0 doesn't allow for us to do this through the UI. We are, however, able to manually add the classpath variable to the .classpath file and Eclipse 2.o will use that.
Can you provide exact steps to reproduce ?
Exact steps to reproduce: 1) Place a servlet engine inside the project directory containing a web root directory containing an unpacked WAR 2) Deploy and Configure Struts MVC framework in said WAR 3) Add the top level of the WAR to the Eclipse classpath as a Classpath Variable. The reason we need to do this is so that StrutsTest.jar (Struts' JUnit base test package) can find the struts-config.xml in the classpath, which is placed in <WAR>/WEB-INF). Note, you cannot add such a variable through the Eclipse UI in Eclipse 2.0. You must edit the ".classpath" file manually. Eclipse 1.0 allowed you to do this. Now everything compiles fine and runs fine, however search will no longer work (always returns without finding anything) and refactoring tools no longer work (will fail to do anything)
Smells like a search/model bug only.
I created a Java project P with the following .classpath file: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="var" path="JRE_LIB" rootpath="JRE_SRCROOT" sourcepath="JRE_SRC"/> <classpathentry kind="var" path="TEST"/> <classpathentry kind="output" path="a\bin"/> </classpath> and the variable TEST resolving to 'P/a' and I was able to search in this project. Could you please post your .classpath file?
Created attachment 1905 [details] .classpath file as requested
Were you able to _successfully_ search and find anything? Note: the searching sometimes works for a while with the classpath variable. It seems to die after a big compile happens or when eclipse is shut down and reopened again.
Yes I was able to search and find results. Note your setup is not officially supported (you're not supposed to edit the .classpath as this could break the conventions used in JDT, see JavaConventions.validateClasspath). However, if you provide a small self-contained test case (i.e. without refering to Tomcat), I can try to see what is going on. BTW do you have anything in your <workspace>/.metadata/.log file?
I can't give you a log output, I'm so very sorry, as we have discovered a workaround and have since rewritten the log serveral times :\ The workaround should help. We placed the struts-config.xml into the src/ directory and changed the MockStrutsTestCase child class to set the config file to that resource in the classpath. We then edited the web.xml file to point to the struts-config in the classes/ directory where eclipse outputs. This works for us now, as refactoring now works again and searching works without resorting to using a classpath variable, yea!! While I fully understand the issue of hand editing the .classpath file, you might consider people upgrading from earlier versions of Eclipse who were able to declare the classpath variable in the IDE and were no longer able to in subsequent versions.
It is always hard to be bug backward compatible :-) Since no one else has complained, and you have a workaround, is it OK to close this bug?
Doh! You're right! :-) I think it's OK to close the bug, but it begs the question as to why what amounts to a directory entry in the classpath should break these other tools? I mean why should a classpath that looks like this: -classpath /this/whatever.jar:/that/whazzit.jar work and a classpath that looks like this: -classpath /this/whatever.jar:/that/whazzit.jar:/my/fine/path/to/a/directory break? I'll try and create a contrived example that illustrates the behavior.
I think in your case the probleme is that the output folder is nested inside /my/fine/path/to/a/directory. This confuses the underlying Java Model which assumes that the contents of a library on the classpath will never change (and the output directory changes with each build). Closing
