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
