Integration- bringing source code

[a_sogor]

The Plan:
bring over the sourcecode under the namespace:
org.jboss.calendar

what I got:
- I have 2 webapps with Struts(All config namespaces will have to change)
- One WebUI, ICalendar generation.
- One admin ui, to add users to JDBC realms.(optional)
- 1 ejb jar with XDoclet.
- 2 jar, hibernate generated source.
- One for the core.
- One for JDBC Realm.(optional)
- 1 jmx jar.

So that would create src/org/jboss/calendar:
- calendarbeans
- calendarweb
- calendarejb
- realmweb(phase2)
- realmbeans(phase2)

than maybe and etc/(dir) with the same disrectories:
- calendarbeans(for mapping file)
- calendarweb(jsp,config, ..)
- calendarejb(nothing yet)
OR user src/web
- calendarbeans
- calendarweb
- calendarejb

I looked through your build file. In addition to source code, I will change the current
build:
- Add Xdoclet.
- Add Hibernate source generation.
- Add Hibernate SQL generation.
- Add libs for Struts,Hibernate,FreeMarker (notification templates)
- Add build/gen/(module) for the generated stuff.

The other option is to rename my stuff, put it into jboss-calendar, leave my build intact, generate jars that can go under lib in jboss-mail. Or someting along these lines. It is less work and less cohesive but simple.

Any objections, suggestions, advise?

I try to finish up my release, feature complete this week or next, then start migrating, repackaging. I would like to get feedback in the begining rather than at the end :)

[a_sogor]

woops- I did not meant to start a new thread.

[acoliver]

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.

[a_sogor]

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.

Aron

Here we go first week with new kids and I got into a fight again:)

[acoliver]

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.

[acoliver]

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. :-)

[a_sogor]

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.

Aron

[acoliver]

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 :-)