Here's my negative opinions (Andrew, apologies in advance, but it's a genuine set of opinions):
- This project has no planned architecture (let alone design). It desperately needs one.
- This project does not have genuine selling point other than that it is "the same old mail services only this time on JBoss" (yes, I have read "the case for mail services")
- This project is too unfocused in deployment of effort and feature delivery (for instance, the integration with Nukes bit - that's way too early to be a target)
- If I see another custom, application-specific user/group management implementation I am seriously going to scream!
- It's dangerous (even suicidal) to tie an enterprise application to tiger just yet. For most big enterprises 1.3.1 is still a "standard" JVM.
- No lessons seem to have been learned from the experience of Apache James (the big draw for me in James was the ability to write Mailets, but it failed evaluation for much the same reasons as mentioned above and that have been previously posted in this thread).
So what to do?
Scott says "step up to the wire". The question is - what's the reward for what would be a major time investment. That should be made clear first.
In the meantime, my initial feedback on the "overall vision" side would be:
- Decide first and foremost WHAT DOES THIS PROJECT GIVE AN ENTERPRISE OVER AND ABOVE SENDMAIL etc or EXCHANGE? Find the single line answer to that question that is sufficient to convince anyone whether commercial or technical.
- Focus first on user/group management and figure out how to reduce dependencies to the point where it is NOT destined to be an inextricable module of the mail services.
- Deliver the IMAP so that a webmail interface could be built.
- Steal the mailets idea from james - yes, even the source as a start point.
- Look forward a bit and realise that you must ditch ejb2 entity beans and build on ORM (hibernate) - later provide an ejb3 implementation for java 5 when people actually want it
- Drop any other integration effort for the time being
Well, that's my 20 cents.
I looked at James. Its poor work, inflexible and tied to Avalon. In short, there are no good open source Enterprise-class Java mail services to date. We've already got POP3 and SMTP. They need some fleshing out. We also are going to heavily leverage existing JBoss services in ways that would be far more difficult with JAMES. Finally, I plan to support Exchange protocol and Calendaring. If you want Mail services built on Avalon leveraging Avalon sevices, use JAMES. If you want mail services for the enterprise built on a proven enterprise platform, use JBoss.
Note by your same logic Avalon predates JBoss. ;-) I'll be publishing a document in a few days with more details.
So James is broken but it could be fixed. But I really like the idea of leveraging all the services that JBoss has in order to create a new breed of email server.
The first part of this quote is a viewpoint that I wholeheartedly disagree with (and BTW, I use JAMES as a mail server and have linked said garbage folder to /dev/null and use file based mail though its SLOW. Also note that I'm a member of the Apache Software Foundation, a [former?] committer to Cocoon [also based on avalon] and I've contributed to JAMES in the past). I am of the opinion that JAMES's problems are due to a cracked foundation. That foundation is called Avalon. I also seriously dislike a lot of the Avalon code.
The second part we agree on ;-)
So you have three options:
1. Work on JAMES to fix it and integrate it with JBoss
2. Work on Mail Services for JBoss, built on JBoss from the ground up!
3. Sit on your butt and hope one of the two achieve it