I am not in favor of making much effort for components to support multiple versions of the Tigase server. I had a talk with Bartosz and Andrzej about separating some code (kernel API) from the Tigase server as Bot Framework (and maybe JaXMPP) uses it. So right now Bot Framework depends on the Tigase server code which is not good.

So, if we are talking about extracting some kind of general purpose API from the server for other projects to use, then yes we should do this.

Artur Hefczyc wrote:

So, if we are talking about extracting some kind of general purpose API from the server for other projects to use, then yes we should do this.

I had something slightly different in mind, but after pondering it more I realised it wouldn't work/make sense. Closing/Rejecting.

Proposal

What I have in mind is project structure similar to structure of JaXMPP:

Tigase Server Project
|- Server
|- Kernel
|- EventBus
|- Installer
\- Something Else

Why?

Because it is easier to develop some new features. For example Kernel. Now it is inside monolithic tigase-server@, and @bot have to depend on whole Server code. With modular project structure Bot imports only Kernel. If we will decide to make Kernel as separate project (for example to have platform running all our software, something like OSGi platform), it will be easy to do that: just move code from module to new repo and update dependencies in pom.xml files.

Modules are not different repos or different projects. Everything is in the same code repository, in single project. If someone does git clone https://…/tigase-server.git he will download whole code, and mvn package will build everything includes sub modules. From user side, it will looks the same.

And most important thing:

Project structure base on modules forces better code, without cyclic code usage etc.

It is easy

If we decide to make tigase-server code structure modular, we have just to move current ./src/ to (for example) ./server/src/ and update pom.xml files. If you will need to make new submodule, just do it. If you want to move some code from server code to submodule - just do it! It is not required at this time. All modules are optional if we have modules friendly project structure.

OK.

I am still uncertain whether it is better to have the Kernel as a module or as a separate project. But I like your approach. Extracting it into a module would be kind of the first step if we ever decide we need Kernel in a separate project.

Wojtek, do the honours :-)

Files moved, initial adjustment of project files done.

Reorganization pushed, still to do:

• update documentations;

• create a blog post;

• move distribution-related files and directory to appropriate module (certs, conf, etc and so forth)

Documentation updated, blog post published (http://tigase.net/blog-entry/tigase-server-project-structure-change), for now moved only win-stuff to distribution directory as it makes more sense.

Planned:

• removal of server/debian directory;

• removal of server/package-list/ directory;

%andrzej can conf contents be moved to @etc@? It's OSGi related.

From Andrzej:

Quite possibly

http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-usage-documentation.html

section Configuring the Framework

java -Dfelix.config.properties=file:/home/rickhall/config.properties -jar bin/felix.jar

so we would need to adjust tigase.sh

I went ahead and removed server/debian and server/package-list/ directories; OSGi configuration file was moved under server/etc (and shellscripts were updated).

Jenkins was updated to accommodate the changes.

I consider the task to be completed.

%Bartek can now work on extracting needed modules: kernel, dsl, eventbus(?!) and others as needed.