You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Kersten <ma...@gmail.com> on 2013/10/11 21:30:04 UTC
Pro / Contra: Splitting The Project
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
Posted by Muhammad Gelbana <m....@gmail.com>.
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.mk@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 <bo...@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 <ma...@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
Posted by Martin Kersten <ma...@gmail.com>.
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 <bo...@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 <ma...@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
Posted by Borut Bolčina <bo...@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 <ma...@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
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Fri, 11 Oct 2013 16:30:04 -0300, Martin Kersten
<ma...@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Pro / Contra: Splitting The Project
Posted by Muhammad Gelbana <m....@gmail.com>.
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 <tn...@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:rhailey@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.mk@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
RE: Pro / Contra: Splitting The Project
Posted by Tony Nelson <tn...@starpoint.com>.
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:rhailey@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.mk@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Pro / Contra: Splitting The Project
Posted by Robert Hailey <rh...@allogy.com>.
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.mk@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
Posted by Jon Williams <wi...@gmail.com>.
yes i do that.
pretty standard i think.
Cheers
Jon
On Fri, Oct 11, 2013 at 1:30 PM, Martin Kersten <martin.kersten.mk@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
>