OK, here are some comments.
First, it is generally a bad idea to maintain the debian-specific parts inside
the upstream source. If there's a bug in the packaging part, what will you do ?
Ask upstream to release a new version just for Debian ?
The best thing to do is to maintain the package in its own repository, or its
own subdirectory, preferably a repository where I could commit, if I'm the one
signing+uploading. (I'm not sure if it's the case of svn co
http://svn.igniterealtime.org/svn/repos/). http://alioth.debian.org/ provides
Also, it usually sounds like a good idea to integrate with upstream build
scripts, but in reality, it usually causes more problems than benefits. Just
working from the released .tar.gz files works much better.
Regarding organization, I can help with the debian-specific stuff, but I would
prefer to only "sponsor" the package (double-check it, sign it, and upload it
to Debian) (I can also upload to Ubuntu). That means that one of you will be
listed as the Maintainer (others can be listed as "Uploaders", that is,
co-maintainers). That also mean that you are the ones responsible for dealing
with the bugs reported to the Debian Bug Tracking System (my Java is not very good, by the way).
Now, some comments about what you already did.
Generally, it looks very good. I like cdbs.
+ please don't integrate with upstream's build scripts (see above)
+ version should be <upstream version>-<debian version>. 3.3.1-1 to start, probably.
+ this changelog is the debian changelog: you only mark here what's specific to Debian, so no need to point to the full changelog.
+ sun-java5: can you switch to sun-java6, or would that cause problems ?
You should make it clear whether it's GPL v2 or later, GPL V2, or GPL (any version).
There are files in the archive which are not covered by the GPL. You have to list all cases in debian/copyright. There are files under LGPL, MIT and Apache 2.0, at least.
Also, we have a problem with the icons, which are non-free. Is it possible to replace them with some free icons ? If not, I'll have to ask if it's OK to distribute openfire in the "non-free" section of Debian.
Finally, some tests seem to be proprietary (see files in src/test/java/org/jivesoftware/util/ and src/test/throttletest/src/org/jivesoftware/openfire/test/throttle/).
[upstream problem] If possible, include the original text for the GPL in the archive. It makes it easier to check that it was not modified.
you use adduser, so you have to Depends on adduser.
I'm not sure I understand what's that for ?
stale file ?
Couldn't you change the install/openfire target to use an openfire.install file for dh_install instead ?
That's all for now