openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject What is the reason for having a single source folder with all Java Source files ?
Date Tue, 11 Jun 2013 23:12:25 GMT
It is a common practise that you split up / group logical entities in
For instance, util classes normally go into a

To keep things consistent and more easy to understand for third parties you
would normally put those classes that are in different JAR packages also
then into separated source folders.

That way you can group and build modules. And for instance start defining
over which API one module communicates with another, make abstractions and
interfaces, replace code or entire jar files with different implementations.

I know that you (@Maxim :)) have been melting all together into a single
source folder some time ago.

I don't really agree with that architecture. It has a lot of issues and it
does not scale with the project size.

For instance from my point of view, the entire Wicket stuff is already in a
separated package. Why is that package not simply another source folder and
JAR file? It makes it so much more easy for anybody to read our code base.
And it is the first step into a modularization.
Compare for instance Spring: There are 10 different packages, each one
describing functionality. Not just a single JAR file. Or the Apache commons

The same could be done with the persistence package. Those are simple Beans
and JPA stuff. Theoretically the DAO's could reference different Beans and
in that way you could replace the entire persistence package with other
However the way we currently structure it, it is simply one big code
package and the abstraction into DAO, DTO, utils, Wicket-stuff et cetera is
only obvious if you work with the code for a while.

I would suggest we try to refactor that. It makes it a lot easy for new
committers to understand the code base. And I think also for us to
understand the different components.

A) What do folks think about that ?
B) What was the initial reasoning to melt it into a single source folder ?

C) What kind of packages do we currently have and which ones are
potentially candidates for a separated source and JAR packages?

My list of candidates are:
1) org.apache.openmeetings.web - Wicket stuff, source and JAR package could
be separated
2) org.apache.openmeetings.persistance.beans - OpenJPA stuff source and JAR
package could be separated
3) org.apache.openmeetings.cluster.* - Cluster stuff
4) org.apache.openmeetings.cli.* - Command line tools
5) org.apache.openmeetings.utils.* - Utils stuff
templates and axis are already separated into different JAR file. Why are
they not also a separated source folder (Why should understand this when he
compared the binary packages and the source package where those JARs are
comming from ?).

I think as we are a growing project our code base should be prepared to
grow in size. The structure as it is now, could be easily transformed into
something more structured.
And this structure would help us to identify classes that form a component
as well as new committers and 3rd parties to understand our code.


Sebastian Wagner!/dead_lock

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message