I’ve recently had a closer insight into Openfire’s source code since I felt like contributing something (which I also did: OF-638).
However there were some inconveniences and things that made me think “WTF!?”…
The first hurdle was to get Openfire running from source. I needed to manually add a whole bunch of libraries to the classpath and
afterwards I also had to manually add the folders “i18n”, “java” and “resources/jar” to the classpath.
I also had to build the project with ANT first and then set the openfireHome variable. This is of course all explained in DOC-1020, but I think it could be easier.
I am used to Maven-structured projects, where you can just import a pom.xml file and everything else is done for you automatically by the IDE.
So my first question is, if you have ever thought about cleaning up the directory structure, i.e. using a standardized (?) structure like:
There are also some folders, which are probably no longer needed (like “resources/images-dev” or “javadoc”) and the package structure in general is too flat/unorganized for my taste.
And have you ever thought about moving to a (in my opinion) more modern build tool like Maven or Gradle?
Second question: Java EE support
Have you ever thought about using Java EE technologies or well established Java standards in general?
Especially I am thinking about:
Context Dependency Injection (CDI) (javax.inject)
Java XML Binding (JAXB) for XMPP processing. (javax.xml.bind).
Java Persistence API (JPA) for storing data (javax.persistence)
maybe even REST WebServices, e.g. for registering users.
I think by using standard technologies like that, which
a) are easier to use and maintain,
b) have wide-spread knowledge among Java developers,
c) are supported by various Java EE application servers
the Openfire project would benefit from more contributors and could be more easily used in Java EE environments (i.e. in a JBoss server).
The problem I am having with the current code base is, that most of it seems to be nearly 10 years old (according to the copyright header) or uses old technologies.
I’ve thought about contributing some more stuff, but it’s less fun working with outdated technologies.
I know, these are probably only dreams, which won’t get real in the short-term future because Openfire lacks developers.
But I’d like to hear your opinions or your vision about Openfire’s future, technology-wise.
Oh, and btw: I was suprised, that there are hardly any unit tests (only 2 for openfire package and only some more for the util package). What’s up with that?