HOWTO Create MANIFEST.MF Classpath From Ant

UPDATE It seems this is at least partly outdated, have a look at manifestclasspath.

It is possible to define .jar dependencies in the MANIFEST.MF of the main .jar file, it is just a comma seperated string which looks like this:

In a project I work on, we keep all our dependencies in a lib directory, where we add and remove libraries from time to time, therefore it would be nice if the above text can be generated automatically. Fortunately, this is possible using just Ant. Unfortunately, this is rather cumbersome. (If you want something more powerful and simpler to use, have a look at Rake).

In a nutshell, this is how I did it:

Continue reading “HOWTO Create MANIFEST.MF Classpath From Ant”

How To Introduce a Wiki

On my quest of successfully installing a wiki at my workplace, I came to the conclusion that the biggest problem is a social one. On this quest, I fought with Google and other search engines to present you this list of great links to this topic:

There does not seem to be much information on this topic available, but it is something to start with.

If You Have a Problem, Crash.

In a Java project I currently work on I am responsible for the software architecture. Here is a little anecdote and lesson that I learned:

At first, when problems occured in our application, people just threw an exception. They were too lazy to catch them decently so the application crashed a lot. But this was not so bad, because the developers had to fix the problems, otherwise the application would not run.

After a while I thought “hey, let’s catch exceptions where it makes sense, and use a a logger to get an error message. This surely helps against all these crashes”.

For a while, life was good. The application did not crash that often any more, and most of the println’s got replaced with the logging mechanism. The logging file grew in size, and had a lot of useful error messages and the application did not crash.

This all looked quite good at first. But it turned out to be a very bad decision after all: The time presure on the project was quite high, so the developers never really got around looking at the log messages to fix their problems. New features were introduced, new exceptions thrown, catched, and reported in the log file which then was completely ignored.

The morale of this story? As always, this is a problem with us lazy humans. Developers have to be forced to fix their bugs, so do not try to make an application stable by working around bugs. If you encounter a problem, crash. Throw an exception and never catch it, so that the whole application goes up in flames and leave you just with a thick red stack trace when the dust settles.

Finding eBooks with Google

Google is a very mighty tool. I have played a bit with search keywords to find eBooks, and this is the result:

The search uses these keywords:

Step-by-step, this works like this:

  • intitle:"index of" This tries to limit the search to all pages that have the typical apache directory listing.
  • -inurl:(htm|html|asp) Helps limiting down to real directory indexes, because these do not have the typical .html extention.
  • (pdf|chm|zip|rar) Searches for all pages that contain the text pdf, chm, zip, or rar. These are all file extensions usually used by eBooks.
  • (book|ebook|ebooks|books) Limit search to pages talking about books or something like this.
  • -bz2 -tar.gz -tgz -rpm A lot of directory indexes contain just archives of Linux/BSD packages, we do not want these show up in the results.
  • (reilly|addison|kluwer|MIT) Each directory index of eBooks should contain at least one book from one of these large publishers.

That’s it. To further limit down the search, add your own keywords (e.g. Java, J2EE, or whatever)