So, while I wait for another bunch of projects to come to a point that I can port them to this process/product - I am looking for a new issue tracker tool. Nobody likes the tool we are using right now, the configuration manager least of all. So, I am looking for an issue manager that uses subversion. Trac seems to be the best bet. So, I am trying to build it, knowing nada, zip, nothing about Python.

It isn't building. It can't seem to find the sqlite library. It should be able to find it - I dropped the exe and dll into System32.

I put a Please help me on the mailing list - but zip so far.

More & more I want to write the issue/requirements tracker that has been in my head for so long. I would write it in either java, php or Ruby on Rails. I would put an embedded firebird database behind it. Now, I have to get people to believe that they should let me do this at work. I am too damn old and tired to do it at home in my oh so copious spare time.

I have reached the stage of hating maven, I used to just mildly dislike it. In fact, if I had the time right now, I might just move my dependency management to Ivy. That isn't going to happen yet though.

1. The useful plugins are all in beta
2. There is close to no documentation for any plugin I want to use
3. When I ask the user's list for lessons learned/documentation/whatever you want to call it - I don't even get a "you ignorant slut" for an answer.
4. When I tried to get the code for the war task through svn - the war task is NO LONGER IN THE SVN REPOSITORY
5. I can't get the scope of transitive dependencies

So, now all I use maven for is to build an eclipse classpath that I then edit so that my regular attributes (like src and docs) are in it.

I have written a nifty common war task though - although it uses excludesfile. What do you bet excludesfile gets deprecated in the next version of Ant? It would be just my luck.

But, in reading blogs, it seems that I can't go even 1 day without reading the phrase "syntactic sugar". It seems to be the newest catch phrase, and it is beginning to annoy me. Also, I am not sure why so many people feel there shouldn't be such a thing.

People, if syntactic sugar makes my life easier, I am all for it. I really don't care if the compile takes another minute - ant and vulcan are managing that for me anyway. If you want to go back to barebones languages, I am sure we can find a PDP-11 somewhere for you.

One of our junior programmers today suggested that smart people had already solved the standardized build project. Hell, some of us have solved it 3 or 4 times. But each company has tradition and rules. A standardized build for Treasury is different from a standardized build for the small piece of DOD I am working for. Among other things, they solve different problems. And you have different big feet around that you don't want to step on. I still prefer my old build to the one I am now using, but I have to respect their work and build on it - not destroy it.

By the way, one of our really really FANTASTIC programmers has written a replacement for anthill/cruisecontrol. I am just getting used to it - it is excellent. Go look at Vulcan on sourceforge.

In other news, I have been doing almost nothing but ant for a few weeks. Ant sucks as a scripting language (as it should). I am still considering moving some of the scripting over to Ruby, but I have managed with Ant this long - I have just been informed that we simply don't have the time for me to refactor. The one project that should be done by march has turned into 13. Most of them are exactly alike (and we have a backup), but I am getting a bit concerned.

All of this will help me when I start my next story - I have 3 projects right now, the next story is the first story in the second project. The ant stuff I am doing now could go opensource (it is a replacement for the eclipseclasspath plugin). The next stuff is DOD, so I probably will not be blogging about it.

I got two books on ant. Luckily, the O'Reilly book has been updated. I am taking notes for a possible book. I am a smart person - and it is not easy for me to figure out path oriented tasks.

Everybody here pairs (except me). Everybody uses agile techniques (I use some of them). Everybody else knows what stories they are working on. My job changes every day (and I like it that way).

I find this strange because I am the person who is supposedly building the tools to make life easier for the programmers. It seems that I am also the new Subversion Queen. I am writing (or helping with) the opensource code, on a project that is as not opensource as a government project can be.

All of this would be ok, but I am not getting any practice on stories and iterations - and I was weak on them to begin with. I am putting X-Planner through its paces, but I don't do enough agile work to really test the code. So, other programmers here tell me what they need changed.

