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.
I have three freeform projects; DOIStudio, DOI and Effie. DOIStudio uses DOI and Effie. DOI uses Effie. I can never set breakpoints in the current project, nor in the JDK. When debugging DOIStudio, I can set breakpoints in DOI. When debugging DOI, I can set breakpoints in Effie. In all cases, the breakpoints are listed correctly in the Breakpoints window. I can use "Go To Source", so NetBeans has no problem locating the source. (How NetBeans does that is beyond me since there is AFAIK no way to specify, in project.xml, where the source for dependent libraries can be found.) In other words, it LOOKS like the breakpoints are set correctly, its just that the debugger never stops on them. This is the Ant task used to start the debugger: <target name="debug" depends="compile" if="netbeans.home" description="Debug Project"> <fail message="Property 'main.class' not set." unless="main.class"/> <fail message="Property 'run.jvmargs' not set." unless="run.jvmargs"/> <fail message="Property 'application.args' not set." unless="application.args"/> <nbjpdastart name="${main.class}" addressproperty="jpda.address" transport="dt_socket"> <classpath> <path refid="run.classpath"/> </classpath> </nbjpdastart> <java classname="${main.class}" fork="true"> <jvmarg value="-Xdebug"/> <jvmarg value="-Xnoagent"/> <jvmarg value="-Djava.compiler=none"/> <jvmarg value="-Xrunjdwp:transport=dt_socket,address=${jpda.address}"/> <jvmarg line="${run.jvmargs}"/> <classpath> <path refid="run.classpath"/> </classpath> <arg line="${application.args}"/> </java> </target>
This problem I have now found seem to be caused by an invalid sourcepath. If you specify it explicitly the problem goes away. The source directories for the project are specified in project.xml and hopefully we will also be able to specify dependencies to libraries and other projects. If freeform then maintains a property file where the complete sourcepath is available we could use that property in a <sourcepath> sub-element and this isn't an issue anymore.
You can set package roots, classpath items, etc. to whatever you like, incl. defining them based on property files shared with your build script. Closing in lieu of any clearly stated request; original bug was admitted to be caused by some sort of misconfiguration (not sure what).
closed