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
Sebastian 2013/6/14 Maxim Solodovnik <[email protected]> > 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] >> > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
