tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: unit test debugging under Netbeans
Date Wed, 28 Dec 2011 12:27:26 GMT
2011/12/28 Brian Burch <brian@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message