Hi Thad,
thanks for the feedback.
do you also work with maven?
In your IDE, when you have to edit a common javadev class (which is used in
GWT as well) do you have to rebuild the library (through the ant task
exposed above) in order to have the GWT project knowing about it - because
the GWT project knows only about mydb-gwt.jar dependency?
On Thursday, November 15, 2012 4:30:53 PM UTC+1, Thad wrote:
>
> I think I've a similar situation which I managed to solve without
> duplicating code.
>
> I've a large number of classes representing various database tables in a
> server app. These classes are used by a variety of applications--some
> command line, some JSP, some GWT, etc. The developement directory is
> organize like so
>
> javadev/
> database/
> build.xml
> src/
> com/
> /corp
> /database
> *.java
> lib/
> server/
> servlet-utils/
> utils/
> project-a/
> project-b/
> project-gwt/
> lib/
> database-gwt/
> build.xml
> src/
> com/
> corp/
> client/
> MyDb.java
> MyDatabase.gwt.xml
> MyDb.gwt.xml
> war/
> ...
> client-app/
> build.xml
> src/
> war/
>
> The javadev/database directory builds a JAR file used by the server and
> different projects. All classes implement java.io.Serializable and use only
> GWT serializable data types (Date, not Calendar).
>
> The javadev/project-gwt/database-gwt builds a JAR file with both *.class
> and *.java files.
>
> The MyDatabase.gwt.xml looks like
> <module>
> <inherits name="com.google.gwt.core.Core"/>
> <source path="database"/>
> </module>
>
> The MyDb.gwt.xml looks like
> <module rename-to='mydb'>
> <inherits name='com.google.gwt.user.User'/>
> <inherits name='com.corp.MyDatabase' />
> <entry-point class='com.corp.client.MyDb'/>
> </module>
>
> The MyDb.java is nothing more than an entry point to serve as a target for
> compiling the module:
>
> package com.corp.client;
> import com.google.gwt.core.client.EntryPoint;
>
> public class MyDb implements EntryPoint {
>
> public void onModuleLoad() {
> // no op
> }
> }
>
> After that, it's matter of arranging ant targets (through depends
> attributes) such that javadev/project-gwt/database-gwt/build.xml calls
> javadev/database/build.xml, then calling targets for javac, gwtc, and jar.
> The jar target collects the *.java, *.class, and *.gwt.xml files:
>
> <target name="jar" depends="javac"
> description="Package up the project as a jar">
> <jar destfile="mydb-gwt.jar">
> <fileset dir="war/WEB-INF/classes">
> <include name="**/*.class"/>
> </fileset>
> <fileset dir="src">
> <include name="**"/>
> </fileset>
> <fileset dir="../../database/classes">
> <include name="**/*.class"/>
> </fileset>
> <fileset dir="../../database/src">
> <include name="**"/>
> </fileset>
> </jar>
> </target>
>
> Now project-gwt's *.gwt.xml file includes <inherits
> name='com.corp.MyDatabase' /> and all is good.
>
> I hope this helps.
>
> On Thursday, November 15, 2012 4:00:40 AM UTC-5, Marius Grama wrote:
>>
>> On the GWT project on which I am working we have dependencies to some
>> common utility methods from libraries that are to be used by other modules
>> for their business logic in order to avoid code redundancy.
>> e.g. : the logic used for calculating a gross price based on a set of
>> given parameters (netto price, tax, promotion type) is used on the GWT
>> client side for displaying the cost information as well as on the
>> webservice side before persisting the data.
>>
>> This is the reason why we are currently defining several common libraries
>> (along with their dependencies - e.g. : hibernate) as a dependency for our
>> web application.
>>
>> One idea I have in mind to avoid the unnecessary dependencies in the web
>> application is that during the building process all the utility classes
>> from the common libraries that are neded in the GWT application could be
>> copied in another project (e.g. : my-gwt-application-utilities), and in
>> this way the GWT application to have only this project as dependency.
>> Downside is that the same code would exist in two places, upside would be
>> that the unnecessary dependencies problem would be solved.
>>
>> Projects with their dependencies before this operation :
>> *SERVICE SIDE*
>> - *mycompany.services.utilities* (java utility project)
>> - jasper
>> - *mycompany.services* (webservice project - contains among other
>> generic cost calculation methods)
>> - mycompany.service.utilities
>> - hibernate
>> - ...
>> - *mycompany.services.gen* (webservice stubs projects)
>> *CLIENT SIDE *
>> - *mycompany.mygwtapp* (gwt application communicating over SOAP/REST
>> with mycompany.services)
>> - mycompany.services
>> - mycompany.services.gen
>> - jasper
>> - hibernate
>> - ....
>>
>> If there would be the artificial gwt project created to contain the
>> common classes the project structure would look like this:
>> *SERVICE SIDE*
>> - *mycompany.services.utilities* (java utility project)
>> - jasper
>> - *mycompany.services* (webservice project - contains among other
>> generic cost calculation methods)
>> - mycompany.service.utilities
>> - hibernate
>> - ...
>> - *mycompany.services.gen* (webservice stubs projects)
>> *CLIENT SIDE *
>> *- mycompany.mygwtapp.utilities* (contains the utility classes needed by
>> mycompany.mygwtapp project copied during the build process from
>> mycompany.service.utilities and mycompany.services projects)
>> - *mycompany.mygwtapp* (gwt application communicating over SOAP/REST
>> with mycompany.services)
>> - mycompany.mygwtapp.utilities
>> - ....
>>
>>
>> This is one (maybe naive) approach on which I've been thinking to tackle
>> this issue.
>> Can anybody provide me some feedback on how they've tackled with this
>> issue (putting the utility classes in separate projects to be used by the
>> business logic and GWT wouldn't necessarily work in my case)?
>>
>>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/bnMg4SNI2eoJ.
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.
