openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Solodovnik <>
Subject Re: What is the reason for having a single source folder with all Java Source files ?
Date Fri, 14 Jun 2013 04:45:49 GMT
Hello Sebastian,
Sorry for the brief reply with typos (I'm from the phone)

The initial reason was to simplify the build and navigation: you open 1
folder and see all sources. I believe some classes/packages will be removed
after we will fully migrate to HTML5 (*manage* -> *dao*, *service* ->
/dev/null etc)
And the source tree will be smaller.
Additionally we currently have not very clear package structure. I would
reorganize packages to have beans and daos under the same root with less

I have no sources right now and will be able to continue this disscussion
after Jun 25, with more detailed proposals :)
On Jun 12, 2013 2:12 AM, "" <>

> It is a common practise that you split up / group logical entities in
> packages.
> For instance, util classes normally go into a
> openmeetings-utils-$VERSION.jar.
> 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
> project.
> 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 implementations.
> 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.
> Questions:
> 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
> --
> Sebastian Wagner

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