openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: What is the reason for having a single source folder with all Java Source files ?
Date Sat, 15 Jun 2013 04:15:03 GMT
Sure let pick up that topic once you are back.
>From my point of view it would be more simply if you have multiple source
folders and give them really self explaining names :)
However the discussion can be also split up into two points:
1) How to organize sources
2) How to organize the compiled JARs and packaging


2013/6/14 Maxim Solodovnik <>

> 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
> packages.
> 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, "" <>
> wrote:
>> 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

Sebastian Wagner!/dead_lock

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