I'm a bit slow on this one, but Anthony Eden has reacted to some of my earlier comments on JPublish by publicly mulling over his plans for 2.0. He's going to come up with an architecture for storage, something it lacks now, and hopefully a way to get content into the system. He's also thinking about what modules it needs.

JPublish's model for finding data, templates, and meta-data is very nice, but there are no tools for entering any of these things, other than by plopping them into the file system. That's the best way to manage data as files, since there are plenty of tools available. But for those who want to keep a lot of content in a database, we need some tools to manage that content.

One thing that will be interesting to see is whether Anthony moves over to a JPublish-based blog package at some point. He's a big booster of Roller, which looks like it is on the way to becoming a primo Java blogging package, but JPublish would be a good platform to build a blog/wiki/forum type thing on top of, something like what Russell has been talking about. Of course Roller is here now and rapidly being improved by a community, and I haven't seen any momentum for building something like it on JPublish, so I guess it's a wheel thing.

One thing Anthony mentioned as a goal for JPublish 2.0 is:

In general I am going to try to factor out as many of my own components as possible and start using other peoples components so that I can focus on items which are really important in JPublish such as the repository system.

This is one of the reasons I decided* not to use Cofax: it implements its own database persistence, templating, and pretty much everything else, and IMO spreading development effort over so much shows in that each of these is mediocre when compared with components available off the shelf, such as Velocity, OJB, WebWerk, etc. There are some things I like about Cofax, in particular the way it finds page templates is brilliantly flexible. But I decided that refactoring Cofax's framework to implement standard components would be more work than reimplementing its clever bits on another framework.

(* Back when I was looking to get into CMS consulting, which it doesn't look like I'll be doing after all)