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.
When answering mailing list questions, I try to make sure that the documentation for the project gets updated too. But that doesn't mean that the documentation is particularly clear. If you have some ideas or changes for the docs, please leave comments on the individual page. You can reach the wiki that the website is generated from by this link. At the end of each page, there is an "add comment" link for you to make additions.
If you are having trouble with the build, a known good build set was checked in at July 1 10:00GMT. I need to make a tag in Subversion, any hints appreciated...
We had a very good meeting with a well-respected Java tools vendor last week. This was the first commercial demo of the completed Dentaku product, and the results were spectacular. While I can't go into the details of the discussions, they were very keen on the project and how we might be able to strengthen future ties between the project, especially around UML 2.0 functionality. It's exactly the kind of response that we had been expecting, and shows that the architecture of the project is on the right track with forward-thinking providers. Good stuff!
Pay no mind to what looks like stagnation, we're finishing off the unit tests before the first tag. If we are going to be TDD, then we better have unit tests to back it up. They aren't all in there now simply because we were juggling a lot of shiny balls at startup and, well, we weren't really TDD yet, I guess.
Are you interested in contributing? Sure, I know you are. Subscribe to the mailing list and start making some noise!
Things are very close to a first tagged release with Dentaku. The site is in great shape due to the ease that it was generated with Confluence and Bob's Confluenza and site layout. Maven's site:deploy worked like a champ, and the output of JavaDoc and Clover are being pushed through SSH to the server with very little work.
All I am really waiting for at this point is to push a XDoclet 1.2.2-SNAPSHOT build and it should be ready for final testing. (Note to self: remember to clean out the personal build.properties as well as removing the repository before building...)