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

1. Place log4j.jar and log4j.properties file somewhere (I put it into <Glassfish Home>/lib/log)
2. Add the fully qualified path to the log4j.jar into the classpath of Glassfish together with the directory that contains the log4j.properties file. You can do that in the web UI: Application Server/JVM Settings/Paths and the entries are separated by a return.
3. Restart the server

Now you will find the log file relative to the <Glassfish Domain Directory>/config directory. Now I can read the log4j output like usual even though not in the same file as the Glassfish log statements.

Now some feedback to the responses I got:

1. I could use SLF4J but this does not help for the classes provided by ServiceMix and that are the more important logging statements
2. Well, Log4J was here first and so many projects and products were using Log4J way before JDK 1.4. And because logging is such a wide spread component so it the pain the incompatibility is causing.
3. If Sun had provided a superior implementation that Log4J I could bite the bullet but they did not and so the whole idea of the JDK logging is ridiculous. And therefore I also don't want a JSR because that is making it even more painful.

Moral of the story is that if Sun could have swallowed their pride and either kept Log4J out of the JDK or just incorporated Log4J as is like they did with Corba we would not have this discussion. Now we have several frameworks on top of them that are trying to fix that and each of them fail one way or the other, what a mess. Thank you - Sun.

Currently I am working with Glassfish and beside some other sticky points with it I ran into an issue with the logging or better the absence of logging. What I want to do is to deploy ServiceMix based JBI components as well as our own components to deploy on OpenESB that runs on Glassfish. Something is not working as expected and so I started to look into the log files but could not find any log entries from our applications. Finally I figured out that my component is using Log4J instead of the JDK logging that Glassfish is using. This is because the component contains Log4J archive because one of the other components needs it. On the other hand Log4J is not creating the log file and so the log entries vanishes. Now I cannot remove Log4J because some of the components used needs it but I cannot make the commons logging to use the JDK logging in my component. Maybe I am just stupid enough not able to fix that but using a logging framework should not be rocket science. Right now I started to use System.out.println() just to see what is going on, ridiculous!

Now how to could this be fixed? Except the Glassfish community is striving to shut out any component that is using Log4J one should expect that Glassfish could provide a Log4J wrapper that takes the Log4J statements and redirects it to their JDK logging. As the JBI components show the issues from class loading making it impossible for Apache's Commons Logging to select the correct logging framework and even when only CL is used it may not work as expected.

So far I went through all the different sub classes of URLConnection and implemented the disconnect() method. Then I needed to create a test with jtreg which is not that trivial. The first problem is to decide where to place it. I could add it to the URLConnection or to the sub classes. I would thing it would make more sense to place it with the sub classes but I am not quite sure. Then I don't know if the test should be named after the bug number or after the newly added method disconnect.

If that is successful then I can send a patch to Sun so that they can evaluate and test it. So far so good but the entire experience with building the JDK and then go through the contribution process as of now is not very satisfying. First I had to build the entire JDK including the JVM etc even though I was only working on the Java source files. After the changes I had to execute a rebuilt and even though I tried to do that only inside the J2SE folder it deleted the entire build directory forcing a total rebuilt including the JVM etc. This is not very user friendly and will discourage some developers to start working on the JDK. A solution to this problem is to create a separate built system only for the Java source using most likely Ant so that I can rebuilt on the part I need speeding up a build cycle quite a lot. Together with a binary build snapshot of OpenJDK we can free the developers from building the whole enchillada if they are only interested in the Java code.

Have fun - Andy

On the other hand the attendants get a paper sheet to evaluate the presentation where one had to ender not only the evaluation but also the ID number. But on the convention we have a Java card (I assume) which already has the ID number and so why can't I evaluate it online on the Sun Ray stations or even do it over the phone especially when one of this year's theme was JavaME.

As an open-source developer I like organized anarchy and therefore have a problem with the overly organized JavaOne. In the early conventions I could roam around when a presentation did not turn out as expected. But when I have to stand in line sometimes way after the session starts then I not only miss parts of the session I also miss even more of a fail-over session.

This also prevented me from adding fail-over session into my schedule because the scheduler does only allow one session at the time because it uses it to control the number of the attendants. This makes it really hard to manage them because I always have to go over all the session rather than only focus on the session I am interested. I am only interested in OpenJDK, Java EE and maybe a little bit Swing which means I am not interested in JavaMe and the Web stuff. Still I was forced to use the rather slow JavaOne website and go through all the session per time slot or per day.

Have fun - Andy

A thank you to all the people who saw the laptop but did not to take advantage of it.

I love you all - Andy

cd control/make
gmake sanity

and sure enough it failed right away complaining missing Alsa headers. After going through some hops I finally could install Alsa, Cups and Motif headers. For Motif I had to revert to lesstif-devel which I have to force to install because of the dependencies of lesstif. Nevertheless I got that going and after setting ALT_MOTIF_DIR to the directory (/usr/X11R6 on my box) containing the includes I was ready to go, at least I thought so. Unfortunately the sanity checks are looking for this file include/Xm/AccColorT.h which is not in lesstif but when I just created that file with vi the make system happily start to build, yeeha.

As a side note I wanted to fool the build by just creating the AccColorT.h file because I saw that on some mailing list that the JDK build does not need Motif but that is wrong, at least as of now. Some generated classes (I found a class called sizer.c) uses it in its imports.

Finally, after nearly an hour the built went through and a short java -version confirmed that I have built JDK 1.7.

Cool - Andy

Well, I wasn't in charge and so we have to live with it. I am just wondering what will happen when EJB4 is released or do you remember EJB1 and the deployment descriptor classes? So deprecation seems to be a good thing but it should not only be applied to the first release. Especially for an application server there is no real need to require that an application needs to support both. EJB interactions enables us to build application using both new and old specifications without intermingling them.

I need to have a look into Glassfish especially V3 to see if and how their modules work out even though I will remain skeptical but it always good to try out new things.

Have fun - Andy

The power of Java does not come from the language or even the JDK even though there is a lot in there lately and in my opinion too much. The power comes from the open-source projects around Java that improves and increases the usefulness of Java and I am not talking about the applications based on Java. There is networking stuff like JGroups and Azureus (bit-torrent), high availability like HA-JDBC and Terracotta, build systems like Ant and Maven, Log4j (logging), Rome (RSS feeds handling), concurrency, web frameworks and much much more. It is really hard to find a niche were one could start a novel open-source project because most likely someone else already had that idea and started a project like that.

What Java provides to me is the foundation that makes it easy to harness the power and versatility of all the open-source projects out there. Quite often a project has to ditch an open-source project only for the reason that it is too big for what the project needs it for but still then the code of that open-source project can be the inspiration of the stripped down version they are finally using.

That said I indent to participate on the Open Java project if something is bugging me and to participate in open-source project again. Even though I don't care much about open-sourcing Java I care about Java and I love to participate where it makes a difference for a few people. I need to make a living and that will not be through open-source, so far, but I would not be who I am now without open-source and my previous commitment for it. I learned so much about Java and how to manage and design projects that it outweighs the time I spent on it.

Enjoy - Andy

Nearly ten years ago I had an job interview in my hometown in Switzerland and the manager  asked me what I would like to do as a software engineer if the sky would be the limit. According to his reaction he was not used to hear that a little developer would like to write software that is distributed worldwide. Since I moved to the US this dream became more and more reality and now some code will be distributed along with JDK 1.6. Now, the only thing left to do is world domination, right Pinky.

Bad Andy - Better Pizza

If I am going to use AOP then I need a very compelling reason and J2EE is not going to cut it. Therefore I crafted the title to indicate that AOP is not here to be squeezed into a container but to free us from the constraints of OOP and therefore we have to free AOP from any container. If you want to be on the safe side and do not want to explore the final frontiers of software development then AOP is not for you. AOP is difficult, hard to debug and sometimes risky to use but you can gain a lot from it: no pain, no gain. AOP is not here (at least currently) for the weak but for the brave who dares to push the limits to make things easier. I can promise you that you will be frustrated quite a lot and you will fail several times until something is working as expected. But anyone how made the transition from procedural programming to OOP or hierarchical to relational DBs can hopefully use his/her experience to understand the difficulties in the transition from OOP to AOP.

