Microsoft's new XML based build tool that looks so much like Ant has become one of the hottest topics on the NAnt list, while it gets more or less ignored in Ant land. MSBuild is going to be bundled with the next version of Microsoft's Visual Studio and will be the default build mechanism for .NET projects then, so it certainly will become a big issue for NAnt.
NAnt's main benefit is and will be that it is Open Source and that it works well with Mono (at least I hope it will, I may need it ;-).
Actually, I'm more interested in what is different between Ant and MSBuild than how MSBuild is going to affect (N)Ant. What have they decided to do in a different way and why? Maybe they have some good ideas that we can improve upon.
John Lam posts a short list of observation he's made while playing with an early access version of MSBuild, he also attaches a sample build file.
I don't grasp the "inter target dependency engine" part, I'll wait until I can find some official docs. This sounds interesting, if I understand correctly what it means. The Item concept sounds like a step into the direction of Ken Arnold's "Ant needs pipes", something we should look into very seriously IMHO.
The other points seem minor, but I'll probably always prefer <csc> over <Task Name="csc"> (and I'd probably never get used to upper-case element and attribute names).
John promises to write an in-depth analysis of MSBuild soon, I'll be reading it.
Bob Arnson posted a pointer to some official information about MSBuild, search for TLS347. I've already picked up the presentation and the source zips but won't find time to actually look into it before the weekend.
Update
Here is what I found:
path: /en/dotNet/msbuild | #
As Fink would install an XEmacs version from the beta branch, using the latest beta release seemed like a good start (21.5.15). "./configure --with-mule" told me that I didn't have libpng and that it was highly recommended to install it.
libpng 1.2.5 worked more or less out-of-the-box, I only had to add a -dynamiclib option to LDFLAGS in makefile.macosx. I also had to manually create a symlink from libpng.3.1.0.2.dylib to libpng.dylib to make -lpng work
OK, rerun configure for XEmacs and it finds the new library. Run make and wait 25 minutes. temacs has been compiled and links successfully, the emacs lisp files get compiled just fine, xemacs gets dumped and recompiles the lisp files, everything looks good until "ellcc" fails to create eldap.ell because of a bunch of undefined symbols.
After a lot of playing around I found that changing ELLCC_DLL_LDFLAGS from "-shared" (which isn't supported on MacOS X anyway) to "-flat_namespace -undefined suppress" in lib-src/ellcc.h created a working xemacs (at least at first glance). Unfortunately I haven't found any way to tell configure to create it, but there is an environment variable ELLDLLFLAGS that is supposed to override the setting.
So what I do now is
> ./configure --with-mule > export ELLDLLFLAGS="-flat_namespace -undefined suppress" > makeand it seems to work. The fonts are the ugliest things I've ever used, but that can be solved later.
path: /en/Mac/XEmacs | #
Bootstrapping Fink went smoothly, but took more than four hours on my 600 MHz G3 iBook that was busy rsyncing some stuff into my home dir.
That machine is too slow to compile everything myself, so I want to rely on binary packages. I guess I should have read this post before starting dselect. After fiddling with the package list locations I got dselect into a strange state where it insisted on uninstalling system-x11, claimed darwin was not installed and a whole bunch of other strange errors.
So time for Plan B. Uninstall Fink and wait for a 10.3 binary release for not so critical stuff (SDL, dia, various things I rarely use), install the most important software manually. The single most important piece of software to me is XEmacs, so I tried to compile it myself - and it fails in the linking stage because of undefined symbols.
The same happens for ifile that I use as a Bayesian Spam Filter. The "./configure; make" sequence worked fine on Jaguar so I guess it must be a gcc 3 thing that can be sorted out by using the correct linker arguments. I wish this page wasn't empty right now.
On the success side, the binary nethack distribution from nethack.org worked like a charm and as Terminal.app now seems to be usable with xterm-color terminal settings, colors have come back to the game for me (it's better to know the color of those "D"s when you meet them). It even accepted my old save file.
... in the J2EE Development package, along with XDoclet, JBoss and a couple of other useful things. This may be old news, but at least I wasn't aware of it.
As soon as Apple releases a JDK 1.4.2, they'll have to upgrade to Ant 1.5.4 to keep <javah> alive (or better upgrade to 1.6).
path: /en/Apache/Ant | #
While I'm writing this, my iBook right next to me is running through the Panther installation.
I've decided to do a clean install followed by a clean Fink install to get rid of some cruft that has piled up over the past months. I may even try to compile XEmacs myself instead of using Fink as the Fink version has become outdated quite a bit.
Hmm, I wonder why 160 MB of "Asian fonts" get selected by default while the 5 MB "fonts for other languages" are not.
It's nice to see that you can elect to not install Internet Explorer at all.
The new NBA season has started last night.
I must admit that I really like Dirk Nowitzki's playing style, not because he's German, but probably because I am German and Dirk certainly gets more TV coverage than any other player here.
TV coverage in Germany has become worse over the past few years. While I was able to watch a couple of games live in free TV even through regular season just a few years ago, now even the finals are only covered on Pay-TV here - or with a few days delay. But still I'm looking forward to this season.
Last night's results indicate that the new Mavericks will need a little more time to learn how to play together while the veterans playing for the new Lakers simply know how to do so.
path: /en/basketball | #
Yesterday I had to travel to "the big customer". This involves about four to five hours sitting in trains and at train stations each way plus waiting time between meeting and my train back home (yesterday this summed up to a fourteen hour day for a three hour meeting).
I was lucky to pick seats with a desk and power supply for the longest part of the journey, so I had enough power for my notebook all the way. After some light Java hacking on the way to the meeting, I decided it was time for some entertainment on my way back, so I started nethack with a new random character.
Even though different GUI front ends are available - even for the iBook - I prefer to run nethack in tty mode. So soon enough my screen contained an xterm that looked like this
The priest of Mitra intones: "Pilgrim, you enter a sacred place!"--More--
------
|.....########## --------------------------------
|....| # #......................%........|
|..<..# ##`#|.------|--------------..-----.|
|....|# ##|.|....|..|...|....|.[-..-...|.|
|....|# ##..|....|..|...|....|..|..|...|.|
|....|# #|.---|----|...||------|..|...|.|
------# #|......|..|...|.|..|%%|.-----|..#### -------
# #..----.|..|-|--.|.)|%%|.|..[.|.|#`######-..^..|
# #%#|.|..-.-|--..{..-)-|..|.|..@.|.|# ### |.....|
) # |.|..|.............-+--.@..j.|.|#` #####...>..|
### ### |.|----|--.----|--......|....|.|# ###|.....|
#------ # |.|((|...|.-..|.%|--|--------|.|# #+.....|
#|....-#### |.|((|(((|.|..|.%| ...|#.|...-.| |.....|
#.....| # |.|..|(((|.---|[%|....|..|.!%|.| -------
|.....## |.-|------..{.---------|------.|
------ |..............................|
--------------------------------
Bodewig the Bandit St:18/02 Dx:16 Co:18 In:7 Wi:8 Ch:6 Neutral
Dlvl:7 $:633 HP:99(109) Pw:25(25) AC:-6 Xp:9/2656 Burdened
That's me entering the minestown temple.
It is not the first time that I had people watching with a very puzzled look in their face while playing nethack. My wife by now knows that "me" is that little "@" walking around, that my pet is the small "f" (I prefer cats over dogs) - and that the rest of the game couldn't be of any interest to her.
This time it hasn't been any different, just that yesterday marks the first time that a complete stranger asked me to explain what was going on. I could have told him I was running a network monitor, but we know how that would end.
It was funny to explain, in particular as he really seemed interested and kept asking question. I ended up playing a lot slower and more careful than usual (which could explain why my Barbarian hasn't died yet) and enjoyed the conversation at the same time. It was one of my most pleasant train travels so far.
path: /en/games/nethack | #
I had to scratch ice from my car's windows for the first time this season. We are even expecting snow today.
When did we have 20 degree for the last time? Less than three weeks ago IIRC.
path: /en/unsorted | #
Florian has lost his second tooth yesterday, Ant 1.6 had its second beta last Friday.
path: /en/personal/family | #
There is a new - not yet official - set of pages in Apache's Wiki that try to explain the most important new features in a broader way.
If you give the beta releases a try and find anything that isn't documented properly (or doesn't work as expected), don't hesitate to change the corresponding page.
path: /en/Apache/Ant | #
Our son Florian is a first grader (started with school just four weeks ago, interesting times ahead!) and we've now been introduced to the way he's supposed to learn reading - by writing.
What sounded silly (at least to me) actually seems to work quite well. He has this big poster hanging at the door of his room with the alphabet and a picture of something that starts with the corresponding letter. If he wants to write a word (and strangely he wants to do that very often), you can see him collect the sounds that make up the word letter by letter. He doesn't need the poster too often anymore.
Of course what he writes is not correct, and I bet it is harder to do right in German with our many Diphthong sounds like "au" that sounds like the "ou" in our or "ie" which is just a long version of "i". But he's getting pretty close and improving fast. Funnily he can currently write better than he can read, sometimes he has a really hard time to read what he's just written.
I wonder how this inversion that seems to be there could be used in different areas as well. Seems that some of the agile development processes follow a similar pattern.
- You don't start with the big picture (the whole word), you assemble your application requirement by requirement (you write the word letter by letter).
- You assert the correctness of those small steps with unit tests (compare the sound of the letter with a known sound).
- Sometimes the application works even though you still don't grok the problem domain (you write better than you read).
- The result may not be correct at the first time, but you have acceptance tests (your parents and teachers?) that steer you into the right direction.
So all my son is does is eXtreme Writing. Interesting.
path: /en/ramblings | #
Steve talks about the UK enacting the EU copyright policy and calls it the EU version of DMCA.
Well, from his description and the recent laws being discussed in Germany it's kind of obvious that different countries of the EU have very different views of what would be required to follow the EU.
Let's use music CDs as an example. Under German law you have the right to take private copies of a CD you've purchased, you may even take copies for your friends (as long as you do so for a limited number of friends and don't charge money for it).
This remains true even with the new copyright laws in Germany, with some silly changes. You still are allowed to make copies if you can. But it is illegal to defeat a copy protection mechanism, or to distribute software that can disable copy protection - I don't know whether pressing the Shift key is now illegal as well. You may even copy MP3s you've obtained, unless it is from an "obviously illegal" source.
How copy protected CDs and the right to obtain private copies can get together is still in some kind of flux. Things like shipping three CDs instead of one per box are being discussed.
Oh, if you have any legal problems getting your Tour de France coverage next year, Steve, we can certainly arrange something for the German coverage. You won't understand the famous commenters Emig and Watterot, but I wouldn't say you'd miss much either. I expect next year's media coverage in Germany to even exceed this year's hype now that Jan Ullrich has re-joined Team Telekom (will be T-Mobile next year).
path: /en/unsorted | #
If you want to include a common snippet of build file code in Ant, the canonical answer has been to use entity includes. Consequently this is what you find in Ant's FAQ.
Ant 1.6 adds an import tasks that can be used to include such snippets as well. The task can do more than that, but I only want to cover the include mechanism right now.
So what is the difference?
-
Files suitable for <import> must be legal Ant build files, i.e. they have to be well-formed XML documents and use <project> as their root element.
This means that - unlike the snippets you use in entity includes - the included file can easily be edited and (partly) validated with XML aware tools.
- You can use Ant properties in the file name for the piece to include in <import>. With entity includes you've been limited to static file names and hard-coded (relative) paths.
- You don't have to worry about the way your XML parser resolves relative file names.
- Entity includes require a DOCTYPE declaration and thus have their roots in DTD systems. If you have an XML-Schema or Relax-NG gramar for Ant build files, the two are hard to combine.
- You must not use <import> inside a <target> (or <sequential>), while there is no such limitation for entity includes.
path: /en/Apache/Ant | #
Go and take a look at the new stuff - and please give the beta a try to help us iron out bugs before we make the final release.
path: /en/Apache/Ant | #
This is another new kid on the Ant 1.6 block. <presetdef> will let you define your own default values for attributes and even for nested elements.
If you've always thought that <ant>'s inheritall attribute should be false by default, you are not only correct (but there is this backwards compatibility issue) but can now use
<presetdef name="better-ant">
<ant inheritall="false"/>
</presetdef>
and then use <better-ant> the same way you used <ant>. You can even set inheritall to true in your better-ant invocation if you want to.
The example from the manual uses <javac>:
<presetdef name="my.javac">
<javac debug="${debug}" deprecation="${deprecation}">
<src path="${gen.dir}"/>
</javac>
</presetdef>
this shows two things:
- the debug and deprecation attributes take their default values from properties. If you use <my.javac> instead of <javac> throughout your build file, you can be sure that running ant -Ddebug=on will apply to all compilation tasks. No need to remember to put the customization into each task.
- The path ${gen.dir} will be added to <javac>s source path automagically.
While you may be able to override attributes set via <presetdef> when you use the task, you can not suppress child elements.
path: /en/Apache/Ant | #
I just received one of the spam mails causing trouble for the broken mail server I've talked about before. "Copy DVD's to a standard CD - without a DVD Burner" - I couldn't care less.
So I gave piston a short try and it (well, JavaMail underneath it) managed to pick up all mails without dieing. Looks as if it would be worth to figure out how it is supposed to work (and maybe contribute some docs after that 8-).
path: /en/unsorted | #
I've been asked to explain what I meant with "Macrodef - hopefully this is going to remove a bunch of <antcall> "abuses" present in Ant 1.5 build files."
Let me pick an example from Ant's own build file. Starting with Ant 1.6 optional.jar has been split into a bunch of smaller jars, one per external library required by the classes in it. I.e we now have ant-trax.jar for the classes that require TraX and ant-xalan1.jar for those that need Xalan-J 1.x and so on.
In Ant's build file this lead to
<jar destfile="${build.lib}/${optional.jars.prefix}-trax.jar"
basedir="${build.classes}"
manifest="${manifest.tmp}">
<selector refid="needs.trax"/>
</jar>
<jar destfile="${build.lib}/${optional.jars.prefix}-xalan1.jar"
basedir="${build.classes}"
manifest="${manifest.tmp}">
<selector refid="needs.xalan1"/>
</jar>
...
and a lot more of them. 25 <jar> tasks that were identical in structure.
The Ant 1.5 way of avoiding duplication like this would have been
<antcall target="optional-jar">
<param name="dep" value="trax"/>
<antcall/>
<antcall target="optional-jar">
<param name="dep" value="xalan1"/>
<antcall/>
...
<target name="optional-jar">
<jar destfile="${build.lib}/${optional.jars.prefix}-${dep}.jar"
basedir="${build.classes}"
manifest="${manifest.tmp}">
<selector refid="needs.${dep}"/>
</jar>
</target>
leading to 25 <antcall>s in a row. This isn't more readable than the original version using separate jar tasks and in fact is a lot slower as <antcall> is a computational heavy operation in Ant. That's why we went back to the separate <jar>s after a few weeks.
And now the Ant 1.6 way:
<macrodef name="optional-jar">
<attribute name="dep"/>
<sequential>
<jar destfile="${build.lib}/${optional.jars.prefix}-${dep}.jar"
basedir="${build.classes}"
manifest="${manifest.tmp}">
<selector refid="needs.${dep}"/>
</jar>
</sequential>
</macrodef>
<optional-jar dep="trax"/>
<optional-jar dep="xalan1"/>
...
We have now defined a macro and use that macro repeatedly within the same build file execution. And on top of it, it's even more readable than the <antcall> approach.
Most if not all uses of <antcall> I've seen in build files can be replaced by <macrodef> (or by understanding <target>'s depends attribute). I'm not really sure that there is any use-case for <antcall> anymore.
path: /en/Apache/Ant | #
Dale Anson, founder of Antelope, has become a committer at the Ant-Contrib project.
Antelope and Ant-Contrib both host a bunch of similar tasks (if, trycatch, switch) and Dale plans to merge features from Antelope's versions with the existing Ant-Contrib tasks as well as bringing over some of Antelope's tasks.
path: /en/oss/antcontrib | #
I managed to compile Mono 0.28 from sources on my Linux box and on my iBook. 0.26 wouldn't compile on my Mac as it failed to find a file necessary for the JIT (there is no working JIT for the PPC architecture, yet).
The first mini-test I do with a Mono installation is running Ant's tests. The tests for <csc> pass, which doesn't mean much more than that Mono's C# compiler is compatible enough to Microsoft's to at least pass the simplistic tests.
One small tweak to Ant's tests was necessary: I had to force Ant to use mint instead of mono as the runtime (i.e. no JIT) for my Mac as all the tests would have failed otherwise.
path: /en/dotNet/mono | #
All my mail is collected on a single box via fetchmail. I've been doing so for years now and it's always been fine that way.
Some months ago some spammers started to put a single dot on a line by itself somewhere close to the end of their mails. An RFC compliant POP3 server is supposed to escape that. One mail-server that receives mails for me unfortunately isn't compliant to that and I don't have control over it.
When fetchmail encounters such a message, it will die because of a protocol error after it has delivered the mail to my local MTA but before deleting it from the POP3 server. The result is that I get duplicates of this spam mail over and over again until I manually delete the problematic mail.
I've upgraded my (originally RPM installed) fetchmail to the latest version, RTFMed and STFWed to no avail - there doesn't seem to be a way to make fetchmail recover from a problem like this.
Currently I'm half-way torn between brushing up my rusty C knowledge in order to dive into fetchmail's code and simply looking for an alternative. Conor started piston a while ago, maybe I should give it a try before anything else.
path: /en/unsorted | #
Antville, the software behind blogger.de, doesn't support trackbacks yet. As it is open-source, I'm sure it is going to be added sooner or later.
In the meantime, I wanted to be able to send trackbacks from posts I write and a found a solution based on Sam Ruby's autoping script.
I store all my blog entries in files that seem to be roughly similar to blosxom's style (i.e. title in the first line, body follows after that) on my machine in addition to posting it to blogger.de, so adapting Sam's script was straight forward. For anybody who wants to try the same, these are the steps I had to take:
- use
python2as executable as I'm running RedHat 7.x on my machine and/usr/bin/pythonis a 1.x version that doesn't know thesplitlinesmethod. - Change the url discovery algorithm in
excerpt- I've decided to put the "story-number" into the last line of my file. - change the excerpt-algorithm (I simply limit the excerpt to the first 250 characters of the body)
- Finally, and most easy, change the
blog_nameattribute.
path: /en/personal/blogging | #
Germany is one of the few European countries where you don't have to pay (directly) if you want to drive on a highway. At least for trucks this was supposed to change at the beginning of September.
Being the high-tech country that Germany is, we've chosen to show the world how to charge the money the right way. No stopping before you drive onto the highway, no, things have to work automatically.
A consortium named Toll-Collect has been charged with implementing the system. Basically you have three choices, register via internet, register at one of the Toll-Collect stations in gas stations and other places or - and this is the really advanced part - use an on-board unit OBU.
This OBU is a little box inside your truck that counts the miles (errm, kilometers) you drive on a highway. It contains a cell-phone and knows your geographical position as well as where the highways are. Everything is automatic. Great!
Well, not so great. There have been massive technical and software-side problems with these boxes. They charge even if you are not on a highway but only close by. They count backwards if your side of the highway is under construction and traffic is redirected via the other side. Incompatibilities between systems. Random communication errors ...
Because of these problems the start has been delayed until November and it seems as if it will have to be delayed again.
It looks like a simple case of one of the many software projects that run out of schedule (and out of budget, I bet). Toll-Collect has been funded by some of Germany's heavyweights of the software and electronic industry (Daimler-Chrysler and Deutsche Telekom) or those heavyweights are working on the hardware (Siemens and Grundig build the OBUs). This shows that big companies have the same problem, even if they are able to throw more people into the project - this may be new to some.
Strangely the requirements have been rather clear from the start and haven't changed. This usually is the reason for failing projects, but not this time.
The downside for German citizens is that a separate contract between the government and Toll-Collect seems to say that those failures will not make Toll-Collect pay back anything of the lost money for the first few months and puts a cap on the damages to pay for a full year.
path: /en/Germany/maut | #
Yesterday Antoine has released the first beta of Apache Ant 1.6.
What can you expect apart from a ton of fixed and another ton of new bugs?
My personal (incomplete, I'm sure) list of important new features in no particular order:
- You can now add custom conditions to <condition> or filterreaders or selectors by using <typedef> and either implementing a particular interface or using one of the supplied adapter classes. See the beta manual to get an initial idea.
- XML namespace support. That on itself isn't too exciting, but together with ...
- Antlib ... things get more interesting. At first glance <antlib> is nothing more than a unified <taskdef> and <typedef> - but you can bind it to a particular namespace and suddenly get scoping of names and more readable build files.
- Presetdef - you don't like the default value of "off" for <javac>'s debug attribute? Just define a javac2 task with the attribute set to true. Presetdef is your way to define default configurations of existing tasks.
- Macrodef - hopefully this is going to remove a bunch of <antcall> "abuses" present in Ant 1.5 build files. Create a new task from a set of tasks as a macro.
- Import - import another build file and even override targets of that other build file using a replacement of your own.
- All tasks are equal - they may now all live outside of <target>.
- SSH support via <sshexec> and <scp>.
- Scriptdef - define new tasks using your favorite scripting language.
- subant - invoke the same target in a whole bunch of build files.
path: /en/Apache/Ant | #
Ara (via Ted) talks about the failures that have been made in XDoclet's community management. Or at least the failures as he perceives them. Some of what he says resonates with my experience in Ant, some doesn't.
First he talks about letting people (committers in this case) in too quickly as they'd be leaving behind a bunch of unmaintained code.
What I've learned is that you shouldn't let people in a popular project that easily. Someone comes, contributes something and goes, and there's no one to maintain it, and the guy apparently is happy to see his name among the team members list.
Like XDoclet, Ant has accepted each and every contribution for a while and simply faces the exact same problems of unmaintained and unmaintainable (unless you have an installation of application server X or SCM tool Y around) code.
Unlike XDoclet, we haven't made those contributors committers automatically. So no, Ara, it is the code you and we have let in that's causing the problems, not the people. Still I agree with Ara. You have to be sure that people are going to persist when you make them committers.
But let's face it, people move on - maybe after years - or lose access to server X. Even if you pick your committers very carefully, you may end up with unmaintained code over time. Unless you have a team that lives collective code ownership where a reasonably large part of your code base is more than just a one-man-show.
In "meritocratic" development communities like Apache's one-man-shows tend to happen less often from my experience. Like I said, Ant has its unmaintained areas, but every now and then a new contributor steps up from the larger user base and starts to fix things. Those new contributors have to get their code reviewed by an existing committer, you build up a trust relation and at the same time make at least two people closely familiar with a certain part of the code.
It is not enough to choose your committers carefully.
Ara's conclusion is
So accept a piece of code only if the contributor remain the proud owner of it.and with this I couldn't agree less. Accept it only if the community is willing and able to take ownership of it.
I'm not sure what has given me the final push to try blogging myself, maybe it has been Ara's article about how and why XDoclet's community management has been a failure or the release of Ant 1.6's first beta or ...
I'm not even sure whether this is going to last or whether I'll stop it sooner or later.
Anyway, I'm here and we'll see where this is going to lead up to.
path: /en/personal/blogging | #