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, "[email protected]" <[email protected]> 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 > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > [email protected] >
