Right now in our project, we have below mentioned structure. Our project is mainly using GWT & Spring framework.
Our application.gwt.xml
contains below entry for source which needs to be coverted in to java script.
source path='client'
source path='shared'
As we are using spring at the server side, we are using spring annotation to mark the services and DAO and then in applicationContext.xml
we are using below configuration to scan the DAO and Service Layer.
<context:annotation-config/>
<context:component-scan base-package>
Now our client wants to go with below mentioned structure. Grouping everything by module. Also in our case module is not GWT module. It is just like diff. parts of the application.
My question is:
Question 1) I agree with edwardTheGreat, your initial package structure sounds perfectly reasonable. You will only have to list the client and shared packages (the ones that need compiled into javascript) in your gwt.xml file.
Question 2) If you do change the package structure, like you've mentioned, you will have to list every module's client and shared directories in your gwt.xml file. As Daniel said, you could break each module out into it's own "GWT module," and then inherit the GWT modules you need in each application module.
To achieve this, you would have to make each inherited GWT module's source available to the inheriting module. Whether you do this through Maven, Ant, etc., doesn't matter. But the top-level GWT module must have compile-time access to the source for all inherited GWT modules. For example:
<module rename-to='A'>
<inherits name='org.example.B' />
... other inherits, entry-point, etc. ...
<source path='client' />
<source path='shared' />
</module>
With this structure, module 'A' must have access to the source of module 'B'. Module 'B' can be built as you normally would a GWT module, but then, at compile-time, module 'A' must have B's source on the classpath.