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, seba.wag...@gmail.com < seba.wag...@gmail.com> 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 <solomax...@gmail.com> > >> 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, seba.wag...@gmail.com < >> seba.wag...@gmail.com> 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 <solomax...@gmail.com> >>> >>>> 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, "seba.wag...@gmail.com" <seba.wag...@gmail.com> >>>> 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 >>>>> seba.wag...@gmail.com >>>>> >>>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> seba.wag...@gmail.com >>> >> >> >> >> -- >> WBR >> Maxim aka solomax >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > -- WBR Maxim aka solomax
