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.
build.xml checks for tools.jar in java home, and fails if it doesn't find them which is the case under MacOSX with jdk 1.4.1. It should not, as classes in tools.jar can be in different locations or even be found in a different jar depending on the SDK-OS provider. Anyways, if Ant need a class from tools.jar, he will find them if the classpath is well built. Fix: remove <fail> tags within all build.xml in the source tree whenever tools.jar is not found and just echo a warning instead.
Not sure we want to fix this. You may also set property jdkhome-valid to any value to workaround this (at least in module nbbuild). Jesse would you comment on this? I guess you are the author of the jdkhome checking code.
Changing the <fail> to <echo>WARNING...</echo> makes sense to me.
Please see Mac OS X howto at http://www.netbeans.org/kb/articles/mac.html You can simply add -Djavahome-valid=true option to commandline when you start build.
Tim is this now FIXED?
It's working on being fixed. As we discussed now, it works now, but not for the right reason. I imagine I'll swap it with something like <available classname="com.apple.eawt.Application" property="isMac"/> ... I seem to remember some way to declare an if/unless based on the platform (more granular than is it unix or isn't it), but after digging through various scripts and the ant docs for about an hour I haven't found it.
It's fixed now: <available classname="com.apple.eawt.Application" property="is-mac"/> ... <target name="setup-jdkhome-apple" depends="setup-jdkhome-1" if="is-mac"> <property name="jdkhome-valid" value="${java.home}/../Classes/classes.jar"/> </target> AFAIK this should work everywhere, and allow the jar to be indexed by those things that need to in the build process. Checking in build.xml; /cvs/nbbuild/build.xml,v <-- build.xml new revision: 1.461; previous revision: 1.460 done Checking in default.xml; /cvs/nbbuild/default.xml,v <-- default.xml new revision: 1.10; previous revision: 1.9 done
I don't like this fix since it depends on jar name. As Tim already knows - we ought to avoid assumptions about names of jars. If you really need to do it this way I would suggest: <target name="setup-jdkhome-apple" depends="setup-jdkhome-1" if="is-mac"> <property name="jdkhome-valid" value="true"/> </target>
I don't like depending on jar names either, but Jesse pointed out that some modules (?) want to index the jar's contents as part or the build process (or something - I'm guessing that's what), and so they just *have* to have a path to the jar. Other than for pre-building a code completion database, that sounds like a bug in those module's build process, but who am I to say...
Sorry, but I really think it's wrong to rely on any jar name within the SDK, as it is a non standardized fileystem layout. If any module needs to index files within tools.jar, these module should find the jar that provide the given class they look for and index all the files within this jar. The fix make the whole build process weaker, as it introduce filesystem struture and OS depencies...what take place if Sun or Apple change the name of the jar in a futur release?! Changing the <fail> to <echo>WARNING...</echo> should be sufficient for other module to fail building if the class it uses in tools.jar is not found. With onyl the compiler error (and the warning), it's easy to trace back the problem to the missing jar, isn't it?
Need to review usage of path to tools.jar in various modules that rely on it (e.g. debuggerjpda). Ideally JDK tools should be accessible in the compilation classpath only of those modules which explicitly request it. Of course it would be preferable to not make assumptions about JDK layouts, but we *do* have to make some assumptions because we are building against JPDA interfaces, etc., which are not part of the JRE. If vendors make changes to file layout, we may need to track them. Note that the runtime launcher also searches for JDK-specific JARs, AFAIK.
Reassigning - I'm definitely not the person to assess the debugger's usage of tools.jar.
As there is no <fail> tag in debugger build xmls, this issue is probably fixed. Feel free to reopen it, if you see some other possible imporvements.
The <fail> part was fixed long ago. This was assigned to debugger because of its usage of tools.jar, cf. e.g. my comments on May 03. But I am too tired to keep tracking this issue.
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.