randombits-org / gwt-dispatch

Implements a reusable 'command pattern' API for GWT.
10 stars 1 forks source link

Break up the project into maven modules #28

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I would like to separate your project into separate maven modules that follow 
your package 
hierarchy (client/shared/server) so that different artifacts are created and 
contain only the 
code/source for the respective module. this would minimize the size of the jars 
and would 
further ensure that client/shared java classes are never accidentally compiled 
against server 
classes (and vice versa).

Here is a patch that includes the modifications i made to fully modularize your 
gwt-dispatch 
project.

--------------------------------------------------------------------------
the following is a list of the modifications:

1. created three maven subprojects (this includes the maven file & folder 
structures like 
src/main/java, pom.xml, etc):
gwt-dispatch-client
gwt-dispatch-server
gwt-dispatch-shared

2. changed the parent pom.xml to have a packaging of 'pom' since it is an 
aggregator project 
now

3. commented out the svn-wagon extension since it was showing as an error in 
Eclipse (not sure 
why this is which is why i just commented it out; you may want to uncomment it 
again)

4. moved all the source code out of the main projects src/main/java structure 
and into the 
respective maven submodules (this is the bulk of the patch file since moving a 
file shows as 
deleting every line in the file and re-adding every line to a new file).

i noticed that several of the "client" classes should actually be "shared" 
since the server is 
dependent on them.

for example, the "server" class:
net.customware.gwt.dispatch.server.standard.AbstractStandardDispatchServlet

implements

net.customware.gwt.dispatch.client.standard.StandardDispatchService

which is a "client" class.

the same is true of the AbstractSecureDispatchServlet and the 
SecureDispatchService

so for the StandardDispatchService and the SecureDispatchService interfaces, i 
left the packages 
the same, just simply moved the source files into the "shared" maven submodule 
which is where 
they really belong (since they are implemented by servlets and used in the 
client to GWT.create 
the async interfaces)

5. added GWT module descriptor files to the gwt-dispatch-client and 
gwt-dispatch-shared 
submodules so their jar artifacts can be "inherited" by other GWT client 
applications. these files 
are located under the submodules' src/main/resources folders.

the two files are respectively named:
GWTDispatchClient.gwt.xml
GWTDispatchShared.gwt.xml

6. added @SuppressWarnings("serial") and @SuppressWarnings("unchecked") to 
several of the 
serial classes (about 15 in total) and where unsafe casting was being done 
(less than 5 i believe) 
in order to remove all warnings from the project

7. extracted and distributed a lot of the contents of the parent pom.xml down 
into the respective 
maven submodules.
dependencies now look as follows:

gwt-dispatch-client dependencies:
-gwt-user
-gwt-dispatch-shared
-gin

gwt-dispatch-shared dependencies:
-gwt-user

gwt-dispatch-server dependencies:
-appengine
-spring-beans
-spring-web
-gwt-servlet
-gwt-dev
-guice
-gwt-dispatch-shared

additionally, the <resources> section of the gwt-dispatch-client and 
gwt-dispatch-shared 
modules' pom.xml files includes the source code so it can be compiled by the 
GWT compiler 
when these modules are "inherited" by a client GWT project

8. changed the GWT version number property in the parent pom.xml to 2.0.0 
(original value was 
1.7.1)

9. changed the maven-compiler-plugin configuration to have a source/target of 
1.6 (original 
value was 1.5)
--------------------------------------------------------------------------

to test my patch, I simply checked out the project at the command line (i'm 
running OS X snow 
leopard), imported the project into Eclipse as a maven project, then applied 
the patch to the root 
of the project. everything seems to be OK after the patch.

as a final note, I did not add the following files & directories to the 
svn:ignore lists but they 
should be added to the parent project and to each submodule sometime in the 
future:
.settings/
.classpath
.project
target/

What version of the product are you using? On what operating system?
trunk
Mac OS X Snow Leopard

Original issue reported on code.google.com by bposs...@gmail.com on 3 Mar 2010 at 8:37

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by Bitmei...@gmail.com on 4 Mar 2010 at 3:31

GoogleCodeExporter commented 9 years ago
Hi there. This looks interesting. I've scheduled it for investigation in 2.0, 
which will potentially be a big jump 
anyway.

Original comment by Bitmei...@gmail.com on 25 Apr 2010 at 2:09

GoogleCodeExporter commented 9 years ago

Original comment by Bitmei...@gmail.com on 18 Aug 2010 at 7:04