Since it's inefficient to generate many XML output files for each test program, 
we
prefer the issue to be fixed on the Hudson side.

We are using Hudson as our CI server as well, like the original poster has 
said. Since 
JUnit outputs multiple XML files, in order to allow broader compatibility with 
existing 
tools, I believe gtest should also offer an similar option to output multiple 
XML files.

I understand it's inefficient at times to generate multiple XML output files 
for each 
test (class), but as long as it is provided as an additional option 
(--gtest_output 
...), we can satisfy both camps of people.

Although a workaround is available, we prefer to keep our build system clean 
and not 
have to depend on Perl or other translation facilities.

Is it possible to raise the priority of this issue?

Charles found this thread: 
http://www.nabble.com/Re:-Getting-Hudson-to-understand-
Googletest-XML--p22182483.html

According to it, if we change the root element from "testsuite" to 
"testsuites", the 
output will work with Hudson.

Google Test was designed to match our internal tools which expect the
XML report to match the format of those produced by the "junit" Ant
task, which has "testsuite" as the root element.

The format Hudson uses corresponds to the "junitreport" Ant task,
which has "testsuites" as the root element.

Unfortunately, if we change Google Test's format, we will break the
build system integration at Google.  I see two possible solutions:

1. Make Hudson support the "junit" format in addition to the
"junitreport" format.
2. Make Google Test support generating both formats, e.g. we can
continue to use --gtest_output=xml to select the current format, and
use --gtest_output=xmlreport to select the junitreport-style format.

We can work on #2, but given the limited resources, we may not be able
to get to it soon.  Therefore, I'm asking Charles to talk to the Hudson guys to
see if they can get #1 done quickly.  Meanwhile, I'm changing the priority of 
this 
issue to Medium.

As long as you have configured Hudson to do the jobs with an Ant build script, a
simple workaround for renaming the root element of the Googletest XML log is to
append a <replace> task to the call of the executable. 
Let us assume that you have a build target called 'run_test' that simply calls 
your
googletest tests called 'GoogleTests.exe'. Then the following XML snipplet will
execute the test and rename the root element of the created XML log so that 
Hudson
will render the junitreport properly:

<target name="run_test" description="Runs the googletests and translates the 
log">
  <exec executable="GoogleTests.exe">
     <arg value="--gtest_output=xml:GoogleTests.xml" />
  </exec>
  <replace file="GoogleTests.xml" token="testsuite tests" value="testsuites tests" />
</target>

However, this is just a workaround for the 'junitreport'. In the end, I would
appreciate a solution implementing njreiman suggestions (additional output 
options).

Hmm -- that ant <replace> task is definitely cleaner than calling out to perl.  
But 
again, I would still prefer separate XML reports for each class, as that better 
reflects JUnit's behavior and is easier (for humans) to parse.

I think the --gtest_output=xmlreport option is probably the best suggestion 
we've had 
so far.  If I have some time in the next weeks, I'll try to write a patch for 
this, 
since the gtest team understandably has bigger bugs to squash first.

I talked with more people at Google, and we decided that we will change our 
internal
format to match the junitreport Ant task.  Therefore the plan is to change the
behavior of --gtest_output=xml to generate junitreport.  We won't be adding a 
new
option --gtest_output=xmlreport.  At least not yet.

Editing the subject to match what we plan to do.

Implemented in the trunk.

Which version do you mean by trunk? I am using gtest 1.3.0, but I am having 
trouble
parsing the generated XMLs with Hudson?

The "trunk" means the development branch in the source code repository, which 
can be 
accessed here:

http://code.google.com/p/googletest/source/browse/#svn/trunk

Or if you prefer, you can just wait until version 1.3.1.

When will be the 1.3.1 version be available?

Since this is still not released 5 months later, I've attached an XSLT file 
that does
the fix:

Which can be applied in ant by doing something like:

<xslt in="test_detail.xml" out="TEST-results.xml" style="fix-testsuites.xsl"/>

This issue is now fixed in 1.4.0 release. Cheers!