woops- I did not meant to start a new thread.
My main request is to keep the struts/web gui admin stuff seperate such that it doesn't HAVE to be installed. I'm curious if the JBoss simple HTTP classloader server thingy could be used instead of tomcat where needed for the calendar protocol. Mainly with the idea that sometimes you just want calendaring and don't want to install tomcat.
I get your sentiment, for no web ui but it will be troublesome.
It can be done, the Struts UI is one war of it's own, not including in the ear is simple.
But once web ui is out there is nothing left(YET) to interact with so adding, updating, deleting calendar entries are would be out.
All the "protocols" that work are HTML/HTTP and ICalendar/HTTP. The new ones can be ICalender/SMTP, CAP/HTTP, rmi-iiop for Glow. SyncML->Sync4j installs into a webcontainer.
True the logic and the ejb's would be there but there is no client to them.
Currently the ICalendar views are the results of the same Action than the Web Caledar listing gives.
Finally, I would argue that ripping out Tomcat the webconinater from a Java Appserver is not a mainistream use. To me the beauty of this mailserver that is works in, with an application server. Tomcat/Web container also host the admin interface for JBoss, possible webmail, which granted are also not a must. I just think it is well beyond 80/20 that someone rips out the webcointaner from a Java appserver. But I could be missing something.
For HTTP based protocols why use the Classloader server over a Servlet container?
For non HTTP protocols use something else, and we would not need a web container but that is not done yet.
Here we go first week with new kids and I got into a fight again:)
Okay, the ICal stuff should be seperate from the mail stuff in teh build. Meaning I should be able to deploy mail without iCal support. JBoss doesn't always have Tomcat enabled. Its more mainstream to not use the webcontainer than you think. Just stick support in your build changes for NOT deploying the iCal stuff. Note that I don't run mail services with any more than its basic dependencies and I suspect this will be a growing concern as we move on. Anyhow, lets compromise. Just add an "all" and a "calendar" module. When we get webmail, it definitely won't always be enabled. In fact I'm considering making the webmail more or less a nukes module.
BTW argument and conflict are good. It makes each person think things through. I understand things WAY better than I did when I asked what the protocols were and stuff :-). People defend their arguments better than they explain things. So I tell all contributors to mail services to fight with me. :-)
Life is all about compromises:)
And as long you view conflict as an opportunity verus a treat we will be fine.
I pack up the hibernate beans as one jar. The ejb as another. I give you that one first.
Then pack Webui as a war and make it conditional to include it in the ear. Or figure out to make it work as a separete war and still work with the classloaders. The ejb-refs should do the magic. I will see.
Excellent. Also pay attention to source organization. If we need more directories in order to keep the build.xml simple then thats fine. maybe src/java/org/jboss/mail/calendar and src/web/org.... etc.
The project development accelerated significantly once I had people to fight with :-)