I have offered to teach Ant for grownups if anybody is interested. I really don't want to be a single point of failure. Of course, I never really wanted to become an Ant specialist either.

But, as usual, there is a problem here. I have No idea what a build/release engineer does when you also have 2 configuration engineers on the project. For some reason, I can't see how you can be one without being the other. Right now, I am automating the build process, but I would be doing that anyway in my role as toolsmith. If anybody who reads this (and there aren't that many readers) has a good definition of what the various people do - I would love to read the defs.

Maven2: We are giving up on maven 2 except for library management. I don't like a whole lot of things about it, but what I dislike the most is that it seems to believe that if you are managing with maven, you want to manage everything with maven. Well, all of you maven people, I don't want maven writing over my classpath file. I want it to update it. I don't want it to overwrite my project file either. And I certainly am not going to trust my code to a project that is averaging 100 bugreports a day after it is released. It is nice that they decided to rewrite maven - but they need better quality control.

I am refactoring the stuff I wrote 2 weeks ago. My partner in crime (even if he is across the whole damn country) is trying to get me to look at ivy. I am not sure if we can get Ivy to do what he seems to want it to do.

I got XPlanner working today. I am going to install it on a real machine tomorrow. I then will decide what we want to do with it.

Of course, it is also possible that I am an idiot and that eclipse plugin code is beautiful and I can't figure out how it should be tested because I am a twit. Many people would probably agree there. BUT - I did ask another programmer to look at it and he said something like "You aren't going to try and extend THAT?????? Are you?????" This is not a case of "Not invented by me". This is a case where there are 5 unittests, named unittest1,2...5. and none of them test anything other than if the code throws an exception. Thank you, that is not what I call a reasonable unit test. Also, the code is not easily testable because it takes (I think) 10 parameters to construct the class I was going to extend. Somebody up there does not approve of dependency injection.

In other words, they wrote legacy code.

So, I am letting the eclipse plugin build a file that I will never use. I am then pulling a dom from it. I am then comparing it with a dom from a .classpath file that I have already written. Doms are then being merged.

Interestingly enough the artifact class does not build a good string for a jar name. Silly shit like that. 200 messages a day since they released Maven 2...and too many of them are jira cases. The plugin left my eclipse projects uncompilable.

So, I will do what I can - and then decide whether I want to rewrite the plugin. I doubt it. Maybe for maven 3?

Yes, I still hate Maven. I also think that it is where we are going to go for at least some of our projects. Maven 2 has been released, and I am now extending it's eclipse plugin. I want it to learn how to update a .classpath, and how to include src and javadoc resources when building a .classpath from a POM. I am hoping that this will get around what we consider to be weaknesses within both eclipse and maven.

While doing this, I am making use of the plexus toolkit (because maven already uses it). Excellent toolkit. I would do some things differently, but I was able to get used to it in 1 day. It is going to become part of those files that I carry around with me from project to project and job to job.

After I get this all finished we will make a decision about how much farther to go with maven. Right now we are just going to go with standardizing resources every developer needs to be able to find. This means that some developers will have to do things differently, but I am NOT the person who has to enforce Best Practices here.

It is so much fun working with a crew of really bright people again. I swear, I haven't worked with a crew like this since I got my dream junior programmer at Nasdaq.

What I am blogging about is Maven2. I am one of those fanatic maven haters. It bit me in the ass when I first started here, and I (with company blessing) took all the code OUT of maven. Actually, there are pieces of maven I like, mostly the war and jar plugins. But, they aren't worth the maven workaround.

I am a software nazi. I believe in a standard build structure. Unfortunately, my standard build structure is not the same as maven2's standard build structure. m2 has a tree that starts as src/target (fine so far). But src then splits into main and test. Then both of these break into java and resources. It just lost me there. I think that the use of main adds complexity. Mine starts as src/test. They both then split into java and config. I could rename config, but I think that it is actually more descriptive than resources, which has a very specific meaning in java. Both are perfectly acceptable build structures, but I don't want to user the main style build. I could (and might) change my build to mirror the m2 build, but I am still not sure how well it would work.

