Andreas Schaefer's Blog

Tools Archives

3 Years later my Bitching became Code: Guilder POC Release

For the impatient readers I just wanted to announce the release of the Guilder POC which can be found on its wiki: https://madplanet.com/trac/guilder which intends to be a replacement for Maven 2 taking the cool features of Maven 1 and 2 and also incorporating some of the cool Groovy stuff to give building projects its Groove back. For all others here is the a little bit longer story.

In December 2004 I first complained about Maven 2 and I never really started to embrace Maven 2 and still think that Maven 1 is the better solution. But now Maven 1 is dead and Maven 2 took over. Eventually I had to use it in my line of work and discovered even more problems. Because I don't think that Jelly is a good scripting language and never started to be used outside of Maven 1 in a bigger way I was looking for another scripting language that I could use as its replacement. Eventually someone pointed me to Groovy and the Maven 2 Groovy plugin. Even though I liked the idea of Groovy the Maven 2 Groovy plugin did not work for me. I did not want to have a plugin that execute Groovy code but that could be written in Groovy. I also did not succeed in mixing Ant statements with script code as I could do in Jelly which took most of the appeal of Groovy away and so a lot of time passed by.

Well, somehow I stumbled over Gant which is Ant in Groovy and I saw in an example what I was looking for. Using closures and a Builder class Groovy was able to provide code that would exactly do that. Here is a simple example:

ant.junit( printsummary: true, haltonfailure: true ) {
    if( classpathName != null ) {
        classpath( refid: classpathName )
    }
    ...
}

As you can see there is Ant's optional jUnit task intermingled with the check if the classpathName is not null and then it will be set a class path ref for the jUnit task. Beside the fact that I can mix and match Ant with Script Code this code also looks nicer because I don't have to deal with the closing tags and with other XML oddities. So nearly two months ago I started to think about a project that uses Groovy able to replace Maven 2 with scripted plugins. Now you might think that why replacing Maven 2 if I just could add the ability to create and deploy Groovy based plugins. The answer is that there is more that I don't like in Maven 2 than just the compiled Plugins and I hope that eventually all of these shortcomings are handled when this project is released. Here is a list of such features:

• Scripted Plugins based on Groovy (maybe with JIT compilation)
• Plugin Context that exposes the user interface but also the interactions with other Plugins
• POM is a Groovy Script as well (no more XML)
• POM Is completely flexible and its structure is defined by the used Plugins rather than the Project
• Transitive Dependency Management using Ivy
• Local POM and local Plugins (see maven.xml)
• Goals can be overwritten or another goal can be executed before or after another goal
• The project builds itself
• ...

Then it took me around 4 weeks to finally get a POC release worked out and finally last Tuesday I was able to announce the release of it on the LA-JUG meeting. After that I heard from many other build tools that are growing like wheat: Apache's Buildr, Gant (heard from it before), Gradle and Graven. After a short scan I don't think that Buildr is a good idea because the instructions are written in Ruby but that's maybe just me. Gant is good but its Ant in a Groovy coat and Graven is the same for Maven 2. Gradle seems to be the closest to what I want to do but I think that there are still major differences between the two when it comes to the idea of plugins and probably other areas.

If everything works out as expected I should be able to release the Alpha version in a month or two which should have a solid core and a few full blown plugins.

Have fun - Andy

Maven: Jump Start

I started to love Maven not only for its scripting abilities but also for the fact that one could start a simple project in a few minutes which is even faster than to build a project with shell scripts. So if you are in doubt about Java just create a simple Maven project and test it with life code. Quit often this approach is even faster than add logging statements in your project or using a debugger.

Now during the creation of my upcoming Maven presentation @ LA Jug I discovered a way to create a project in seconds rather than minutes. Here is how to do it:

1. Open a console and go to the directory where your project should be placed in
2. Enter 'maven genapp' and hit enter
3. Select the template (if in doubt then just hit enter to use the default template)
4. Enter the application id which will become the first part of the application archive
5. Enter a human readable Name for you project
6. Enter the package for your source code like 'org.test.myapp'

Long life laziness – Andy Schaefer

Maven: 'I love you' afterall

Correction:

At the bottom of my weblog I complained that I cannot redistribute JAXB with my project forcing others to download and install JWSP. Ryan Shoemaker from JavaSoft told me that this is not correct and an updated FAQ entry about this is made available. I am glad to hear this and hope that JAXB can be found on the Maven repository soon. I hope that this confusion helped to clarify this important issue and I want to thank Ryan for his valuable feedback.

The first time I saw Maven I did not like it at all. It seemed to be a huge, complex and unfinished project. But somehow I could convince myself to try it out in my very own JDoppio project. So I checked out the Maven website documentation and wrote the initial project descriptor. Now I just had to write the code, jUnit tests and was ready to run the project. So instead of writing an Ant script taking me roughly around one hour I wrote the project descriptor in ten minutes without loosing any features.

Then I decided to split up the project into multiple sub projects and found some existing projects using Maven's multi-project tool like Turbine. This took a little bit longer to understand the multi-project but to write the sub projects was quick and easy as before. After that I needed to import sub projects into other sub projects which was easy using the local repository and the dependencies in the project descriptor. Using JAXB made it mandatory to add my own archives to the local repository. Finally using properties in the project descriptor allowed me to add certain archives to a class path or to copy them into the test environment to run the JDoppio server standalone. So every requirements by my project could be resolved by Maven very elegant without making it complex.

The biggest challenge to me was to find help on problems I wanted to solve with Maven. The first stop was their website but it only works for simple questions. But then I discovered that looking into Maven plug ins and their project descriptors and Jelly scripts provided me with a wealth of information and every time I look into a different plug in I find new ways to solve a problem. It also helps to look into other open-source projects using Maven and their project and extension (maven.xml) descriptors to see how they solved a problem.

The only problem I found so far was some buggy plug ins which I either did not care about or got the newest version from CVS to solve an issue. Otherwise I am convinced that using Maven is a real time saver and if you flexible it can be used in most projects I can think off.

Have fun – Andy

P.S.: Can someone explain to me why Sun does not allow JAXB to be distributed freely and I have to bug all other developers interested in my project to download and install Java Web Services Developer Package to just get this archives? As if only web service developer would be the only ones interested in JAXB. Sometimes I am really wondering why Sun cannot stop making our lives miserable even thought they are using open-source software in their distribution as well. So Scott, please could you prevent JAXB from becoming the next Java on Linux issue where it took Sun years until they went along with the developer community.

Debuggers: a modern 'Dr. Jekyll and Mr. Hyde'

I have to admit that I only use a debugger if someone wants to show me a problem he discovered within his debugger. Other than that I never used a debugger since I started to code in Java even thought I used debuggers before in C and C++. But when I started with Java there were no debuggers and so I have to rely on debugging statements and stack traces. When the first useful debuggers became available I had to switch between multiple OSs that, of course, one or more of them were not supported, yet. Finally, today, where many excellent debuggers are available but I really do not need them anymore and even think they do more harm than good. Dr. Jekyll or the debugger as useful tool can easily turn into a Mr. Hyde or a time sink if misused or overused.

Beside that for certain problems a debugger is a great tool it prevents many developers from focusing on the real problem that their code is plain buggy and that they have no clue where to look for. Stepping through a program only works well when the developer can remember where he came from and where he is heading to. But most of the time people lose that and when they found the problem they do not know how they got there in the first place and so the have to step through multiple times until they understand what caused the problem and how to fix it. A much better way is to look at your code, log output and, if you have, your test cases to localize your problem area and then focus on this area. For me this does mostly lead to a solution and I do not need a debugger anymore. With an AOP framework and a decompiler I can also debug third party library without a debugger.

You might think that I do not have to debug much and hardly have to deal with unknown code. As a J2EE application server developer I have to deal with many third party libraries, deployed application that are written in the company but also by customers and therefore I spend half of my time debugging code to find the problems and to fix it or to suggest a solution.

A debugger is like a telescope looking at the night sky and you have to find the North Star. With the naked eye you will find it pretty easily even when you have to remember that the rear leg of the Big Bear directs to it. The telescope needs to be directed pretty closely to the target otherwise you will miss it and waste a lot of time. Actually that would not be so bad but it prevents you also from learning the big picture of the night sky and to navigate easily through all the stars and nebulas. In addition a debugger can only work when program is not working as expected and therefore does not help in any way to prevent a bug. A debugger does not or barely work with race conditions (multi threading), class loading issues, network problems or any other runtime issues.

Here some tips how programs can be debugged without a debugger:

• Use a logging tool like ‘log4j’ to log the progress, warnings and exception stack traces
• Use ‘jUnit’ to write test cases and suites to make sure your code is working as expected and that the code does not regress due changes
• Narrow down the problem and check for previous warnings that may indicate the cause of the problem
• Use an AOP framework like ‘AspectJ’ or ‘AspectWerkz’ to introduce logging without changing the code
• Minimize side effects of other components or additional libraries
• Expect runtime problems from multi threading, class loading etc

jUnit to the Rescue

I was just recently faced with taunting task to revamping the transaction handling of the J2EE server without breaking it but improving performance and removing any resource leaks. Already two developers tried to do this but had problems to understand the existing code in the first place and so I failed, too. If we could not improve the code we had to dump the implementation and start all over again. Now just a few weeks before shipping I had to rewrite a central component without wasting other developer’s time and/or delaying the project. Lucky me jUnit came to the rescue. Instead of just starting to write a new implementation and then testing it I decided to write a test suite around the currently working code, replace the code and rerun the test suite ensuring that I did not break anything. Finally I had a chance to use test driven development (TDD).

As easy this sounds as difficult it was to implement. I spent around the same time for writing the test suite that to rewrite the transaction code but at the end testing was a breeze. The first hurtle was to decide how to test a transaction implementation because I did not want to rely on a DB, JMS etc and their side effects. So I wrote a fake XA resource that used JMS without transactions to trace the interactions with the transactions, various EJBs and 100+ tests. The first benefit from writing the test suite were a much better understanding of the transaction handling and its interaction with XA resources. At the end testing the new code was easy, straight forward and I missed one bug so far. The tests also made me very confident to put the code in the release branch without fearing to work on weekends just to fix undetected bugs.

So I have to give jUnit and TDD two thumbs up and see a beautiful friendship in the future. Nevertheless I have two little requests to the jUnit folks:

1. A way to write a message to the output file on a per test basis in order to write a description or other information out that later can be read and incorporate in a test suite report.
2. Currently there is only a successful or failed (failure or error) test result possible but sometimes it would be nice to keep non-crucial failures available but they should not fail the test suite. These warnings could be reported and even have a stack trace but would be considered a success. Examples of a warning could be a bug in a particular JDK or third party library that needs a work around but as soon as this is fixed the workaround should be removed or bugs that are postponed etc.

This work is licensed under a Creative Commons License.