2011/12/28 Brian Burch <br...@pingtoo.com>: > When I submitted a bug and fix recently, I promised to develop some unit > tests to demonstrate the behaviour of my change. > > I don't want to get into a *#!&ing contest here, but I switched away from > eclipse a long time ago, when IBM threw in the towel over not having a pure > java workbench. Having invested a lot of energy in understanding netbeans > I'm a committed (but not always happy) user. > > I've been using netbeans successfully to debug tomcat and used it > extensively when investigating > https://issues.apache.org/bugzilla/show_bug.cgi?id=52303. > > I didn't realise you had a section on the tomcat wiki > http://wiki.apache.org/tomcat/FAQ/Developing#Q3 > because I'm more than comfortable enough to wade through setting up a > netbeans project for something as complex as tomcat from scratch. > > However, I was a bit surprised to discover I couldn't simply "wire up" > netbeans to compile, run and debug any of the tomcat unit tests! > > netbeans provides three standard ide actions for what it calls "free-form > ant projects", such as tomcat. These ide actions expect the ant build.xml > for the project to have three corresponding targets that can be "connected" > to these actions.
Are you saying that NetBeans cannot run an arbitrary user-chosen target of build.xml, but needs them to have specific names in English? It cannot run an arbitrary target under debugger? Note, that you can specify a single test name in build.properties. > > I would be happy to update the wiki to describe this process, but I don't > want to write a load of stuff about modifying the checked-out build.xml when > it would be MUCH easier to commit my changes to the trunk first. My changes > are intended to be completely safe when ant runs outside netbeans. > > I'll just describe the changes for now, to see what kind of reaction I get: > > 1. existing runtests macro: netbeans looks for a brief non-file junit > formatter so that it can hoover junit results when running a single unit > test class and then prettily present them within the workbench gui. I have > added such a formatter, but made it conditional upon running under netbeans > and wired it to the run-single ide action. Formatter is configurable since 7.0.24. > 2. new target compile-selected-files-in-test: the name of this target is > defined by netbeans convention. I have a cut-n-paste mod of the existing > test-compile target that accepts a list of classes to compile, because I > couldn't see a trivial change to your existing target. You must compile all files and pack them into jars etc. as needed. It is not possible to compile a single file. > > 3. new target debug-selected-file-in-test: this is a cut-n-paste mod of the > runtests macro. I need to run junit under the jvm debugger and attach the > netbeans nbjpdastart ant task to let the gui control the test. The same as above. > So... can I submit a patch for these three changes to build.xml? I am sure > this will make some of you nervous, but it seems the cleanest approach to > me. > > How (specifically) should it be submitted - bugzilla? > Yes. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
