I spent a good part of last week getting DamageControl operational, as well as getting dependent projects working with it. With some regret, I still build on Windoze (I'd prefer to use a Mac G5), and DC runs on Linux, so that gives some feedback from a different build architecture. It's working great! For sure, I'm bristling in anticipation of using Continuum, but in the mean time, this works great.

I've recently been a huge fan of XDoclet2, and when confronted with some issues in the original XDoclet code recently, I decided that it was time to convert Dentaku over to see what would happen. XDoclet2 is very easy to write plugins for, and since Gentaku is based on Generama (the root module for XDoclet2), it made sense to port over to it. I'm happy to say that this conversion was a success and the fruits of that are checked into CVS.

While X2 was designed such that the metadata implementation is pluggable, the fact is that opaque Objects are returned from the metadata provider, and these Objects are cast at runtime after a bit of type checking. But that binds the generators to the QDox metadata provider. In the near future, watch this space as we refactor the existing XDoclet output modules to get their metadata information through a strongly typed interface, allowing the metadata source to be truly swappable.

Most database-driven sites that are developed with unplanned XP are a pain to unit test. Every time you add model elements, the database sample data needs to be updated to go with the changes in the model. This gets to be such a pain that (speaking for myself) I never do it. And without that deterministic sample data that the unit tests can run against, there isn't any way to know if your code is doing what you expect.

Enter a synthetic database module for Dentaku. This module reads the metadata about the generated model and creates code that will automagically create code that returns synthetic records populated with data that you can test against. In other words, you have fields with predictable values and relations with predictable counts.

It's not quite finished yet though, it turns out I broke Hibernate the other day when I put this in. But I should have that fixed soon. It would be great if we had Continuum running, that way I could get slapped every time I broke the build. Hopefully, that's ready to go soon.

Subversion is an idea who's time has come. Well, it's time had come a long time ago. It's running the repo for Dentaku, but it's entirely not ready for prime time.

Why?

While the system is stable, the clients absolutely suck. Tool vendors refuse to support it. Won't even put it on the roadmap.

That's very uncool.

Howdy folks, just checking in with recent changes to the project. I'm currently on location with a client in Tokyo, Japan.

One of the things that's been a high priority is removing AndroMDA from the build. It's a good tool, but Dentaku started using XDoclet 2 some time ago because of the difficulty with writing certain kinds of generators for AndroMDA. It initially seemed that they could be run side-by-side, but getting JMI compatible beans out of the XMI with Netbeans MDR is a very expensive operation, and doing it twice for each build is prohibitive to those without fast machines.

Chronologically, there was work done to before the first client work that would have had a version of Dentaku working without AndroMDA. But the initial client work put a stop to that due to time constraints, and the project was completed with AndroMDA. This initial version was using code checked into the build. But as the client project was finished, the then-current AndroMDA templates became harder to reverse back to use the old helper code. I had been considering using proxy wrappers for the JMI objects recently anyway, and it just made sense to pull across the AndroMDA proxy code complete.

So the current state of Gentaku is that it is very thin, and does simply uses the new Metadata Service in the Services project. The Metadata Service is a componentization of the AndroMDA proxy core, basically. I had hoped to avoid such a large import of their code, but I'm sure the XDoclet patterns in there will be useful to them if they were to choose to use them. From this point moving forward, I don't expect to see many similarities in the code bases.