Re: Pro / Contra: Splitting The Project
Hello Martin, always split your code! Of course it depends on how large the project is, but a good practice is to have separate projects for different layers. Some examples: simple scenario: myproject-web (contains the web app with majority of services and all the pages and components) myproject-persistence (contains dao interfaces, implementations and also model classes) a bit more advanced: myproject-web1 (contains the web app 1 with majority of services and all the pages) myproject-web2 (contains the web app 2 with majority of services and all the pages) myproject-web-components (contains reusable components for all web apps) myproject-persistence-api (contains dao interfaces - dao is not only a code which accesses database(s), but also solr indexes or datagrid for example) myproject-persistence (contains dao implementations and a module service to bootstrap persistence contexts) myproject-model (contains all model classes that is entities) even more advanced: add myproject-model-domain1 (model classes for domain1) myproject-model-domain2 (model classes for domain2) myproject-core (holds services and utility classes for all web apps) myproject-functional-tests (the name implies the purpose) When you have such separation you can share model classes with backend software (in which ever technology it is). You can test each layer separately. For easier installing/deploying artifacts you can cretae myproject-reactor project which only contains pom.xml to buils/install/deploy all projects. If you are serious then you must have jenkins and nexus and follow best practices of creating branches and a proper procedure to release software. There's a lot to it. Hope it helps, borut 2013/10/11 Martin Kersten martin.kersten...@gmail.com Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen
Re: Pro / Contra: Splitting The Project
Thanks for the replies, I currently split it in half. Since I use Hibernate/JPA I just split it in half having a business layer (including the so called persistence layer) and a web layer. Later on it will be joined by a project housing the rest API. And that is all necessary because Eclipse is just not good in handling package trees. Same old story for the last 10 years... . So thanks a lot for your replies. Cheers, Martin (Kersten), Germany 2013/10/13 Borut Bolčina borut.bolc...@gmail.com Hello Martin, always split your code! Of course it depends on how large the project is, but a good practice is to have separate projects for different layers. Some examples: simple scenario: myproject-web (contains the web app with majority of services and all the pages and components) myproject-persistence (contains dao interfaces, implementations and also model classes) a bit more advanced: myproject-web1 (contains the web app 1 with majority of services and all the pages) myproject-web2 (contains the web app 2 with majority of services and all the pages) myproject-web-components (contains reusable components for all web apps) myproject-persistence-api (contains dao interfaces - dao is not only a code which accesses database(s), but also solr indexes or datagrid for example) myproject-persistence (contains dao implementations and a module service to bootstrap persistence contexts) myproject-model (contains all model classes that is entities) even more advanced: add myproject-model-domain1 (model classes for domain1) myproject-model-domain2 (model classes for domain2) myproject-core (holds services and utility classes for all web apps) myproject-functional-tests (the name implies the purpose) When you have such separation you can share model classes with backend software (in which ever technology it is). You can test each layer separately. For easier installing/deploying artifacts you can cretae myproject-reactor project which only contains pom.xml to buils/install/deploy all projects. If you are serious then you must have jenkins and nexus and follow best practices of creating branches and a proper procedure to release software. There's a lot to it. Hope it helps, borut 2013/10/11 Martin Kersten martin.kersten...@gmail.com Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen
Re: Pro / Contra: Splitting The Project
What do you mean by that Eclipse is just not good in handling package trees ? *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana On Sun, Oct 13, 2013 at 3:22 PM, Martin Kersten martin.kersten...@gmail.com wrote: Thanks for the replies, I currently split it in half. Since I use Hibernate/JPA I just split it in half having a business layer (including the so called persistence layer) and a web layer. Later on it will be joined by a project housing the rest API. And that is all necessary because Eclipse is just not good in handling package trees. Same old story for the last 10 years... . So thanks a lot for your replies. Cheers, Martin (Kersten), Germany 2013/10/13 Borut Bolčina borut.bolc...@gmail.com Hello Martin, always split your code! Of course it depends on how large the project is, but a good practice is to have separate projects for different layers. Some examples: simple scenario: myproject-web (contains the web app with majority of services and all the pages and components) myproject-persistence (contains dao interfaces, implementations and also model classes) a bit more advanced: myproject-web1 (contains the web app 1 with majority of services and all the pages) myproject-web2 (contains the web app 2 with majority of services and all the pages) myproject-web-components (contains reusable components for all web apps) myproject-persistence-api (contains dao interfaces - dao is not only a code which accesses database(s), but also solr indexes or datagrid for example) myproject-persistence (contains dao implementations and a module service to bootstrap persistence contexts) myproject-model (contains all model classes that is entities) even more advanced: add myproject-model-domain1 (model classes for domain1) myproject-model-domain2 (model classes for domain2) myproject-core (holds services and utility classes for all web apps) myproject-functional-tests (the name implies the purpose) When you have such separation you can share model classes with backend software (in which ever technology it is). You can test each layer separately. For easier installing/deploying artifacts you can cretae myproject-reactor project which only contains pom.xml to buils/install/deploy all projects. If you are serious then you must have jenkins and nexus and follow best practices of creating branches and a proper procedure to release software. There's a lot to it. Hope it helps, borut 2013/10/11 Martin Kersten martin.kersten...@gmail.com Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen
Re: Pro / Contra: Splitting The Project
It's always better to start in this way and not wait for your application to get bigger and then you are forced to split it, when which you find out it's very much harder than you thought because you'll probably need to refactor a huge part of your code, since the concept of tiers or modularity wasn't enforced form the beginning. This will also prove worthy when you decide to selectively deploy specific modules for a specific client. Also when uploading your updates, you won't have to upload your whole code since you only need to upload the updated part. And don't worry about distributed configurations (plugging in services, contributing values to services while these services are about to be created/built/instantiated) since Tapestry is VERY good at this. *-* *Muhammad Gelbana* http://www.linkedin.com/in/mgelbana On Fri, Oct 11, 2013 at 10:35 PM, Tony Nelson tnel...@starpoint.com wrote: I split mine into several components Ih-db - the hibernate domain classes Ih-api - all of the business logic, depends on ih-db Web - the web site, including all of the tapestry stuff, depends on ih-api Utility1..UtilityN - command line programs that do things the system needs, these all depend on ih-api I build it all w/ a multi-project gradle build. Works very nicely. -Original Message- From: Robert Hailey [mailto:rhai...@allogy.com] Sent: Friday, October 11, 2013 4:29 PM To: Tapestry users Subject: Re: Pro / Contra: Splitting The Project The way it usually goes is a three-way split... A B (the logical split), and C (which A B both depend on). -- Robert Hailey On 2013/10/11 (Oct), at 2:44 PM, Jon Williams wrote: yes i do that. pretty standard i think. Cheers Jon On Fri, Oct 11, 2013 at 1:30 PM, Martin Kersten martin.kersten...@gmail.com wrote: Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen Since 1982, Starpoint Solutions has been a trusted source of human capital and solutions. We are committed to our clients, employees, environment, community and social concerns. We foster an inclusive culture based on trust, respect, honesty and solid performance. Learn more about Starpoint and our social responsibility at http://www.starpoint.com/social_responsibility This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Pro / Contra: Splitting The Project
yes i do that. pretty standard i think. Cheers Jon On Fri, Oct 11, 2013 at 1:30 PM, Martin Kersten martin.kersten...@gmail.com wrote: Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen
Re: Pro / Contra: Splitting The Project
On Fri, 11 Oct 2013 16:30:04 -0300, Martin Kersten martin.kersten...@gmail.com wrote: Hi, Hi! Does anyone split projects in core vs web? Hell yeah! What is the point in doing so and why not? Very simple software development rule: when something gets big, break it in smaller pieces, because it's easier to deal with smaller things than bigger ones. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Pro / Contra: Splitting The Project
The way it usually goes is a three-way split... A B (the logical split), and C (which A B both depend on). -- Robert Hailey On 2013/10/11 (Oct), at 2:44 PM, Jon Williams wrote: yes i do that. pretty standard i think. Cheers Jon On Fri, Oct 11, 2013 at 1:30 PM, Martin Kersten martin.kersten...@gmail.com wrote: Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen smime.p7s Description: S/MIME cryptographic signature
RE: Pro / Contra: Splitting The Project
I split mine into several components Ih-db - the hibernate domain classes Ih-api - all of the business logic, depends on ih-db Web - the web site, including all of the tapestry stuff, depends on ih-api Utility1..UtilityN - command line programs that do things the system needs, these all depend on ih-api I build it all w/ a multi-project gradle build. Works very nicely. -Original Message- From: Robert Hailey [mailto:rhai...@allogy.com] Sent: Friday, October 11, 2013 4:29 PM To: Tapestry users Subject: Re: Pro / Contra: Splitting The Project The way it usually goes is a three-way split... A B (the logical split), and C (which A B both depend on). -- Robert Hailey On 2013/10/11 (Oct), at 2:44 PM, Jon Williams wrote: yes i do that. pretty standard i think. Cheers Jon On Fri, Oct 11, 2013 at 1:30 PM, Martin Kersten martin.kersten...@gmail.com wrote: Hi, I am sitting in front of 1.5 MB of sources and I think about splitting the project in half. One for the services + entities + utilities the rest for the web fun. It would also allow to test the core only with unit test and barely with integration tests. Where the web part might be all about integration + acceptance testing. But I am in doubt. the only gain I would have is half the packages at once, and some separation and shift in thinking. Does anyone split projects in core vs web? What is the point in doing so and why not? Cheers, Martin (Kersten), Köthen Since 1982, Starpoint Solutions has been a trusted source of human capital and solutions. We are committed to our clients, employees, environment, community and social concerns. We foster an inclusive culture based on trust, respect, honesty and solid performance. Learn more about Starpoint and our social responsibility at http://www.starpoint.com/social_responsibility This email message from Starpoint Solutions LLC is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Opinions, conclusions and other information in this message that do not relate to the official business of Starpoint Solutions shall be understood as neither given nor endorsed by it. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
