On 28/12/11 22:27, Konstantin Kolinko wrote:
Thanks very much for your time and valuable thoughts, Konstantin.
2011/12/28 Brian Burch<br...@pingtoo.com>:
<snip/>
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?
I was saying that, but your question prompted me to check more carefully
and now I see I was wrong.
Netbeans automatically creates a build.xml and project.xml for most
kinds of new projects using "standard" target names and wiring them to
standard ide actions.
However, when "introducing" an existing project to netbeans as what it
calls a "free-form ant project", all the (rather confusing and
out-of-date) documentation assumes that you will adhere to the existing
naming conventions. I can now see that an ide action in project.xml can
be associated with any valid build target.
In other words, I do not need to create new targets simply to achieve a
redirect to an existing target that already does the desired job.
It cannot run an arbitrary target under debugger?
As far as I understand, that question makes sense with eclipse, but not
with netbeans.
Because netbeans projects are (always and only?) manipulated through
their ant build.xml (either created by wizards, or pre-defined in
free-form projects), all projects need a target that will start the jvm
in debugging mode and then call the nbjpdastart task to connect to the
debugger socket. If not, then you can't debug.
When I want to debug tomcat itself, I just run "catalina jpda start"
(thus running it outside netbeans) and tell netbeans to start a debugger
session to connect to the target jvm. However, when I want to debug a
unit test under the netbeans ide, I believe I need a suitable ant
target. However, I'll give your question more thought...
Note, that you can specify a single test name in build.properties.
Yes, I noticed that was the case. My netbeans project.xml already
assigns the ${test.entry} property to the selected fully-qualified
classname before calling ant to run my two new single test targets.
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.
Silly me! A ${test.formatter} property is defined immediately after
${test.name}! However, the runtests macro assumes I want usefile="true",
but that prevents netbeans from intercepting the results.
I will think about whether I really want both formatters active on the
same netbeans test run (as in my current version). If not, I need to
work out how to inject a value without the user having to change it in
build.properties, where it would affect non-netbeans test runs.
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.
I was talking about compiling a selection-list of unit test classes. I
remember that eclipse compiles classes on-the-fly. Netbeans /appears/ to
do the same thing, but it actually only compiles the class in the editor
window (to show compilation errors), not into the project build
directory. When you run an individual test class under netbeans, it MUST
have been previously compiled by the ant build.xml into the correct
output directory. This process seems to be working fine for me already
because netbeans/ant submits the individual class file to run under the
jvm/junit.
[note to self: the run-single and debug-single targets are dependent on
the test-compile target, thus triggering a compilation of the selected
single unit test file (if necessary), as well any other classes that
might have changed. Without it the user would be confused by testing an
old version of the class, while viewing the last saved version in the
workbench.]
Do unit test classes really get jar'd and run from the jar? (I couldn't
see this when quickly looking at the build.xml.)
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.
I felt it would not be appropriate to add a significant amount of
netbeans-specific conditional logic to the runtests macro to support
debugging of a single test class. It seems much "cleaner" to have a
separate ide-specific target, even though it needs to duplicate a lot of
the existing runtests logic.
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.
OK. I need to think about these issues and improve my changes first, so
you won't see anything specific for a couple of weeks.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
