John Lam has a nice doc about MSBuild, Microsoft's XML based build system of the next Visual Studio version. This issue has far more information than has publicly been available yet.
You may need a Windows machine running Acrobat Reader to read it as both xpdf on Linux and preview on MacOS X seem to be lacking the fonts necessary for it.
path: /en/dotNet/msbuild | #
Man landing on Mars or Toll-Collect delivering a working Maut system for German Autobahns? - I laughed out loud when I heard this on the radio this morning (while standing in the traffic jam caused by two centimeters of snow).
The truck Maut system was supposed to start in November 2003 but failed for various technical reasons, both hardware and software problems. The new plan of the contractor promises a stripped-down version of the system for January 2005 and the full system for January 2006. We'll see.
Currently the contract between the German government and Toll-Collect makes Toll-Collect pay 7.5 million Euro per month as long as the system isn't in place - IIRC this will go up to 15 million in April. Contrast this with the expected 180 million Euro the Maut was supposed to deliver per month.
The biggest mistake of Toll-Collect has been that they didn't admit their technical problems in time IMHO. It wasn't until September or October 2003 that they admitted that the system wouldn't be ready by November.
As Nicolai Josuttis pointed out during last week's OOP 2004, Toll-Collect is hiring people for the legal department, they probably know why. To be fair, they are also looking for some developers, engineers or project managers.
path: /en/Germany/maut | #
I've just merged the changes I've made to Ant's CVS HEAD to the 1.6 branch so that Ant 1.6.1 will contain some initial support for Java 1.5. It will basically be treated as if it was Java 1.4 with some minor additions to the <javac> task.
The longer term plan is to support JSR 199 compatible compilers - as J2SDK 1.5 promises to deliver - in Ant's
path: /en/Apache/Ant | #
Similar to Brian I'm writing this so I have a place I can link to when people assume I'd be sending virus mails to them. Go and read Brian's article for the longer version of
Almost all recent worms and viruses fake the from address. If you receive a worm sent from any of my addresses, you can be absolutely sure that I haven't sent it.
Due to server-side filtering (big kudos to the people responsible for the apache.org mail infrastructure) I'm getting far less Mydoom worms now. I still keep getting bounces, which certainly is annoying. Being the moderator for a couple of mailing lists doesn't help either.
I've noticed that those viruses are causing problems to statistical spam detectors, mails without a virus get a higher probability of being ham now. So far I've been filtering out all mails with "bad" attachments (I don't have any use for .exe or .scr files) before ifile sees them, but I cannot remove all "zip" attachments.
path: /en/malware/viruses | #
I received about 50 copies of that new virus during the past twelve hours. What's worse than that are more than 200 bounce messages, as usual about half of them containing the virus itself.
For the record, I'm not the sender of those virus mails, I don't even run an operating system it could affect.
Dear virus detection software writers, please get a clue. The forged sender of such a virus message is most probably not yet affected by the virus. In sending "back" that thing, you help spreading it.
Now back to refining those procmail recipes so that I don't have to see the garbage at all.
path: /en/malware/viruses | #
Seems like Jon Tirsen is the one I should ask when I want to know more about the complex build systems, Martin Fowler has been talking about.
I found Jon's blog entry via an unrelated story in Leo Simons' blog via Planet Apache.
path: /en/Apache/Ant | #
Conor talks about the impact NAnt's license choice has on what they can and can not do with Clover.NET.
Conor, you may be pleased to know that the community is aware of this and that they have been considering alternatives.
See here for
We're planning on moving to an Apache or BSD style license, so that should make you feel a little more comfortable :-)and the whole thread named "Licensing" starting here.
path: /en/oss/NAnt | #
I didn't have as much fun with airlines and airports as Ken used to have with his last trip to the Linuxtag, only baggage being delivered to the wrong belt and a train that didn't go where it was supposed to go. But finally I made it, traveling from the airport to the hotel took longer than traveling from home to the Munich airport.
The hotel has a T-Mobile WLAN-Hotspot at no cost - at least during some initial period of time, sweet.
path: /en/personal/traveling | #
A discussion on the JPackage list reminded me of a new Ant 1.6 feature that is documented but easy to miss.
With the new launcher code, the directory .ant/lib in your home directory is treated just the same way as $ANT_HOME/lib by Ant. This means that all jars puts into that directory will be available to all Ant tasks or can contain Ant libraries. No need to fiddle with the Ant installation in a multi-user environment.
path: /en/Apache/Ant | #
Miguel de Icaza says
The MacOS X port is working, but it needs testers on MacOS to try the latest editions of the Boehm GC do build fixes and so on.
I'll have to try it out since it still seems very likely that .NET will become a more important part of my day job and I really don't want to switch to an Intel based notebook.
Last night's Mono snapshot fails in configure with a syntax error
checking for pkg-config... /sw/bin/pkg-config ./configure: line 20032: syntax error near unexpected token `BASE_DEPENDENCIES,' ./configure: line 20032: `PKG_CHECK_MODULES(BASE_DEPENDENCIES, glib-2.0 >= $GLIB_REQUIRED_VERSION)'that I don't have the time to diagnose right now. My previous attempts with released versions failed to produce a usable binary so far.
path: /en/dotNet/mono | #
Great essay, most of it is still true - 124 years later (via Stefan Tilkov).
After reading it you'll know why my sentences are overly long and full of parentheses.
has been released a while ago. It is an alpha release, even though the files you get via the download page are named j2sdk-1_5_0-beta-*.
It is currently provided without documentation.which makes it kind of useless for the stuff I intended to do - namely making sure that Ant works well with it and maybe make it use some of the new features.
The first thing I've noticed is a warning
javac: source release 1.4 requires target release 1.4when trying to bootstrap Ant.
Ant's build file does not set the -source argument at all, so it is supposed to default to 1.3 (in JDK 1.4 it does) - apparently JDK 1.5's javac defaults to -source 1.4 as it also compiles to -target 1.4 even though Ant explicitly requests -target 1.1. Without docs I can only assume that this is a bug in the JDK and won't change Ant at this point - in particular since the warning goes away when I explicitly set -source 1.3 but -target 1.1 still gets ignored.
Ant's own test suite passes, Ant recognizes 1.5 and treats it as JDK 1.4, not much more we can do for now.
Comparing the command line help output it seems javac has now a built-in lint, that looks interesting and should be supported by Ant directly:
-Xlint Enable recommended warnings
-Xlint:{all,deprecation,unchecked,switchcheck,path,serial,\
finally,-deprecation,-unchecked,-switchcheck,-path,\
-serial,-finally}Enable or disable specific warnings
I'll be attending OOP 2004 in Munich starting in a bit more than a week.
path: /en/personal/traveling | #
Peter Williams announced MBuild on the Mono list (via Miguel de Icaza).
I had a very quick look at its documentation and it seems to hold some nice concepts.
The dependency mechanism is closer to make than to Ant and friends, you state a relation between targets and sources via rules. Rules look and behave like functions and are implemented as .NET assemblies, which should make MBuild reasonably portable and easy to extend.
Targets (not necessarily files) are typed in MBuild which enables rules to infer some things about them, for example
program = CCompile [parser.c foo.c libmylib.so]would know that the last part was a library and add -lmylib on the command line (and do the right thing on Windows AFAIU). It even goes so far to defer the rules based on types like invoking the C# compiler on
parser.exe = [parser.cs]
This looks interesting. Maybe there is some inspiration to be found for Ant.
Interesting blogs on build systems these days.
I found Bill's list of what's wrong with Ant via Bruce Eckel's Feedback Wiki.
Most of Bill's points seem to be addressed with 1.6.
"Ant encourages duplication across build files."
As he already notes, <import> is your friend. And as it even allows you to override targets from the imported build file, you get quite a powerful reuse system.
"Ant isn't recursive."
<subant> is what he's been looking for. This also addresses his next point that "Ant's enforcing of downward dependencies".
"Ant doesn't understand dependencies."
True. He's talking about dependencies between projects.
When Dominique first submitted <subant>, it contained a mechanism to declare project dependencies and have subant sort out the build order. We stripped that functionality but I'm seriously planning to bring it back with a pluggable dependency analyzer - still, it isn't there yet and won't be for quite some time.
path: /en/Apache/Ant | #
Martin Fowler talks about make and Ant and how he thinks they are not appropriate for larger scale build systems:
Simple builds are easy to express as a series of tasks and dependencies. For such builds the facilities of ant/make work well. But more complex builds require conditional logic, and that requires more general programming language constructs - and that's where ant/make fall down.
He suggests that using a real programming language (he prefers Ruby) instead. If you really need conditional logic, you better use a real programming language, with that I wholeheartedly agree.
The approach of Ant to this is that you should use Java (or any scripting language supported by BSF) as the language and write a task. Instead of looping over a list of filenames and copy them one by one with a small and simple copy task, Ant has a more powerful task that hides the loop. The same is true for compiling, running JUnit tests and even executing external programs (<apply>).
This approach violates the KISS principle. Ant tasks are complex and sometimes unwieldy or even overtaxed with features. But look where kiss would lead you in this situation
for file in list-of-files
do
cp $file destdir
done
instead of
<copy todir="destdir">
<fileset .../>
</copy>
If all you have is a programming language, things get difficult even for easy things. There certainly are things that are too simple to write a custom task for, but I've never encountered a build that really needed a for loop - I bet that Fowler's "complex" is an order more difficult than mine.
My general feeling is that Ant is on a good middle-ground between making simple things simple and enabling difficult things. It may not the best solution if things are really complicated, even though 1.6.0 will help a lot even then (<macrodef>, <subant> and <import>).
path: /en/Apache/Ant | #
... even if he doesn't seem to like it at all. He explains it in his Web Log.
The main reason against Ant he talks about is that he doesn't like to use XML to describe the build and that it is way too verbose for him. Fair enough.
Like Martin Fowler he is convinced that a real build needs the power of a programming language (Python in his case). Again, my build manager experience isn't much to talk about, so he may be correct. But the example given (by an intern of his) seems strange:
For instance, because a class may be compiled or not based on the presence of a jar, a whole separate target has to be created for any classes that want to use compiler arguments.as conditionally excluding classes from compilation is probably the only conditional logic that is really easy to do with Ant.
They went on and wrote a program that generates Ant build files from a simpler description but stuck with Ant mainly because Ant doesn't seem to be that bad and there was little reason to solve a problem that has already been solved - even if suboptimal according to their findings.
I disagree with quite a bit of what he says but think most of it is fair. Still,
Ant sucks on a number of levels (so much that the original inventor became disgusted with it and went off ...)could use some qualification. My recollection of Ant's past is certainly different from his interpretation.
path: /en/Apache/Ant | #
Ever since I read "Ein Mann in einer fremden Welt", the German translation of Heinlein's "Stranger in a Strange Land", about six years ago I knew I had to read the English version. I already knew the verb "grok" before (so common in software developer's English) and was curious to see what else originated from the book.
I'm through the first seventy something pages now (started reading today) and have already learned that "grokking" has to be written with double-k.
The other notable thing so far is a disclaimer along the lines of "If you've purchased this book without a cover, it is stolen good". I've never seen that in any other book so far.