I installed Subversion this arvo, and rebooted.

Bad move. The desktop would no longer come up on WinXP SP1a.

Uninstalled Subversion and my desktop was back, whew.

I couldn't believe it was Subversion, so I did it again, just to make sure.

Yep, no desktop again. Off to the tigris site....

Today I moved a build machine from Maven RC1 to RC2.

A multiproject build of 24 projects into a single EAR file (including non-container tests) used to allocate 154MB of memory.

It now uses 67MB to do the same thing.

Not optimal, but a swag load better.

Update: Oh, and it also cut 10 minutes of the build time too

Good work Brett!

See this technote for details on diagnosing problems like An error has occurred.

I found this report while browsing the bea site.

Interesting read...

developer works has an article on specifying the target server for j2ee projects in WSAD 5.1.1

(update: Apparently the TechNotes on the WSAD support page are the best place to look for issues, along with the README file of the released product.)

In the last month, as part of automating our build process, I've raised 4 bug reports on the ejbdeploy tool of WebSphere Application Server, Advanced Edition (For the interested, PMRs 49750, 55301, 55386, 55930).

49750 - opened 2004-02-19 and closed on 2004-03-05 ('corrupt' metadata files)
55301 - opened 2004-03-05 and closed on 2004-03-24 ('cmp ejb cant have a cmp field called 'value')
55386 - opened 2004-03-08 and closed on 2004-03-10 ('corrupt' metadata files)
55930 - opened 2004-03-23 (ejbdeploy doesn't include RMIC code if an ejbModule directory exists)

All of these are problems with the tool where it either fails to run to completion successfully, or runs successfully but doesn't create a correct jar.

The code can be successfully exported out of IBM WebSphere Studio AD in each case, so there's an inconsistency between the development and deployment environments.

The response from IBM on 55301 when I enquired if these would be fixed in an upcoming release was

Potential fixes for problems in WSAS 4.0.x would be evaluated and several factors will help us to make decision whether or not fixes for it would be
developed such as its prevalence, workaround availability, and if the newer releases already have fixes for them. For this particular problem we would not work on a fix for WSAS 4.0.

The end result? I've wasted days on these issues with a decision from IBM that these issues will be not be fixed in a later release.

The decision to not fix these issues mean that any other poor sucker on WAS 4.0.x is going to have to go through the same pain as I did.

It also doesn't give me a good feeling about other bugs we may pick up on the way, if they're already known about (by IBM) and I then spend days trying to work around them.

It would be much better if the list of issues and workarounds were documented so that we could easily find them, and in the case of calling a CMP field 'value' steer clear of them altogether.

Surely this would make the support team's job easier too.

On Java Tips

Elliot Rusty Harold slams the Colorado Software Summit because they allegedly ' have a reputation on being stingy when it comes to paying speakers'.

As someone who's been paid for speaking there, I found it very rewarding. Not only did I get paid for talking about technical topics, but I also got to attend a conference where I learnt a lot from people who know what they're talking about.

And I fly from Australia to go there.

There's been a call for papers for Colorado Software Summit 2004.

This year the focus is on building and deploying Web services using Java and Open Source technologies, so Apache's various projects including Jakarta should be well represented.

If you're a technical person, I'd recommend submitting a paper.

I've presented there a few times, and the conference is a "by geeks, for geeks" event, with a lot of interaction. I've gotten a lot out of the sessions I attended there, and made some good friends along the way.

Recently I've been taking our automated build process (using CruiseControl) and getting it to integrate in with WebSphere 4 AppServer.

The was40 plugin has been useful, and I've added a generate-ejb-code goal to it, which generates the code needed for the ejb jar to run in WAS.

The EJBDeploy tool in WAS is a very fragile beasty. I've had lots of NPEs due to invalid chunks of metadata in the various files WAS/WSAD uses. With some help from IBM support I've been able to identify the bad chunks and clean them up.

I'll hopefully have the generate-ejb-code goal all cleaned up and ready for general usage in the next couple of days.

Note to self: keep a list somewhere of good plugins. Add profiler to it.

This is a maven plugin that helps building netbeans modules with Maven.

It's an offshoot of the ide development work. Go Milos

The ide plugin team on Sourceforge recently announced a NetBeans module that brings code completion for:
- your project.xml file (currently POM version 3 only)
- your maven.xml and plugin.jelly files.

The 0.1 release works and was tested with Netbeans 3.5.1.
The 0.2 snapshot release works with the Netbeans 3.6 beta.

Cool.....