1 2 3 4 Previous Next


51 posts

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/guilderwhich intends to be a replacement for Maven 2taking 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 andGraven 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

After several futile attempts to get my deployment units to log to Glassfish I finally figured out to use Log4J in Glassfish which is not really well documented there. So that is what I had to do:

  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 directorythat 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>/configdirectory. 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.

Based on the success of Log4J Sun for sure had to go ahead and add its own version of it as JDK logging making our life miserable. I was complaining a lot about that at the LA-JUG but today it reached a point where I really had enough to start ranting here.

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 useSystem.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.

After I could build the bundle and the repository I am now able to do what I wanted to do a year ago. Bug 6313849 is an enhancement request to add a disconnect() method to the URLConnection class so that one can close any URLConnection without having to know which protocol is used and without any fancy upcasts. This is a generalization of my previous contribution to the JDK and so I wanted to tackle it a long time ago but never found time to go through the hassle of building the entire JDK.

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 methoddisconnect.

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


Open-Sourcing JavaOne Blog

Posted by schaefa May 11, 2007

JavaOne is nearly over and it was a good as well as a bad convention. One of the things that stroke me was the fact of registering for a session and then standing in line for it. Considering the fact that back in 2000 there were 25k attendants and no registration / lines and it worked out mostly fine I have a hard time to understand this approach. I remember that some complains back in 2000 were that some people could not enter that a popular session but instead of creating an overflow room where they could have a big screen so we could watch the presentation remotely they just failed back to access control. This is like as if a servlet developer would have a problem with multithreading and as solution would make it single threaded. It does the trick but the fix is maybe worse than the problem.

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

Last night I went to the Java 3D / OpenGL Bindings BOF and in all the locomotion I forgot to pick up my fairly new MacBook Pro after asking a question. After the next session I suddenly realized it and raced to that room and my laptop was still there even though it was moved to the next row, ufff.

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

I love you all - Andy


OpenJDK: Here I come Blog

Posted by schaefa May 10, 2007

Ditching the Keynote session at JavaOne I am sitting in the Alumni room and trying to get my head around the OpenJDK. Having a MacBook Pro I cannot download the JDK and build it on my Mac natively and so I needed to fire up my VMware installation of OpenSuSE and use Linux to build it on top of the Mac. So I went to the OpenJDK website, downloaded the source and the binary plugins and extracted them. Then I went ahead and tried to setup the environment as requested byj2se/make/jdk_generic_profile.sh script file likeALT_BOOTDIR, ALT_CLOSED_JDK_IMPORT_PATH, LANG and emptied JAVA_HOME. There I realized that I do not have Java 6 installed so I downloaded and installed it. Finally I was ready to fire up the build:

cd control/make
gmake sanity

and sure enough it failed right away complaining missingAlsa headers. After going through some hops I finally could install Alsa, Cups and Motifheaders. For Motif I had to revert tolesstif-devel which I have to force to install because of the dependencies of lesstif. Nevertheless I got that going and after settingALT_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 fileinclude/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 shortjava -version confirmed that I have built JDK 1.7.

Cool - Andy


EJB3 and Glassfish Blog

Posted by schaefa May 8, 2007

I just had a nice discussion with John Clingan, product manager on Glassfish, about EJB3 and Glassfish in particular. One of the thing that strikes me with EJB3 is that Sun seems not to be able to let go of old stuff. Right now an EJB3 application server needs to support EJB2 and EJB3 and must make sure that they do not conflict. This is going to convolute the code and drags down the performance. If I would have been in charge I would have made the support of EJB2 optional and required that an JavaEE application is either EJB2 or 3 so that the application server can deploy it on different containers. I would it even have made it possible that an application server can only support EJB3 and so a deployment of an EJB2 application would fail.

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


JavaOne 6 Years Later Blog

Posted by schaefa May 7, 2007

It is six years since my last trip to San Francisco to attend JavaOne and boy has my agenda changed since them. Back then I was working on JBoss and there was a huge fight between Sun and the open-source community on a lot of issues surrounding Java. Now Sun is going to finally open-source Java which is a great success for the open-source idea but I couldn't care less.

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

