Bugzilla – Full Text Bug Listing
| Summary: | allow a launch configuration classpath to be "default plus" | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Lee Breisacher <lbreisacher> |
| Component: | Debug | Assignee: | Luc Bourlier <eclipse> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | eclipse, evgruijthuijsen, luke.evans, nikolaymetchev |
| Version: | 2.1 | ||
| Target Milestone: | 3.0 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Lee Breisacher
Deferred Consider for 3.0 *** Bug 36251 has been marked as a duplicate of this bug. *** We should allow users to prepend and append to the default classpath and bootpath. *** Bug 45057 has been marked as a duplicate of this bug. *** I have reworked the Java Classpath Tab to present a UI that will allow us to better proceed with fixing this bug. I experimented with using a JDT CORE "classpath container" to represent the default classpath, but there are issues: * The container is contributed via a JCORE extension point, and thus it also shows up as possible to add to a project's build path (which we don't want) * The classpath tab just feels unituitive to use. The mapping of what you see in the tree to what appears on the command line is not obvious. I'm wondering if we have the wrong UI for this, in general? Question to bug reporters, and those interested: When you use a non-default classapath, what are you generally doing? (adding an extra jar? adding projects?...) Does the current UI feel right? What would be better? We would use this feature extensively as we have a few projects with considerable dynamic behaviour (i.e. plug-ins, extensions, whatever). Some directive to our program can cause the need to have some extra classes on the classpath at runtime, but these are certainly not things we want to have checked-in to the project or otherwise on the project's build classpath. Besides, in many cases, both the configuration and location of the extension classes change completely depending on the individual and how they are testing the product. JDBC drivers are another example of this. We often want to test our product from within the IDE (i.e. debug it), and want to have different JDBC drivers on the runtime classpath. Like it or not, different people have different drivers installed, or installed in different locations. However, they just want to create execution profiles citing the drivers they need and the appropriate options/ properties to start the program with the right configuration. Not sure what you mean the "current" UI - I'm using M4. But I don't really care too much about how wonderful the UI is for this because it is not I would use very often. I setup my runtime classpath and leave it. As for what I do with it, I am simply adding an external directory (that has, e.g. some dynamically generated classes) or sometimes I'll add another project (that also has some separately generated classes). My project has a long (build) classpath and I want the runtime to have all of that, plus a few extras. As the M6 focus is on cleaning up the more minor bug backlog, moving to M7 Fixed. The Java launching plug-in now allows for an extensible set of runtime classpath entries (although the extension point is currently considered "internal"). I have created a "Default Project Classpath" entry. It is added to the classpath when "Restore Defaults" is used, or when a new configuration is created. We may want to add this to the "Advanced" options in the future (i.e. add a default classpath for a specific project). @see IRuntimeClasspathEntry2, DefaultProjectClasspathEntry. Please verify, Luc. Verified. I filled bug 51082 for a javadoc problem. |