This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | No support in GUI for tools.jar in classpath | ||
|---|---|---|---|
| Product: | java | Reporter: | Stacy <stacy> |
| Component: | Platform | Assignee: | Tomas Zezula <tzezula> |
| Status: | NEW --- | ||
| Severity: | blocker | CC: | jglick, mgrebac |
| Priority: | P3 | ||
| Version: | 4.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | ENHANCEMENT | Exception Reporter: | |
| Bug Depends on: | |||
| Bug Blocks: | 41535 | ||
|
Description
Stacy
2004-08-03 16:30:37 UTC
Rather an enhancement than P2 defect I would say. You need only edit the classpath for your platform definitions to include tools.jar, then you do not need a library definition at all. There is no UI for it but it can be done in the build script, but it is not easy. I am not going to introduce library to platform dependency, but in the next release (promo-E) the platform will allow user to change the bootstrap libraries (and probably also standard libraries) in the platform customizer. Then you will be able to add the tools.jar into the platform specific boot/standard classpath. This seems to me to be a quite valid requirement for enhancement of UI of PlatformManager. Reopening it. I was trying to port some project to Netbeans. I had hard times, and had to do a lot of manual work editing project.properties and project.xml, because the UI very often added or replaced relative references as absolute, ... but I was able to overcome this by manually editing the file. The blocker for me however is adding tools.jar to the classpath of the project (shared in cvs of course), so that it works for everybody. I don't know how to do it, and I doubt there's a reasonable way to do it, thus raising priority of the enhancement and changing target milestone. I hope NB 6 will be able to address the problem. To the proposal of enhancement - possibility of adding tools.jar into classpath is a little way around it, but then everybody has to tweak his platform in the beginning to add this jar manually. I'd prefer a way to be able to reference jdk jars through build.properties somehow. To Martin:
Anything added to the project's compile, execute classpaths is relative if
possible (it has a common disk root).
The problem with tool.jar is another one, it should be relativized to JDK not to
the project. Currently there is no way how to solve it, it would require project
to let change the JVM classpath. You can work around it by using non default
platform and adding tools.jar in the following way:
javac.classpath=${platforms.MyPlatform.home}/lib/tools.jar
For default Java platform you can simply use
javac.classpath=${java.home}/../lib/tools.jar
Of course this is not portable to non-Sun JDKs, but then using tools.jar implies
nonportability anyway.
Probably should just be WONTFIX with a FAQ entry. Or ReferenceHelper.addExtraBaseDirectory may be able to infer a proper relative
path if you just add tools.jar via file chooser from Add JAR/Folder, just as it
infers ${basedir}/${relpath}. With the API as it currently stands,
${platforms.MyPlatform.home}/lib/tools.jar would work but
${java.home}/../lib/tools.jar would not (as the method requires a property name,
not an unevaluated text fragment).
WONTFIX? I'm really confused by the different comments. I think I tried
${java.home} for sure, but it didn't work. I'll try again, though.
|