I am delighted that Sun finally decided to make Java open-source and to harvest the ingenuity of developers around the world. In a few days or months the Java source code of the JDK should be available and with a good build system developers should be able to fix long standing bugs or enhancing some of the features.

The only question remaining: Is OpenJDK really open-source?

What do I mean with that. Open-source is not only to make the source code available and it is not enough to let outsiders contribute patches. In my opinion the main question is who is going to control the project and decides which patch goes in or not. Contributing patches is a great way to show your abilities and commitment to the project but if a developers invests a lot of time with good work then he / she wants to gain more access to the project by having write permission to version control, being able to manage other submitted patches and much more.
As far as I can see the only persons with version control access are Sun employees and so Sun still controls and manages the project. If that is the case then I do not call it an open-source project but maybe I am just too early to ask this question but JavaOne is on next week and I would love to get some answers on how Sun indents to run OpenJDK.

See you at JavaOne - Andy  

JDK Community: Update Blog

Posted by schaefa Apr 5, 2006

After quite some screaming and kicking (see my previous blog) my fix for bug ##6212146 made it into Mustang build #78. For a change I do not want to bitch about anything but congratulate Sun for all the progress they made in the Peabody endeavor. Any community project in a big company is difficult especially when so much is at stack as in Java and lawyers tend to be the problem as well as the solution and so it is amazing that the community project went as far as it did. Of course, there is a lot that can be improved and I will try to contribute to that as much as I can but I think that Sun is on the right path and I see the light at the end of the tunnel where Java becomes an open-source project.

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

Greg Hamilton blogged about AOP: Madness and Sanity talking about where and where not to use AOP and I nearly threw up, figuratively speaking, of course. Primary AOP is a concept that wants to relive the developer from some of the constraints of traditional OOP. I say traditionally here because J2EE is some sort of a AOP light framework already using some of the AOP concepts even though it is not really AOP by any stretch of imagination. In addition he said that the AOP allows the add code in a cross-cutting concerns manner but I think that is not the most important feature of AOP even though it is the best selling point because it can be illustrated quite easily. For me the most important feature of AOP is what I call "feature merge" or "loose integration" meaning that I can take two or more components and massage them in a way where they can interact together without actually changing their code base. I think that is actually what Greg's thinks is the bad part of AOP and he said that only Container based AOP is good because it is well defined even though I know too many J2EE developers who do not even understand the basic concept of J2EE transactions good enough to work as a J2EE developer. But Container base AOP is somewhat weak, very limited in its scope (not everything is an EJB in Java) and very rigid. On the other hand I am quite surprised that after the past where Sun said that JBoss will not pass the certification because it allows the user to change the way J2EE framework works by changing the interceptors I now see that interceptors are part of EJB3 specification. So I guess that JBoss has prevailed with its vision of a dynamic J2EE.

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.


Yesterday Ray Gan blogged about the JDK Community listing some of the facts about the Peabody project. If you never heard about that project then you are not alone and I only now about it because Joshua Marinacci gave a presentation about it at the LA-JUG last year. But even without knowing about the Peabody project is became a JDK contributor last year in November and started to code a fix for bug #6212146 which I has sent to Sun for a review by the end of November. I got an initial confirmation that the bug fix was received but that was all I heard from Sun for a long time. Then January 2006 Ray blogged about the state of JDK Community and I responded complaining about that I got no feedback from Sun about my patch. A little bit later I finally got an email from Michael McMahon (1/31) that they started to look into the patch. I also spoke with Matt Ingenthron from Sun about it and he tried to find out what is going on and to bring some more transparency into the JDB Community. Needless to say that I did not get any feedback since then

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).


Tuesday, 6th of December 2005 I had the chance to attend Carlos Sanchez's presentation about Maven 2 at the LA JUG in El Segundo. I already played around with Maven 2 and therefore had a list of questions I tried to get answered. Especially I wanted to see if my concerns I expressed earlier in a Java.net blog where valid or not. Today I came to the conclusion that Maven 2 has some good ideas but I think that the Maven team threw out the baby with the batch water in some of the new features/restrictions and so I still prefer Maven 1 over Maven 2.

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.


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

This week I created a test suite for a project I am currently working on and a coworker wanted to run the same tests but no matter what we did defining the junit task in the Ant build script failed. The script just reported:

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

Filter Blog

By date: