You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openmeetings.apache.org by "seba.wagner@gmail.com" <se...@gmail.com> on 2013/06/12 01:12:25 UTC
What is the reason for having a single source folder with all Java
Source files ?
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
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
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by Maxim Solodovnik <so...@gmail.com>.
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 Maxim Solodovnik <so...@gmail.com>.
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
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by Maxim Solodovnik <so...@gmail.com>.
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" <se...@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
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Thanks for the comments Sebastian,
It is like "far far away" ideas :)
1) is in my mind because I really like annotation based code since it is
very compact and self descriptive. Additionally we currently have "General
servlets", "Velocity servlets", "String controllers" and Wicket in our
stack seems to be too much :)
2) My idea was based was based on the fact Wicket has native support for
XML based language files and the only things need to be changed are:
1) replace number id with self descriptive label
2) replace WebSession.getString with getString("name") //there is an
option also to have strings with placeholders
pros are:
1) redundant strings can be removed (I expect ~50% of strings are
redundant)
2) Wicket will automatically use English strings if localized is not
provided
3) All strings are available before installation (installer can be
localized as all other modules)
4) Installation will perform faster
cons are:
1) this is huge refactoring affecting everything
2) editing of string will be slower (not very major issue since only
admins can edit the strings, and I believe not very often)
I believe the GUI can easily be reused since the only thing need to be done
is: DAO working with DB should be replaced with DAO working with file :)
I'm still not sure if such changes worth to be implemented :(
Will try to finish 3.0.0 first then get back to this :)
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" <se...@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
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>.
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" <se...@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
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by 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" <se...@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
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>.
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" <se...@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
Re: What is the reason for having a single source folder with all
Java Source files ?
Posted by 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" <se...@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
>