Oh yeah, annotation has to end up here because it is so great, isn't it !?! Annotation in EJB3 makes the whole thing only complexer because I now need a tool to know what is a remote interface, an ejb and what the actual JNDI name is because it is buried insight the bytecode rather than to have it explicitly insight an XML file. Annotations are just a way to tag elements in a class, nothing more and nothing less and so do not have anything to do with AOP. Most AOP systems like AspectJ or JBoss AOP provide support for annotations to declare aspects, pointcuts etc but especially for AOP I prefer to keep the definition outside of the source code because I want to be able to change it without rebuilding the project.

Any paradigm shift is painful because we have to give up our comfort zone in order to conquer new ground but it is not done by restriction. Christopher Columbus would not have found America if he did believe into world's view of that time and so sanity can be the madness of human evolution. Don't get me wrong if you are happy with you have and you want to code Java for the rest of your life then be my guest but do not expect that the world just stops spinning because of you.

-Andy

As a good citizen I took the time yesterday to fill out the survey and to pour in some of my thoughts and complaints. Now I take the opportunity of this blog to share my thoughts on the JDK Community to a broader audience. As an active open-source developer I know both sides of the aisle, the one that runs a project and the one that provides patches. But in order to keep a community alive and active the project team must react to input from the community and give feedback without being pushed all the time. Especially in this case where Sun is a huge company and Java is a big project getting a community project up an running is difficult. Nevertheless as a contributor I think I have the right that Sun not only receives the work from the contributors but also gives something in return and the very basic would be feedback on the progress of a patch. Unfortunately a regular contributor cannot get the CTS in order to make sure that one's but fixes does not break Java and so I cannot test it thoroughly. This means a contributor has to wait until Sun provides feedback to improve the patch. As a contributor I do not want that my patch is swallowed by a black hole and one day it makes it into the JDK or not.

I suggested a few improvements and most prominently I would love to have a contract person within Sun with whom I can work on the patch to make it into the JDK. He/she does not have to be the developer that test or improve the patch but he/she must be able to answer questions and to provide feedback. I do not need contests, awards or public recognition but I would love to have my name as author in the Java code when the patch makes it into the JDK. In addition I would love to have forum(s) for contributors where they can discuss items with the Sun's Java developers and also a way to track which contributor is working on which bug so that I can avoid working on a bug that someone else is already working on. Maybe it would be a good idea to invite some contributors into an expert group to improve the JDK Community process.

Currently I am not working on any patches for the JDK because I want to ensure that my time spent on this is spent worthwhile and so I want to see if it makes it into the JDK or not and in case it fails I want to know why. That said I still hope that Sun can improve the JDK Community because I would love to work on the JDK in the future. So far I am disappointed about the process and also think that this is why there are not as many contributions as one would expect (see the JDK Community List).

-Andy

These is a list of the problems I have with Maven 2:

1. Properties cannot be set outside the POM
2. Any dependencies must be provided by repository (local or remote) and cannot be redirected to a directory within the project.
3. For now a project cannot reuse Jelly code from a Maven 1 project and so must convert that code into a Java based plugin.
4. The build hierarchy cannot be extended by the project (no pre or post goals) and the order of plugins executed within one build step is undefined.
5. The current Maven plugins use Java classes and the plugins downloaded do not include the source. The source archives of these plugins then do not include a build environment just only the Java source code.

1. Properties cannot be set outside of the POM

Many open-source projects use other applications to build, deploy or execute their application. Most of the time the project needs a path to this application like for example the JBoss deploy directory or the installer root directory. On the other hand the project cannot know the path to these directories and therefore does not want to include these directories into their version control system(VCS)..The only solution is that every user does set the path in a separate properties file like the build/project.properties file in Maven 1.
For me this is a must have requirements and I do not see another way around it.

2. Dependencies must be in the Repository

Not every open-source project has their archives deployed in the Maven repository or is able to run their own repository. Also sometimes the Maven repository is not up to date or cannot provide archives for other reasons. In that case an open-source project needs to add dependencies in their VCS and add the dependencies without the repository. Currently in Maven 2 a project can only ask the users to copy the archives in question to their local repository in order to make the build work.
I could accept that if Maven 2 would be able to have a project internal repository that can be made available through the VCS.

