My "msbuild" search feed today made me discover Waaargh.NET by Stéphane Tombeur that holds some interesting posts. In particular I liked the Creating custom MSBuild tasks and CruiseControl.NET and MSBuild posts.
The first one explains how to write an MSBuild task by converting a NAnt task - which turns out to be mostly a matter of six simple steps. I assume that it would get more complex for more elaborated tasks, but this really looks rather straight forward.
The second one comes with an MSBuilder based on NAntBuilder that can be used to drop into CruiseControl.NET and you are done. Nice work, I hope it finds its way into cc.net.
path: /en/dotNet/msbuild | #
As promised I checked out JUnit 4 from CVS. It compiled just fine without any additional dependency. Only
<property name="build.compiler" value="classic" />looks a little strange in a "Java 5 or higher" project's build file. Luckily Ant is smart enough to upgrade to modern automatically.
Then I went ahead, checked out a fresh copy of Ant and compiled it against JUnit 4. No problems. To be sure that no problems are hidden anywhere, I ran Ant's test. I even tried some cross-checks.
- Ant compiled against JUnit 3.8.1, tests compiled against 3.8.1, tests run against 4.0rc1 (took 10 minutes 31 seconds).
- Ant compiled against JUnit 3.8.1, tests compiled against 4.0rc1, tests run against 3.8.1 (took 10 minutes 10 seconds).
- Ant compiled against JUnit 4.0rc1, tests compiled against 3.8.1, tests run against 3.8.1 (took 10 minutes 18 seconds).
- Ant compiled against JUnit 3.8.1, tests compiled against 4.0rc1, tests run against 4.0rc1 (took 11 minutes 24 seconds).
- Ant compiled against JUnit 4.0rc1, tests compiled against 3.8.1, tests run against 4.0rc1 (took 10 minutes 57 seconds).
- Ant compiled against JUnit 4.0rc1, tests compiled against 4.0rc1, tests run against 3.8.1 (took 10 minutes 19 seconds).
- Ant compiled against JUnit 4.0rc1, tests compiled against 4.0rc1, tests run against 4.0rc1 (took 11 minutes 14 seconds).
As for the timing information, I'm not sure how significant they are. My machine may have been swapping or running under load of other processes during the tests. All tests were run in the same VM as Ant using Sun's JDK 1.5.0_003 for Linux. Yes, it looks as if using JUnit 4 was a bit slower, but I couldn't explain why since most of the time is taken up by running Ant (inside of the tests) or for Ant's own test-runner.
path: /en/Apache/Ant | #
There's been a lot of rumor about JUnit 4 lately and thankfully Kent Beck provided some information on the JUnit list. He also points to a short introduction by Gunjan Doshi.
With this to me it looks as if it won't affect the Ant <junit> task at all - if you plan for it.
The first thing you have to be aware of is that JUnit 4 requires Java 5 at runtime. So you either need to run Ant on a Java 5 VM if you want to use JUnit 4, or use fork="true" and specify a Java 5 VM in the executable attribute of the <junit> task.
And then you will need to provide a suite() method in
all your test classes and wrap your class in a
JUnit4TestAdapter, otherwise Ant's testrunner won't see
any tests in your classes. With this you should be able to use Ant
the same way you always did.
Right now this is pure theory since I haven't actually tried anything yet. During the next days I hope to free up some time to check out the JUnit 4 branch from CVS and play with it. If I should find any problems, I'll make some noise.
Longer term Ant may provide an additional testrunner that is used if Ant detects JUnit 4 on the <classpath> specified by the user, but this should not be required to use the task.
For Ant's own unit tests I'm totally with Steve. Since a switch would require our tests to be Java 5 only it will take a long time before we'll leave JUnit 3.8.1 behind.
path: /en/Apache/Ant | #
Nothing too fancy, but something I didn't find in the plugin registry: The plugin creates a short list of all subcategories of the current category with a count of articles within them. It doesn't create a full tree but still provides some useful insight into the hierarchy of the articles.
It's harder to explain than to show. See the "Sub-Topics" section on the left hand side. Now, if you go to en/Apache/ you'll see all subcategories I've created below Apache together with an article count. It does no show "Ant/dotnet" since this would be a subcategory of "Ant".
The code is here.
path: /en/oss/blosxom | #
If you are reading this blog you are likely to be interested in Ant or Gump.
If so, take a look at the ApacheCon Europe 2005 Schedule with talks about Ant by Steve or Gump by Leo - they'll be worth a visit.
path: /en/Apache/ApacheCon | #
Phew, took quite some time and effort, but now all old are here and archived, at the same time they went offline in the old blog.
Sorry for all the noise.
path: /en/personal/hosting | #
There is an interesting thread going on at user@ant. Somebody asks about using Ant outside of the pure Java realm and not only gets the usual "C for JNI" type of answers but also things like a JavaScript library.
At work I drive parts of an ASP.NET webservices project using the built-in <wsdl2dotnet> and <csc> tasks as well as my experimental <nunit> (all on Mono and MacOS X, BTW) and Axis's <wsdl2java> tasks. Steve once suggested to use <junit> to drive Axis-backed interop tests, but I still need to go there.
path: /en/Apache/Ant | #
Well, choosing the domain name turned out to be the hardest part of all. All bodewig.FOO domains have been taken. Even if bodewig.de looks as if it had been designed be me, it isn't. Oh, and it has been looking like it currently does for five years or more now.
I wanted a family-domain, maybe one of our children wants to start a blog one day? At least they'll need email addresses.
The next attempt was trying anagrams - a typical geek-reflex. A few lines of Perl later I realized that I have "I Web God" in my last name, oh that irony. Nothing that at least sounded well.
In the end my wife suggested to play with the first letters of our first names, and that it is - Sarah, Manuela, Florian and Stefan.
Boring, I know.
path: /en/personal/hosting | #
My blog has moved from http://stefanbodewig.blogger.de/ to http://stefan.samaflost.de/blog, please update your links.
I've gone with blosxom and a rather conservative choice of plugins, I may switch to static rendering (at least partial) later. So far I haven't enabled search yet since I really want to use Lucene but didn't manage to set up the plugin within five minutes.
Migration of old articles is mostly manual, as I feared it was. I've moved all articles of this year and will go backwards gradually. The old articles will probably pop up in the feeds again, please bear with me.
Speaking of feeds, the new blog has both Atom and RSS feeds, and in the typical blosxom manner, feeds on each and every level. Since I may start blogging in German more than I did before, you most probably want to subscribe to my English-language-only feed (either http://stefan.samaflost.de/blog/en/index.rss or http://stefan.samaflost.de/blog/en/index.atom).
Right now trackbacks are (supposed to be) enabled, comments are not.
path: /en/personal/blogging | #