Ant Tutorials

A while ago I thought about writing a book about Ant. I even had a deal organized and I had started work on it. In the end, the deal fell through. I was actually relieved, since I had begun to feel that the workload might be pretty high. I have enough deadlines in my life as it is from work and family that I don’t need any more.

Now that I am blogging, however, I thought I could release the occasional tutorial on Ant. This way I can write bits and pieces as I have time and interest without the worry of meeting deadlines. Also I can mix up advanced and introductory stuff as I like.

So, I have put up my first tutorial on Ant up. It is a very basic introduction to Ant.

Piston

It’s time for my first code feed. After a bit of googling, I’ve decided to call my little email fetcher "piston". I skipped the whole "j" namespace as it’s worn a little thin for me – sorry Matt. The idea behind the name is that the app is like a piston, drawing email from the POP port, and pushing it to the SMTP port. I hope it doesn’t explode too many in between.

You can download it and try it out or just check out the source. The licence is the same as the current Apache licence with the names changed to protect the innocent.

It’s a little rough at the moment – not much in the way of configuration options, logging to the console, etc. It does the job for me and I will probably clean it a little later. To run the piston, you must create a directory ".piston" in your home directory and create a config file "config.xml" Here’s mine

<config loop="120">
  <smtp/>
  <pop username="user"
       password="password"
       host="pop1"
       smtpname="conor"
       max="100"
       nullMessageId="delete"
       duplicateMessageId="delete"/>
  <pop username="user"
       password="password"
       host="pop2"
       smtpname="conor"
       max="100"
       nullMessageId="delete"
       duplicateMessageId="delete"/>
</config>   

When I used to use Outlook, occasionally it would redownload a whole load of old mail sitting on the server. I think this occurs when there is a server problem and the UID values are rebuilt. When it happens it is a real pain. I set out to avoid that happening by tracking the messageIds of the messages currently on the server and not downloading these if I had already seen them. I discovered that a lot of viruses and spam does not have messageIds so I have an option to delete such messages. I have only seen one "legitimate" email that does not have a messageId (a super-12 footy tipping email). The nice thing is that virus payloads are often quite large and this approach allows me to delete them without downloading them. The tracking of messageIds also allows me to eliminate duplicates arising from cross-posting.

So if you send me an email without a messageId, I won’t read it – sorry.

DISCLAIMER This code is capable of deleting emails from your POP account. You need to satisfy yourself that it is working as you expect.

Good Names

One of the hardest things in software development is coming up with good names. Whether it is the name for a variable, a class or a project, a good name is really important to succinctly convery the role or purpose of the thing being named.

BTW, let me go on record to say that I don’t like the use of so-called "Hungarian" notation. For me names should be pronounceable (Pronounceable is a funny word – it is hardly pronounceable). lpszBlah does not work for me.

The reason I mention this is I am having trouble naming my little Java based alternative to fetchmail. I originally called it popper but there is already a tool by that name. My thoughts of a play on codefeed, "mailfeed", is also already in use. Is this like domain names – everything you can think of is already gone. I’ll have to sleep on it.

I just remembered that I once had to work on a system where the source files were part of a bill of materials and had to have part numbers. The part number was reflected in the file name – e.g. 123456.h. I’d rather have the problem of coming up with good names …

Beta Testing

I’ve just uploaded the first beta for Ant 1.5.3. One thing I’ve noticed as Ant has matured and become the standard build tool for Java projects is that the betas do not get as much testing as you might expect based on the so-called "open-source " effect.

These days most bug reports actually come after we make a full release and not during the beta period. My guess is that most people do not bother to try out the betas but feel comfortable upgrading to a release. It seems it is the release that actually triggers the testing phase. The consequence is that each major release has more point releases. You can clearly see this trend in Ant releases over time.

This behaviour, whilst understandable at the individual level is perhaps counter-productive to the user community as a whole. An interesting conundrum. For my part, I rarely use a build of Ant that is more than a few days old.

If you are an Ant user, test the beta now.

Ant 1.5.3

I’ll be building the beta for Ant 1.5.3 early next week. Hopefully we can get some good beta testing on this release. This will probably be the last JDK 1.1 compatible release of Ant.