Summary: | Improved classpath variables | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Sven Köhler <sven.koehler> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | ||
Version: | 2.1 | ||
Target Milestone: | 3.0 M3 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: |
Description
Sven Köhler
2003-07-16 20:07:02 EDT
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? |