Looking through my Referrers I stumbled over this Javalobby thread.
<junitreport> is supposed to work with JDK 1.5 (or Java 5 if you like) in Ant 1.6.2, there has been no change after that in CVS. The very first post in the thread says the task failed with
BUILD FAILED java.lang.OutOfMemoryError: Java heap spaceso the problem is insufficient heap space, not Ant's task. Try to give it more memory, using ANT_OPTS, for example. And come over to user@ant.apache.org ;-)
Java 1.5 comes with XSLTC as its default XSLT processor and maybe this one needs a whole lot of memory, even more than Xalan-J 2? Stephane reported quite a few problems with XSLTC and recommends using a recent version of Xalan-J 2 using the endorsed standards mechanism instead in the Ant bug report:
About XSLTC, I did a quick hack and I'm having a look but...it looks like I need to upgrade to 2GB of memory before getting some results from it. The memory usage is absolutely massive.
Running w/ JDK 1.5B1 (xalan 2.5.2) it jumps straight to 420MB and and I'm transforming a 32.3KB xml...I'm running out of memory (only have a 512MB laptop) about 60s later while it takes less than a second to perform the transformation with JDK 1.4 and endorsed Xalan 2.6.0 (w and w/o xsltc)
path: /en/Apache/Ant | #
After being happy with xCHM for a while now, I discovered a serious limitation, it doesn't support frames.
Not that I'd understand why anybody would need a frame to nail a header that contains nothing but the chapter's title inside the documentation, where the title is perfectly visible and the page isn't longer than a single screen anyway ... But there really are documentation files out there that require a frame enabled HTML viewer. The various "Microsoft Application Blocks for .NET" are examples.
Right now I've switched to split up the whole archive using chmlib's extract_chmLib and use a "real" browser to view the ".htm" files, but this is not really satisfying. Any better options for Linux and MacOS X out there?
path: /en/unsorted | #
Junfeng Zhang points to a beta of an overhaul of MSDN.
I've been accessing the .NET class library docs at MSDN quite a bit over the past weeks and always thought it was rather hard to navigate - in particular when compared to the Javadocs I was used to. I later realized that many of my usability problems with MSDN go away when I use IE since MSDN's navigation frame works a lot better there. But I rather don't want to switch machines between coding on Linux/Mono and reading docs.
First impressions of the new site:
I can now go to the docs of the String class via http://msdn2.microsoft.com/library/System.String and even to String's Length property via http://msdn2.microsoft.com/library/System.String.Length. This is a lot better than anything that has been there before. It doesn't work for http://msdn2.microsoft.com/library/System.String.Equals, though, but let's remember this is a beta.
http://www.javadocs.org/string#length() is even more concise, but it took many years to finally get there.
- The text is finally readable in Mozilla and friends, although the code snippets and the navigation are still a point or two to small. In the "old MSDN" the first thing I did was hitting CTRL-+ to increase the font size.
- I still have to click on "Foo Members" to see the methods offered by Foo - one more click than I need in Javadoc.
- One single frame and no JavaScript magic to synchronize a bigger frameset, yay!
path: /en/dotNet | #
I've spent some time on NUnit tests for the stuff I do at work and felt I really should write an <nunit> task for Ant so I don't have to shell out to a different build tool or use <exec>. Since most of the stuff I needed was already present in my experimental Ant library for .NET development, it wasn't too difficult.
The result is inside http://cvs.apache.org/~bodewig/dotnet/dotnet.jar and the docs are either online or available as an archive.
All those tasks have only been developed and tested under Mono on Linux and MacOS X (1.0.1 highly recommended) or are completely untested - MSBuild (where does a mere mortal get it - would it run on Mono?) and WiX (doesn't work on Mono). Because of this, feedback by a Microsoft framework users would be extremely useful, but any feedback is appreciated, of course.
Update: Steve has successfully tested the library using the Microsoft .NET Framework 1.1.
path: /en/Apache/Ant/dotnet | #
Jeff of the MSBuild team asks what works for you when it comes to debugging a build. There probably are no hard-n-fast rules.
You really need your build system to output enough information to track things down and this requires the exact location of the error together with some contextual information at the very least. When we introduced <import> in Ant we soon learned that you really need the full stack of nested build files listed to understand what went wrong. It's not enough to say the error occurred in line 37 of build file foo/bar/baz.xml, you also need to know which build file imported that file at which line - recursively. The same applies to using the <ant> family of tasks.
It's probably easiest to locate build process failures if you have some kind of continuous integration system in place, it may help to identify the change causing problem - but then again the problem may be a server that's unexpectedly unreachable or just the time of the day.
Are there any more hints? You can tell Jeff since you don't have to register to post comments at his blog ;-)
In the comments Steve mentions that IntelliJ IDEA now supports refactoring of build files, scary.
path: /en/dotNet/msbuild | #
It has been as strange as I expected. Carrying around shelves and washing machines isn't really a way to relax and living between boxes that remind you you need to look into them isn't either. Live is slowly getting back to normal, slowly.
Between all the moving related activities we managed to spend a lot of quality time with the kids. So much they even didn't complain about the lack of TV.
The satellite dish arrived in time to get at least a glimpse of coverage of the Olympic Games and I managed to see the US men basketball team win over Spain (which I didn't expect) and lose against Argentina. I have to agree with Mark Cuban that the main weakness of the US team has been a lack of decent shooters. Stephon Marbury demonstrated this against Spain quite clearly when he started to hit some shots.
We even managed to get our DSL line activated last week and now have to get accustomed to the speed difference after upgrading from a 28.8k modem.
Back from vacation I'm having a hard time to decide which of the mailing lists I dropped last months are important enough to re-subscribe to. I guess Gump problems are going to drive this again.
path: /en/personal/family/vacation | #