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
