We don't currently use Gin, Guice, or Maven, so I can't speak to that
portion of your architecture, but the rest of your approach looks
good. I would encourage you to build up a good set of components and
utilities (what you've labeled "commons") and you might even want to
break that up.

Here's a small sample of how we've broken things up (there are 5-6
more):

edit - controls, rpc specific to editing

forms - an xml-based form generation mechanism we created

pillbox - a pillbox component we created (we'll share this eventually
in http://code.google.com/p/gwt-traction/ but it depends on other
code)

newprofile - new profile page with validation, etc. (see it live here
https://teampage.tractionsoftware.com/traction?type=newprofile)

admin - features, rpc specific to admin

traction - core set of utilities and components (like your core),
includes most of our rpc and pojos for rpc

view - a poorly named module for our main interface

We also use all of the gwt-traction code I mentioned above (like your
commons). It's where we put non-application-specific code that isn't
tightly integrated into the rest of our code.

Every module depends on our traction module. That module depends on
gwt, gwtquery, and gwt-traction and contains our i18n configuration.
It's helpful to keep these external dependencies in one place.

I realize that much of your question was around gin, guice, and maven
and hopefully someone will be able to provide some insight there.

I hope that was useful,
Andy

On Feb 28, 1:39 pm, zixzigma <[email protected]> wrote:
> Hello Everyone,
> I would like to ask your opinion on the correct way of organizing large gwt
> projects.
>
> Below you can see the approach I'm thinking of, I am not sure though,
> and greatly appreciate your invaluable input, or experience in similar
> situation.
>
> GWT documentation recommends a project structure consisting of 3 parts:
> Client, Shared, Server
>
> in addition, any application can be broken into several *Functional 
> Areas*(realizing business concepts)
> for example, an app can have Accounts, Reports, Tasks sections (aka.
> functional areas, modules)
>
> to organize our project, we can therefore break the app into: Accounts
> Module, Reports Module, Tasks Module.
>
> moreover, we would typically have a *Core module*, (one Core module for
> client +  one for Server)
> this Core module might contain our custom framework in which other *business
> related* modules can be put together(assembled) and work together to
> accomplish their goal.
>
> and we would also have a *Commons module*, which contains utility or common
> classes that other modules can use.
>
> therefore:
>
> - Functional Area 1 Module (eg, Accounts)
> - Functional Area 2 Module (eg. Reports)
> ....
> -Functional Area N Module
>
> - Core Module - Client
> - Core Module - Server
> - Commons Module
>
> Reports Module for example takes care of everything related to Reports.
> and according to GWT recommendation, we break Reports Module into
> Reports Client, Reports Shared, Reports Server sub-modules.
>
> *ReportsClient* would have its own pom.xml , Gin Module, and GWT Module
> (xx.gwt.xml)
> *Reports Server* would have its own pom.xml and Guice Module
> *Reports shared* would have its own pom.xml and would consist of interfaces
> or some static data files
>
> and similar for Accounts, and Tasks module.
>
> our Core and Commons module would have their own pom.xml
>
> we then would have an overall pom.xml which puts together all the other
> modules,
> and builts the entire app.
>
> can be summarize like this
>
> *Each Functional Area would have*
> 1- client: pom.xml +  GIN module + GWT Module (xx.gwt.xml)
> 2- shared: pom.xml (would be interfaces for client and server to
> communicate)
> 3- server: pom.xml + Guice module (contaning DAO, Service, Servlet, etc)
>
> and an overall pom.xml which puts together functional areas + core + commons
> modules (and corresponding pom.xml)
>
> - what do you think of this way of organizing projects ?
>
> - is there a direct one-to-one correspondence between pom.xml and gin/guice
> modules ?
>   in other words, is it a good idea to have a pom.xml for each of our gin
> modules, and
>   having a pom.xml for each of our guice modules ?
>
> Really appreciate your thoughts on this.
>
> Thank You

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to