Looks a lot better! Maybe we can split up some more projects into separated source folders in the future. That would help to have a better modularization.
Seb 2013/8/23 Maxim Solodovnik <[email protected]> > done https://issues.apache.org/jira/browse/OPENMEETINGS-772 > > > On Thu, Aug 15, 2013 at 10:29 AM, Maxim Solodovnik > <[email protected]>wrote: > >> I'm going to perform basic refactoring to separate tests from other >> sources. (I'll took wicket quick start project layout as an example) >> Please let me know if you have any concerns regarding that >> >> >> On Tue, Jul 23, 2013 at 11:57 AM, Maxim Solodovnik >> <[email protected]>wrote: >> >>> Additionally we can use http://cxf.apache.org/ as Axis replacement >>> >>> >>> On Fri, Jun 28, 2013 at 11:10 AM, Maxim Solodovnik <[email protected] >>> > wrote: >>> >>>> A collegue of mine told me that JAX-WS RI can be used for SOAP (I >>>> believe it is also part of TomEE) >>>> >>>> >>>> On Thu, Jun 27, 2013 at 5:15 AM, [email protected] < >>>> [email protected]> wrote: >>>> >>>>> Some comments: >>>>> >>>>> Quote: *remove *webservices* jar in favor of "TomEE like annotation >>>>> based REST/SOAP methods"* >>>>> => Does TomEE really have SOAP _and_ REST support out of the Box? As >>>>> far as I could see, from a very high level perspective, it does only >>>>> support REST but not SOAP. It would be good to maybe put a bit of time >>>>> into >>>>> analyzing that before a decision is made. >>>>> >>>>> Quote: *2) I would remove FieldLanguage* classes/dao/packages in favor >>>>> of wicket xml resource files + GUI editor (this should dramatically speed >>>>> up the app) in 5.0.0 :)* >>>>> => The motivation for have the fields in the database instead of XML >>>>> files was to speed up loading, reading them from the database is faster >>>>> then parsing XML files. If we move to wicket xml resource files, can we >>>>> re-use the existing Language-Editor or do you have to re-do that GUI? >>>>> >>>>> Thanks, >>>>> Sebastian >>>>> >>>>> >>>>> >>>>> >>>>> 2013/6/27 Maxim Solodovnik <[email protected]> >>>>> >>>>>> Hello Sebastian, All, >>>>>> >>>>>> Below are my thoughts on this topic: >>>>>> >>>>>> 1. Changes I would like to add to the packaging are: >>>>>> 1. Move html/js/css files out of the jars so users can modify >>>>>> them without repacking >>>>>> 2. remove *webservices* jar in favor of "TomEE like annotation >>>>>> based REST/SOAP methods" >>>>>> 2. I would like to have 1-2 source folder with well organized >>>>>> tree structure >>>>>> >>>>>> 1.1 above was already discussed earlier >>>>>> 1.2 I would implement it since Apache Axis seems to have no releases >>>>>> for the very long time and TomEE demo at ApacheCon was really amazing, >>>>>> REST >>>>>> services were created with few lines of code >>>>>> >>>>>> >>>>>> source code structure is not so clean in my head :( >>>>>> I believe org.apache.openmeetings should be the root :) >>>>>> >>>>>> Currently the main packages are: >>>>>> *o.a.o.data* package seems to contain beans defined in >>>>>> openmeetings-aplication.xml file >>>>>> *o.a.o.persistence* seems to contain all entities >>>>>> *o.a.o.test* test root >>>>>> *o.a.o.web* HTML5 root >>>>>> *o.a.o.utils *the root for utilities >>>>>> >>>>>> same time there are lots of subpackages named "beans" all over the >>>>>> code >>>>>> lots of util/utils subpackages >>>>>> lots of redundant packages will need to be removed in 3.0.0 >>>>>> >>>>>> What I propose: >>>>>> 1) source for the tests might be moved to separate folder to reduce >>>>>> the tree size and make "readable" it was my decision to join them :( >>>>>> 2) use "singular words" as package names: dao instead of daos, file >>>>>> instead of files, util instead of utils etc. >>>>>> 3) have "o.a.o.dao" root package with all daos >>>>>> 4) have "o.a.o.entity" root package with all entities and the same >>>>>> subtree structure as "o.a.o.dao": so if "o.a.o.dao" contains package >>>>>> "basic" the entities its working with are in "o.a.o.entity.basic" package >>>>>> etc. >>>>>> 5) have "o.a.o.dto" with the same tree structure as entity package >>>>>> 6) I prefer to have "util" packages in the subpackages it belogs >>>>>> like: "o.a.o.web.util" instead of "o.a.o.util.web" not sure if it is good >>>>>> or bad. >>>>>> >>>>>> Some global refactoring thoughts: >>>>>> 1) I would rename FlvRecording/flvrecording to Recording/recording >>>>>> 2) I would remove FieldLanguage* classes/dao/packages in favor of >>>>>> wicket xml resource files + GUI editor (this should dramatically speed up >>>>>> the app) in 5.0.0 :) >>>>>> >>>>>> >>>>>> What do you think? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jun 15, 2013 at 11:15 AM, [email protected] < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 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] >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> WBR >>>>>> Maxim aka solomax >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> http://www.webbase-design.de >>>>> http://www.wagner-sebastian.com >>>>> [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> WBR >>>> Maxim aka solomax >>>> >>> >>> >>> >>> -- >>> WBR >>> Maxim aka solomax >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > WBR > Maxim aka solomax > -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
