Community
Participate
Working Groups
hi, i'm usign classpath-variables to improve the "proitability" of my .classpath-file. for example i defined a variable "GL4JAVA" that points to my gl4java.jar on systems where GL4Java is not installed, and i'd like to define an "empty" classpath-var on systems where is properly installed in the ext-dir of java. the problem is, that i cannot define "empty" classpath-vars. another problem is, that a classpath variable can only contain one folder or JAR-file. from my point of view that isn't reasonable. i'd to define one classpath-var pointing to all GL4Java JAR files (there are 4 of them).
with "portability of my .classpath-file" i mean, that i checkin the file to CVS which is very usefull, but the PCs used in our teams differ - some have a complete systemwide GL4Java installation, some only have a user-installation, which means that eclipse doesn't use the JARs by default, because they aren't in the ext-folder of the JDK.
Then you should contribute a classpath container to solve your need. A container can be empty or encapsulate a set of libraries/projects. There is no UI to define these at the moment, these have to be programmatically contributed (like JRE containers).
what's the difference between classpath-vars and classpath-containers? why not only have one of them? what's the difference? between them? and if can't define classpath-containers, this hint it nearly useless for me :-( can i take you message as a hint, that an UI for designing classpath-containers is on the TODO list?
Eclipse is both an IDE and a framework. The fact we (JDT/Core) provide a functionality like containers, doesn't mean it is reflected in the IDE directly, but can be made accessible to Eclipse extension or certain features will use them. For instance, installed JREs are implemented in term of containers. There is no UI for defining custom containers upon user request, but this issue is well-known, and already sitting on our TODO list (of course). Variables were designed much earlier with a far smaller intent in mind. Now, one alternative you could use is to use a designated project as a container. Define a Java project GL4JAVA, referencing all relevant libraries on its build path, and exporting them. Then any subsequent project which will prerequisite GL4JAVA on its build path, will automatically gain access to its exported libraries. This also allows you to browse in context, and share this library project.
Is it ok to close?
Closing.
I think it's OK to close this "bug", but what is the eclipse-team to do about it? Will Eclipse 3.0 keep the current way of handling classpath vars/containers or is there some improvement in progress?
