You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by Maxim Solodovnik <so...@gmail.com> on 2013/08/15 05:29:47 UTC
Re: What is the reason for having a single source folder with all
Java Source files ?
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 <so...@gmail.com>wrote:
> Additionally we can use http://cxf.apache.org/ as Axis replacement
>
>
> On Fri, Jun 28, 2013 at 11:10 AM, Maxim Solodovnik <so...@gmail.com>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, seba.wagner@gmail.com <
>> seba.wagner@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 <so...@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.wagner@gmail.com <
>>>> seba.wagner@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 <so...@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.wagner@gmail.com" <
>>>>>> seba.wagner@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.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> WBR
>>>> Maxim aka solomax
>>>>
>>>
>>>
>>>
>>> --
>>> Sebastian Wagner
>>> https://twitter.com/#!/dead_lock
>>> http://www.webbase-design.de
>>> http://www.wagner-sebastian.com
>>> seba.wagner@gmail.com
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by "seba.wagner@gmail.com" <se...@gmail.com>.
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 <so...@gmail.com>
> done https://issues.apache.org/jira/browse/OPENMEETINGS-772
>
>
> On Thu, Aug 15, 2013 at 10:29 AM, Maxim Solodovnik <so...@gmail.com>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 <so...@gmail.com>wrote:
>>
>>> Additionally we can use http://cxf.apache.org/ as Axis replacement
>>>
>>>
>>> On Fri, Jun 28, 2013 at 11:10 AM, Maxim Solodovnik <solomax666@gmail.com
>>> > 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, seba.wagner@gmail.com <
>>>> seba.wagner@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 <so...@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.wagner@gmail.com <
>>>>>> seba.wagner@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 <so...@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.wagner@gmail.com" <
>>>>>>>> seba.wagner@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.wagner@gmail.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sebastian Wagner
>>>>>>> https://twitter.com/#!/dead_lock
>>>>>>> http://www.webbase-design.de
>>>>>>> http://www.wagner-sebastian.com
>>>>>>> seba.wagner@gmail.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> WBR
>>>>>> Maxim aka solomax
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sebastian Wagner
>>>>> https://twitter.com/#!/dead_lock
>>>>> http://www.webbase-design.de
>>>>> http://www.wagner-sebastian.com
>>>>> seba.wagner@gmail.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
seba.wagner@gmail.com
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by Maxim Solodovnik <so...@gmail.com>.
done https://issues.apache.org/jira/browse/OPENMEETINGS-772
On Thu, Aug 15, 2013 at 10:29 AM, Maxim Solodovnik <so...@gmail.com>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 <so...@gmail.com>wrote:
>
>> Additionally we can use http://cxf.apache.org/ as Axis replacement
>>
>>
>> On Fri, Jun 28, 2013 at 11:10 AM, Maxim Solodovnik <so...@gmail.com>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, seba.wagner@gmail.com <
>>> seba.wagner@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 <so...@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.wagner@gmail.com <
>>>>> seba.wagner@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 <so...@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.wagner@gmail.com" <
>>>>>>> seba.wagner@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.wagner@gmail.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sebastian Wagner
>>>>>> https://twitter.com/#!/dead_lock
>>>>>> http://www.webbase-design.de
>>>>>> http://www.wagner-sebastian.com
>>>>>> seba.wagner@gmail.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> WBR
>>>>> Maxim aka solomax
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sebastian Wagner
>>>> https://twitter.com/#!/dead_lock
>>>> http://www.webbase-design.de
>>>> http://www.wagner-sebastian.com
>>>> seba.wagner@gmail.com
>>>>
>>>
>>>
>>>
>>> --
>>> WBR
>>> Maxim aka solomax
>>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
--
WBR
Maxim aka solomax