Bugzilla – Full Text Bug Listing
| Summary: | Add button disabled on New Classpath Variable Entry dialog | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Gary Schiltz <gschiltz> |
| Component: | UI | Assignee: | Martin Aeschlimann <martinae> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | assaf, erich_gamma, gro, mccull1, mlq.eclipse |
| Version: | 2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 2000 | ||
| Whiteboard: | |||
|
Description
Gary Schiltz
the bug is that you can double click. The add button is disabled if the variable resolves to a folder and you have to give an extension to complete the path to a JAR fixed > 20020529 Martin, would you clarify your comments? Perhaps I don't understand the purpose of classpath variable entries, but I assumed they should be able to refer not only to Jar/Zip files, and also to directories. After all, that's the way the CLASSPATH environment variable works in Java, i.e. a separated (by ';' in Windows and by ':' in Unix variants) list of Jar files, Zip files, and directories in which to search for Java packages (i.e. directory heirarchies) that contain Java class files. Since I haven't gotten an answer yet, and I've seen several postings regarding this topic (i.e. "add Folder with ".class" files to CLASSPATH"), I'm reopening this bug. In F2 & F3, I can't add a classpath variable that points to a folder to my project. In previous builds, I could. In (I believe) F1, I could do it by defining the CLASSPATH variable to be one directory up from the directory I wanted, then I could "Extend" it to a directory (not just a .jar/.zip). If I modify the .classpath file directly, or if I import an existing .classpath file that I created with F2 (or even WSAD 1.0.137), and have it reference a CLASSPATH variable that points to a folder, then it works. Even though the variable is grayed out in the build path window, my classpath operates as I would expect it. Currently, I have a /resources folder which contains about 300MB of test files, which I need on my classpath (class.getResource() calls). I really prefer not to define this as a source folder and have them copied every time a rebuild happens -- it takes an absurd amount of time and seems unnecessary. Likewise, I do not want to have to modify the runtime classpath for each independently executable test case that references things in the /resources folder. I submit that the CLASSPATH variables should be allowed to point to folders, and I would also say it's critical for Release 2 -- especially since this is currently possible in R1.0 and all the WSAD 4.X users will expect it to work in WSAD 5.X. -Andrew The same problem with "Attach source", it must permit adding folder with ".java" files, not only jars or zips. It's especially inconsistent that you can DEFINE a variable to point to a
directory (i.e. Window->Preferences->Java->Classpath Variables->New->Folder...)
but you can't reference the newly created variable in a project using the
method I described when I first opened this bug. As a workaround, you can close
the project, manually edit its .classpath file, and add an entry as follows (in
this example, I have a variable "MY_CLASS_DIR" defined):
<classpathentry kind="var" path="MYCLASSDIR"/>
Not the best use of the GUI, but it works (maybe I'd better keep quiet - after
I initially reported a workaround for the bug, it was "fixed" by removing the
workaround :-)
Arghhh... Bugzilla ate a line from my last comment. Here it is, hopefully intact: It's especially inconsistent that you can DEFINE a variable to point to a directory (i.e. Window->Preferences->Java->Classpath Variables->New->Folder...) but you can't reference the newly created variable in a project using the method I described when I first opened this bug. As a workaround, you can close the project, manually edit its .classpath file, and add an entry as follows (in this example, I have a variable "MY_CLASS_DIR" defined): "<classpathentry kind="var" path="MY_CLASS_DIR"/>" (remove the outer quotes from the above) ... martin - pls comment Sorry for the delayed answer, I was away for 2 weeks. There is in deed an inconsistency between UI and JCore. JCore would allow to have a Variable entry on the classpath that points to a folder. UI only supports variable entries pointing to JARs. Variable set to a folder need to be extended (ECLIPSE_HOME/xy/myjar.jar). The original variable concept only supported JARs, folders were added later, The UI never cought up, as we were not really conviced of the usefulness of the concept: Note that a unsolved problem is the refreshing of external files. There are also only external JARs and no external folders. Yes, you can modify the .classpath file directly, but note that you are in a more or less untested area. To point to a folder, can't you use a class folder? Does the folder really has to be on an external location? In my case, the folder's location is almost irrelevant to my problem. Sometimes the folders are external, but many times they are within the project/workspace. However, I would encourage you to allow references to external folders -- so many people expect to be able to do it that it is a constant issue in the newsgroups and elsewhere. The main issue for me _right now_ is performance. I will have to look into the "Class Folder" -- I haven't noticed it before now. As I mentioned in my previous comment, If I specify the resource folder (which contains files used in testing, as well as some configuration files (XML, .properties, etc)) as a source folder, any rebuild takes MUCH longer, because there is 250-300 MB worth of files in that folder. Copying them to the /bin folder is an unnecessary and time consuming step for me. Refreshing is also a problem for me, but the opposite of what you may think. Since these resource files are more easily edited outside Eclipse, if I define the folder as a source folder and edit files in that folder, changes are NOT copied to the /bin folder unless I explicitly refresh the folder, as Eclipse has no way of knowing I edited the file. The first time this happened to me it had me scratching my head for a minute, until I realized what was going on. Now, in my team, we have a lot of less-experienced Eclipse users. While I am familiar with how Eclipse works in some detail, many people on my team would probably be even more confused if such a "refresh problem" happened to them. On the UI/JCore/Untested territory issue: We are in a mixed environment, with some user using WSAD and some (few) using Eclipse 2.0 builds -- so the .classpath was set up from a 1.0 build, including using source folders in the way I describe in my comments. Since the .classpath is shared and in Source Control for easier setup (pls see my comments about Eclipse experience levels), I only "discovered" that I could no longer specify a folder about a week after I was successfully running with a R1.0 .classpath file. Only later did I realize I was "cheating" -- this is why I mentioned that I think it is ciritical for 2.0 that it be consistent with R1.0 in this regard. FYI: Class Folders seem to work fine in my case. This, of course, assumes the resources are in the Workspace (which they are for me). -Andrew It is one of the points that I hope will be adressed first post 2.0: External folders and files. In my opinion, this has to be supported by core.resources, so JDT core would get correct resource change information. (when 'refresh' is called, see next section) Having this we could also remove the external JAR classpath entries, which are complicating the UI and code a lot. I don't know what's the latest news with automatic refreshing. I heard that there will be a plugin which periodically would do a 'Refresh workspace' (Or it could contain a native library to get the change events from the operating system). I will find out if my fix is a serious 1.0 compatibility violation. Thanks for your help - the class folder is fine for me. We are probably a little unique with the heterogeneous setup here, so perhaps the R1.0/R2.0 issues are not as important as they sometimes seem to me. I hope to see external resources handled soon, too -- I am the reporter of bug 6664 which seems to have taken on a life of it's own -- and I of course agree that it is a platform-level issue. Thanks, -Andrew *** This bug has been marked as a duplicate of 22219 *** |