I am also still working on adding a ruby on rails project inside a project.

What I loved maven for was the ability to pull jars/poms from ibiblio. I am going to look at ivy next week and see if it will work to pull my dependency tree instead. If it does as good a job (or better) than m2, I will stop thinking about m2.

BTW, one of the things I HATE about m2 is that it STOPS pulling all the dependencies and chokes the minute it needs to use a sun library.

This happens at just the right time. My main quickstart is well tested, I start the administration piece of the authorization software today. The company I am working for has no projects that fit me well. I am not sure if they have ever bought into OO, much the less java, .NET or agile processes. My beloved manager has moved to a new job in a big (non-consulting) company that will be perfect for him.

Bill (the manager) and I will continue working on the quickstarts, and the business objects that started this whole mess. They will be opensource. First release (probably just the quickstarts, the common jar and the authorization code should be ready to roll by November.

This dao needs a lot of data to be in the database (this is the project that is going to use ruby on rails to fill the database). I (like most people) have used dbunit to put this data in. Part of setup. Well, setup and onSetup are final for this test - so I moved the dbunit setup (which had been in a static initializer) to onSetUpBeforeTransaction. All of a sudden my tests were not failing - they were going into some weird state and I had to kill eclipse in order to close the database. But, as soon as I moved the database to local (from embedded) everything went just fine.

I think that we had deadlock on the embedded firebird. My cure for this now (other than giving up on the spring class and rolling my own which would happily use dbunit) is to stop using embedded firebird and call through local. I still might roll my own, but it depends a lot on what else has to be done in the next two weeks.

Here is one for firebird. Thanks to Roman who seems to be in charge of firebird-java for giving me the sql.

import javax.sql.DataSource;
import org.springframework.jdbc.support.incrementer.OracleSequenceMaxValueIncrementer;

public class FirebirdSequenceMaxValueIncrementer extends
OracleSequenceMaxValueIncrementer
{
/**
*
*/
public FirebirdSequenceMaxValueIncrementer()
{
super();

}

/**
* Convenience constructor.
* @param ds the DataSource to use
* @param incrementerName the name of the sequence to use
*/
public FirebirdSequenceMaxValueIncrementer(DataSource ds, String incrementerName) {
super(ds,incrementerName);
}

public FirebirdSequenceMaxValueIncrementer(String incrementerName)
{
super();
setIncrementerName(incrementerName);
}

protected String getSequenceQuery()
{
return "SELECT gen_id(" + getIncrementerName() + ",1) FROM rdb$database";
}

}

After I finish the jdbc examples I have to decide whether to do the same for jdo and ibatis.

Honestly, I don't think anybody in the company will ever use these, but it doesn't hurt and keeps me busy. As long as I look busy, I will probably keep this job.

Still not sure about jdo and ibatis though. This is turning into an awful lot of work.

Any opinions on this?

Right now I am trying to get ant and hibernate playing together. I am a newcomer to hibernate 3 (I hated hibernate 2 and used it daily). I think I am a reasonably intelligent person. So, tell me, why can't I get the reverse engineering task working in less than an hour? I not only need to get it working, I then need to document how/why/when on it. Let me tell you, the information on the web is very sparse for hibernate 3 tools. And, of course, nobody has come out with a decent book on hibernate 3. I have no idea if any are even planned.

Makes me think more and more of just going with straight spring/jdbc. Wouldn't have to teach one more framework. Wouldn't have to tear my hair out. Wouldn't have to document the how and why of hibernate tools.

Of course, I have also realized that I need to write a short, humorous, and factual manual on how to use ant. And why it will make your life easier and keep your manager from strangling you. I don't want to go into the api, I don't want to teach people how to write tasks. I just want to explain how to get hibernate working and how to build/deploy a war file.

Damn, I wish there was a decent book on hibernate 3. Or even on ant.