3. No Jelly in Maven 2

In Maven 2 one cannot inline or execute with a plugin any Jelly code one might have from a Maven 1 project. Even though that I do not like Jelly as a scripting language it really makes sense in conjunction with Ant because their XML code can be easily intertwined making it easy and fast. Maven 2 allows user to inline Ant and so I was wondering why not also Jelly.
This is a must have requirement for me.

4. Build Hierarchy

In Maven 1 it is easy to hook into the build hierarchy (defined by the plugins), extend the build hierarchy or do overwrite it (somewhat like in AOP) with what I need. Maven 2 does not allow me to do that anymore and so I am stuck with the build hierarchy. For example if I would have a code generation tool's output is the others code generation tool's input then I have a problem because I cannot define an order in that step. Whatever build hierarchy Maven 2 has there will be projects that do not fit in. As much as I agree that many developers misuse Maven 1 there are still valid exceptions out there that do require a more flexible build hierarchy especially when Maven 1 had this flexibility.
A tool must make the life of a developer easier and that is just the opposite.

5. Source of a Plugin

Having the Jelly script with the Plugin in Maven 1 as the one single feature that sold me to it. It helped me tremendously to understand Maven, was a great source of how to do it and an easy way to debug it. Now with Maven 2 the plugins are written in Java and they do not contain the source and even the source archives does not contain a full build environment. I think that is quite a hassle and is not user friendly at all. I also do not understand why it was not possible to write a Jelly compiler if performance was an issue.
Java has proven that speed is a relative thing and so I do not see the need for Java plugins. I saw the problems of Java based plugins in the XDoclet project and would loved to see them using a scripting language instead. Now Maven 2 does the reverse with minimal gain but a lot of pain if things do not work as expected and that will happen quite often.

Conclusion

Beside the fact that Maven 2 made it to be released the other concerns are still valid leaving me no other choice than to keep using Maven 1 for now. In my opinion the team failed to meet their own goal of making Maven 2 simpler and easier to use than Maven 1.

Have fun – Andy

taskdef A class needed by class org.apache.tools.ant.taskdefs.optional.junit.JUnitTask
cannot be found: junit/framework/Test

even tough we added junit.jar in the classpath in the junit's taskdef.. After a search on the web I figure out that a long time ago I put junit.jar into the Ant's lib directory and now forgot to tell my coworker about it.

The reason for that is that the classes for the Ant's junit task is in the archive ant-junit.jar and that is placed by default in the Ant's lib directory. So the class loader of ant will have the junit task put is not able to find the junit classes because Ant does not bundle the junit.jar archive together. Now even when I put the junit.jar in the taskdef's classpath the Ant's class loader is not able to find the junit classes because junit.jar is only available to a child class loader. There are only two ways to fix that:

1. Put junit.jar into the Ant's lib directory
2. Remove ant-junit.jar from the Ant's lib directory and add junit.jar and ant-junit.jar into the taskdef's classpath

In my opinion both solution are bad because it requires human interaction and the user is maybe not aware of the problems that go along with each solution. Solution 1 does look in the version of jUnit that can be used even when another Ant script wants to use a newer version. Solution 2 maybe breaks other scripts that expect that both archives are in Ant's lib directory and does not add both archives to the taskdef's classpath.

The best solution in my opinion would be that all optional tasks that need another library are not placed into the Ant's lib directory so that they are not loaded by the Ant's class loader. Ant's distribution could have them in a separate directory available for scripts to use. Now in the jUnit's taskdef one could add the ant-junit.jar from the Ant distro along with the desired junit.jar. This way there is not human interaction needed and the scripts can choose the library they want to use rather than relying on the user to select the right one to be put in Ant's lib directory. Of course scripts that do rely on the fact that these archives are placed in Ant's lib directory would need to be adjusted but that would be a one time task rather than spending hours later to figure out why the junit tasks fails in certain environments or after someone upgraded to a newer version of Ant.

Once again convenience has proven once more, at least to me, that on the long haul it uses up more time solving the problems it causes than what it actually saves in the first place. I think that it is much better to fail fast rather then letting a problem lurk under the surface and then it bites you from behind at the probably most inconvenient time.

Have fun - Andy