How To Include External Classes On The Client Side?

[gazarcher]

Hello,

I am a new member of this discussion group, but I have searched for an
answer to my question in previous posts without finding what I want.

When I first started using GWT a couple of months ago, adding a small
module inside of a larger application, I found it annoying that I
couldn't include model classes from outside the module on the client
side because they were not known by the JRE emulator. I ended up
creating duplicate (or similar) model classes on the client-side and
copying data from my original models into them on the server-side.

As I learnt more about GWT at first I thought the <source
path="somepackage"/> in the gwt.xml file was the answer to my problem.

For example, if I had a package structure that began with things like
(names changed to protect the guilty):

com.abc.common
com.abc.myapp

and my GWT module had a package structure like:

com.abc.myapp.admin.usermanager

As you can see, I can use my "external" class called
com.abc.myapp.model.User
in my GWT module server-side class called
com.abc.myapp.admin.usermanager.server.UserManagerServiceImpl, but I
cannot use my "external" class in my GWT module client-side class
com.abc.myapp.admin.usermanager.client.ui.UserManagerPanel, even if
com.abc.myapp.model.User implemented the IsSerializable interface, the
GWT compiler would complain about it ("cannot be resolved as a type").

So, I created a model subpackage in
com.abc.myapp.admin.usermanager.client and in my GWT module server-
side class I copy data from my "external" class into a "duplicate" GWT
module client-side class called
com.abc.myapp.admin.usermanager.client.model.UMUser.

Everything all works, but in my opinion it's clunky and inefficient
when I have two model classes to transport the same data.

So, I've been trying to figure out a way to reference those external
classes on the client-side of my GWT module.

At first I thought <source path="com.abc.myapp"/> (or just <source
path="com.abc"/>) would fix it, because when I try this the GWT
compiler no longer complains that my external classes cannot be
resolved. Instead, the GWT compiler can no longer find my CSS files
or my entry point class! Even if I added <source path="client"/> (or
even <source path="com.abc.myapp.admin.usermanager.client"/>), I still
get the same errors.

Yes, I already know the problem... I finally realised <source
path="blahblahblah"/> is only intended for subpackages of the client
package in the GWT module! But, I was at a point where I was
literally trying everything...

And before you say it :-), no, I don't want my external classes inside
of another GWT module so that I can inherit them. Those classes have
to stay independent of GWT (so, I shouldn't even be tempted to make
them implement the IsSerializable interface anyway!).

Perhaps I could create empty model classes in the GWT module client-
side that extend the original, external model classes, but now
implement the IsSerializable interface. But, I still have the problem
of getting my GWT module to recognise the external classes on the
client-side.

Anyway, this is a rather long post, but I was hoping someone would
know what the heck I was babbling on about and could postulate a
solution. Or, is what I'm already doing (copying, or mapping, the
models) the best I can do for now (perhaps until the GWT team resolves
this dilemma)?

Many thanks in advance.

Cheers,
- Garry Archer

[teerapong]

I also appreciate if GWT team will help invent the way to get rid or
reduce such a model class "duplication" pain.
In fact, it is general problem (or general task, if someone don't
think it's a problem) for server-client software development.
I may have my service return result in XML format and when client got
that result it read data by XML parser and go on working. This kind
can not use advantage of compile-time checking and bring much lines of
code lead to complication. GWT way of RPC seem to help life easier.
But with its limitation stated above by first poster, I think so much
people can not adopt GWT RPC. Because if one decides to use GWT RPC I
know noway to avoid duplicating class model 1 for server an 1 for
client, how much pain when classes are changed, package renamed, ....
and so on, especially for big application. (Apologize if someone not
clear in any part of my phrase, I'm not so good in English)

[Ian Bambury]

try 'inherits' and not 'source' for the external module, plus you'll need an external.gwt.xml file for it, and a reference to it in the class path

--
Ian
http://examples.roughian.com

[charlie...@gmail.com]

You can inherit other modules, as Ian notes. I use that all the
time. In fact, I normally break projects up into client - model -
server. All separate modules. (We have different teams working on
client and server, for example, this helps to separate things
logically, and it helps with deployment and other stuff too.)

With GWT 1.4 the DTO effort (duplication of "model" beans) is reduced
somewhat, but not entirely gone - depending on what you use for your
regular server side model. You can now use "Serlializable" as a
translatable maker interface, rather than IsSerializable, that helps.
However, you will still have DTO and mapping (client model to server
model), if you have anything else that wont translate in your server
side model (annotations for JPA, HashCodeBuilder or ToStringBuilder
that use non translatable stuff, so on).

[gazarcher]

Ian,

Thank you for your response.

Unfortunately, as I outlined in my original post, the external classes
are not in a GWT module and never will be, they are totally
independent. Therefore I am unable to inherit them.

I wonder, however, if I could put a gwt.xml file in at the root
package of my external classes and use <source path="com.abc"/> in
there, and then inherit this gwt.xml file as if it was a module?
But, I would still have the problem that my external files are not
translatable without them implementing the IsSerializable interface
which I am not allowed to do.

I think I'm stuck with the copying/mapping model class solution. At
least until the GWT team fix this.

Cheers,
- Garry

On Jun 28, 4:47 am, "Ian Bambury" <ianbamb...@gmail.com> wrote:
> try 'inherits' and not 'source' for the external module, plus you'll need an
> external.gwt.xml file for it, and a reference to it in the class path
>
> --
> Ianhttp://examples.roughian.com
>

[gazarcher]

Charlie,

Thank you for your response.

As I just replied to Ian, unfortunately the external classes are not

in a GWT module and never will be, they are totally independent.
Therefore I am unable to inherit them.

I haven't downloaded GWT 1.4 and won't until it is finally released,
but if my external classes only need to implement Serlializable and
not IsSerializable, I wonder if the idea I postulated in my reply to
Ian might work (Putting a gwt.xml file in at the com.abc package --
which is not a GWT module -- and inheriting this file in proper GWT
modules)?

Cheers,
- Garry

On Jun 28, 8:08 am, "charlie.coll...@gmail.com"

[BioInfoGuy]

Garry,

You might look at the gwt-maven project at http://code.google.com/p/gwt-maven/
. They have a generateBean... goal written that might do the trick.
I've had some issues with getting it to work in all cases, but it's a
start. Both this solution, a Spring solution and a mention of Dozer (a
sourceforge bean mapping library available at http://dozer.sourceforge.net/)
are described in some detail in a book I've been consulting called GWT
In Practice (http://www.manning.com/cooper/). The book is in pre-
publication state right now, but you'll get a copy if you want one if
you purchase the early-access version. The book is pretty good, but
very dense.

For the record, I have no vested interest in selling the book, though
I am participating with the gwt-maven project - also a work in
progress.

Jason

[charlie...@gmail.com]

Garry, I understood from your original post that your classes are
"independent," but I guess my response was muddled.

If you want to use classes with GWT, on the client, they have to be
translatable and have to be part of SOME GWT module somewhere. You
can either include them directly, or inherit them. I find inheritance
to be much cleaner and easier. I typically have a "client" module, a
"model" module, and a "server" module, all separate.

In my "model" module I use beans that are "Serializable" (with GWT
1.4, can avoid IsSerializable), but these are still not non GWT beans.
As you have noted, it does seem a bit clunky to require the DTO layer,
but that is simply life with GWT (at least at present).

Stuff has to be translatable. Now, if your model beans otherwise meet
the GWT translatable requirements (no args ctor, based on the GWT JRE
emul library, implement Serializable, dont have any Java 5 stuff,
etc) then you can re-use them simply by making them a module, yes.
But in 98% of cases your existing server side model beans will not
meet these requirements.

The gwt-maven project and the BeanGenerator (as BioInfoGuy notes) was
created to help alleviate this (I am one of the project owners, but
Robert Cooper build the bean gen stuff, props to him), but whether you
do it with generation, by hand, whatever, it does have to happen.

(P.S., I am also one of the authors of GWT in Practice that BioInfoGuy
notes - it has a lot of info on this topic, and we are working on
ironing out the "density." What is on MEAP right now should be updated
soon, we are in final review now and that current content is from an
initial draft. Disclaimer: I DO have an interest in selling the
book ;) .)

[Richard Bondi]

The JDK classes are as external to a GWT module as gazarcher's
external classes are: how does the GWT compiler not reject them, and
how can we use the same trick to solve gazarcher's (and my) problem?
/r:b:

On Jul 1, 9:07 pm, "charlie.coll...@gmail.com"

<charlie.coll...@gmail.com> wrote:
> Garry, I understood from your original post that your classes are
> "independent," but I guess my response was muddled.
>
> If you want to use classes with GWT, on the client, they have to be
> translatable and have to be part of SOME GWT module somewhere. You
> can either include them directly, or inherit them. I find inheritance
> to be much cleaner and easier. I typically have a "client" module, a
> "model" module, and a "server" module, all separate.
>
> In my "model" module I use beans that are "Serializable" (with GWT
> 1.4, can avoid IsSerializable), but these are still not non GWT beans.
> As you have noted, it does seem a bit clunky to require theDTOlayer,
> but that is simply life with GWT (at least at present).
>
> Stuff has to be translatable. Now, if your model beans otherwise meet
> the GWT translatable requirements (no args ctor, based on the GWT JRE

> emul library, implementSerializable, dont have any Java 5 stuff,

> > > With GWT 1.4 theDTOeffort (duplication of "model" beans) is reduced

> > > somewhat, but not entirely gone - depending on what you use for your
> > > regular server side model. You can now use "Serlializable" as a
> > > translatable maker interface, rather than IsSerializable, that helps.

> > > However, you will still haveDTOand mapping (client model to server

[Richard Bondi]

Also, consider what the GWT team said about introducing Serializable
support (emphasis added by me):

<ul>
http://code.google.com/webtoolkit/releases/release-notes-1.4.10.html

Serializable equivalent to IsSerializable

Although GWT's RPC mechanism doesn't purport to honor the semantics of
Java serialization, by popular demand, Serializable and IsSerializable
are now equivalent for the purposes of RPC. This should improve
<b>server-side interoperability</b> and <b>remove much of the need for
DTOs</b>.
</ul>

Surely what was meant by "server-side interoperability" was using
external classes with GWT servlets; and surely what they meant by
"remove much of the need for DTOs" is precisely what gazarcher (and I)
are trying to do: stop writing @#$%!! mappers to map from external
classes to isSerializable classes, and instead finally (finally!) load
up Serializable external classes (externally) with data, and inject
them directly into the GWT servlet.

Hopefully we are missing something here: what else is the new support
for Serializable for except this?

Hopefully,
/r:b:

[Isaac Truett]

I'm not entirely sure what the problem here is. I'm going back to
gazarcher's original post and addressing his error message. If that
has already been resolved, feel free to ignore me and carry on...

> the GWT compiler would complain about it ("cannot be resolved as a type")

GWT needs access to your source code. By default, it looks in the
client directory under the directory in which your module xml resides.
Example:

com/abc/myapp/MyApp.xml
com/abc/myapp/client/MyClientCode.java

In this case, GWT will compile and be able to resolve references to
MyClientCode. As I understand things, you want GWT to compile code in
com/abc/common. This directory is next to com/abc/myapp, not under it.
That's why it can't be resolved. Adding <source
path="com.abc.common"/> doesn't work, because the path isn't relative
to the location of MyApp.xml.

You have several options, two of which are moving the common package
and defining a module in com/abc.

Option 1:
Step 1. Move com/abc/common to com/abc/myapp/common.
Step 2. Add two <source> entries to MyApp.xml:
<source path="client" />
<source path="common" />

Option 2:
Step 1. Create Common.xml in com/abc with <source path="common" />
Step 2. Add <inherits name="com.abc.Common" />

(I haven't actually compiled either of these examples, but the
concepts should be accurate)

Does that clear up anything at all?

[Richard Bondi]

That's definitely helpful and makes things clearer.

My issue is this. All my domain models are in com.foo.model. My GWT
modules are in com.foo.gwt.module.

I would like to load some of my domain model (com.foo.model.*) classes
into a GWT-generated page.

What I would like to do is simply have those models implement
Serializable, inject them via IoC into my RemoteServlets, and RPC them
into the GWT page. In my gwt client code, I would simply cast what was
returned by the RPC call to com.foo.model.MyModel. But that won't
compile.

So what I have to do all the time instead is this:
- in my gwt client package, declare DTO classes, eg MyModelDTO
- in my gwt server package, make a Mapper class that maps MyModel to
MyModelDTO classes (and vice versa)
- RPC the MyModelDTO classes back and forth in GWT.

That's a big pain (although good practice when certain models need
protecting).

My interpretation of GWT making Serializable with isSerializable was
to relieve programmers of this DTO step. I thought it meant, "Just
sprinkle Serializable fairy dust on any non-GWT class, keept it jdk
1.4 and GWT compiler compliant etc etc, and you can RPC it -- no more
DTOs." Was I wrong?

Do you see a way I can use Serializable in this way?

See also http://tinyurl.com/2ewoc6 for more detail on how I develop
with these dtos.

Thanks much,
/r:b:

[Isaac Truett]

There are actually two separate issues here. One is making a Java
class visible to the GWT compiler and the other is making it
serializable. A class can actually be one, or the other, or neither,
or both. It sounds like your classes are serializable but not visible
to the GWT compiler.

Your solution works because the regular Java compiler, javac, can
compile anything on your classpath. The GWT compiler needs a little
more help. That's where the <source> tags come in. GWT will only try
to compile code that exists in a package that is specified in a
<source> tag (or the default <source path="client"> if you didn't
specify a <source>). To load classes from your com.foo.model package,
you need a GWT module that specifies that package in a <source> tag.
That module doesn't need an entry point or any web-related code. It
just needs to be a marker telling GWT that it's okay to compile this
package. You can then inherit that common module in your client
module. This is how third-party GWT libraries are created.

The problem with IsSerializable is that people in situations such as
yours might not be allowed/able/willing to modify the source code for
their data model. Now, if those model classes meet all of the other
criteria for GWT serialization, GWT will consider Serializable the
same as IsSerializable (but will NOT honor the usual Java contract
implied by Serializable). Serializable/IsSerializable does NOT remove
the requirement of a <source> tag identifying the code as
GWT-compilable.

So, no, you're not wrong about Serializable being a replacement for
IsSerializable. You just need to meet all the other requirements that
an IsSerializable class would meet.

[Que_genio]

Hi Isaac,

I'm pretty much in the same case as the previous posts dudes...
I have loaded the GWT classes into Eclipse (or better said RADv6.0) so
I have one single project for the GWT client and server, and I have
another project for Hibernate project to handle the model.

I downloaded yesterday the 1.4.10 release and just finished the
migration, I just have removed all the DTOs and model duplicated
classes and now I'm trying to make GWT to recognize the Hibernate
objects directly.

My model layer has nothing but plain data, int, String, boolean,
java.util.Date, etc; so nothing spectacular or agains Serialized
concept of GWT so I was hoping to be able to send this same objects
directly to the GWT.

I read your previous post, and I was wondering do you have an example
of how to write this gwt.xml thing, or where should I place it on my
directories, I have an structure similar to:

(GWT project)
CmmiWebApp
+com.kick.whatever.client.CmmiMgr
+com.kick.whatever.server.ProvidingServlet

(Hibernate Project)
+com.kick.whatever.else.model.ReleaseRequirement
+com.kick.whatever.else.model.Requirement

This peoject are separate projects in Eclipse and I link them by the
build path, but of course my problem is that de GWT compiler can't
find them

So do you have any example or how to modify my gwt.xml?

Thanks.

On Jul 9, 9:24 am, "Isaac Truett" <itru...@gmail.com> wrote:
> There are actually two separate issues here. One is making a Javaclassvisible to the GWT compiler and the other is making it
> serializable. Aclasscan actually be one, or the other, or neither,

> or both. It sounds like your classes are serializable but not visible
> to the GWT compiler.
>
> Your solution works because the regular Java compiler, javac, can
> compile anything on your classpath. The GWT compiler needs a little
> more help. That's where the <source> tags come in. GWT will only try
> to compile code that exists in a package that is specified in a
> <source> tag (or the default <source path="client"> if you didn't
> specify a <source>). To load classes from your com.foo.model package,
> you need a GWT module that specifies that package in a <source> tag.
> That module doesn't need an entry point or any web-related code. It
> just needs to be a marker telling GWT that it's okay to compile this
> package. You can then inherit that common module in your client
> module. This is how third-party GWT libraries are created.
>
> The problem with IsSerializable is that people in situations such as
> yours might not be allowed/able/willing to modify the source code for
> their data model. Now, if those model classes meet all of the other
> criteria for GWT serialization, GWT will consider Serializable the
> same as IsSerializable (but will NOT honor the usual Java contract
> implied by Serializable). Serializable/IsSerializable does NOT remove
> the requirement of a <source> tag identifying the code as
> GWT-compilable.
>
> So, no, you're not wrong about Serializable being a replacement for
> IsSerializable. You just need to meet all the other requirements that

> an IsSerializableclasswould meet.

>
> On 7/8/07, Richard Bondi <rbo...@gmail.com> wrote:
>
>
>
> > That's definitely helpful and makes things clearer.
>
> > My issue is this. All my domain models are in com.foo.model. My GWT
> > modules are in com.foo.gwt.module.
>
> > I would like to load some of my domain model (com.foo.model.*) classes
> > into a GWT-generated page.
>
> > What I would like to do is simply have those models implement
> > Serializable, inject them via IoC into my RemoteServlets, and RPC them
> > into the GWT page. In my gwt client code, I would simply cast what was
> > returned by the RPC call to com.foo.model.MyModel. But that won't
> > compile.
>
> > So what I have to do all the time instead is this:
> > - in my gwt client package, declare DTO classes, eg MyModelDTO

> > - in my gwt server package, make a Mapperclassthat maps MyModel to

> > MyModelDTO classes (and vice versa)
> > - RPC the MyModelDTO classes back and forth in GWT.
>
> > That's a big pain (although good practice when certain models need
> > protecting).
>
> > My interpretation of GWT making Serializable with isSerializable was
> > to relieve programmers of this DTO step. I thought it meant, "Just

> > sprinkle Serializable fairy dust on any non-GWTclass, keept it jdk

> > 1.4 and GWT compiler compliant etc etc, and you can RPC it -- no more
> > DTOs." Was I wrong?
>
> > Do you see a way I can use Serializable in this way?
>

> > See alsohttp://tinyurl.com/2ewoc6for more detail on how I develop

[Isaac Truett]

http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.Fundamentals.Modules.ModuleXml.html

Also have a look at the Kitchen Sink and any of the other samples;
those all have gwt.xml files you can copy for a start.

[Richard Bondi]

Thanks, Isaac.

This doesn't quite solve the problem, I think. The <source> tag is all
or nothing: *all* your client files have to be in the package it
specifies. I want most of my files in "client", and just some of them
(like domain model classes) in a different package.

Do you know how to have the GWT compiler compile files from more than
one package?

I tried this without success:

- create module DTO, and gave DTO.gwt.xml a <source> pointing to
com.foo.domain.model, and no entry point.
- had module GUMBY inherit module DTO, and used
com.foo.domain.model.MyClass in one of GUMBY's client classes.

The GWT compiler said it couldn't locate com.foo.domain.model.MyClass.

Any ideas?

Thanks,
/r:b:

> > See alsohttp://tinyurl.com/2ewoc6for more detail on how I develop

[Isaac Truett]

On 7/12/07, Richard Bondi <rbo...@gmail.com> wrote:
>
> Thanks, Isaac.
>
> This doesn't quite solve the problem, I think. The <source> tag is all
> or nothing: *all* your client files have to be in the package it
> specifies.

Not true. You can have multiple <source> tags and you can also inherit
from other modules.

> I want most of my files in "client", and just some of them
> (like domain model classes) in a different package.
>
> Do you know how to have the GWT compiler compile files from more than
> one package?
>
> I tried this without success:
>
> - create module DTO, and gave DTO.gwt.xml a <source> pointing to
> com.foo.domain.model, and no entry point.

You don't put full package names in the source path. If you have
com/foo/domain/DTO.gwt.xml then you would put <source path="model" />
to have GWT compile the com.foo.domain.model package.

[Richard Bondi]

OK, I got the inheriting method to work now, for which many many many
thanks. But I still can't figure out how to do this with just one
module and <source>.

So for the record, I got the following to compile: a GWT client object
that uses an interface from com.foo.domain.model, using <inherits> and
a second module MODEL.gwt.xml:

[src]
|- [com]
|- [foo]
|- [domain]
| |- [model]
| | |- Order.java (Interface)
| | |- OrderImpl.java
| |- MODEL.gwt.xml
|- [gwt]
|- [module]
|- [uo]
|- [client]
| |- UO.java (implements Order Interface)
| |- UOService.java (I)
| |- UOServiceAsync.java (I)
|- [public]
|- [server]
| |- UOServiceImpl.java
| |- UOStub.java (returns Order objects)
|- UO.gwt.xml

MODEL.gwt.xml contains:
<source path="model"/>

UO.gwt.xml contains:
<inherits name="com.foo.domain.MODEL"/>

So my remaining question is: how could I do this without a
MODEL.gwt.xml, just using UO.gwt.xml and <source> tag(s)?

TMIA again,
/r:b:

[Isaac Truett]

On 7/12/07, Richard Bondi <rbo...@gmail.com> wrote:

> So my remaining question is: how could I do this without a
> MODEL.gwt.xml, just using UO.gwt.xml and <source> tag(s)?
>
> TMIA again,
> /r:b:

I'm glad you got it working. To answer your question: you can't.
<source> can only reference paths relative to the gwt.xml file's
location and it can't go backwards (e.g., ../../). Your gwt.xml would
have to be in com.foo to include both com.foo.domain.model and
com.foo.gwt.uo.client. Now, I'm not saying one way or the other
whether I think this is the right way to do things, just that this is
the way it is. I'm sure the GWT team has very good reason to attach
such significance to the location of the gwt.xml file. I just don't
know what the reasons are.

[Richard Bondi]

Isaac, this is fabulous, thank you. Your posts here ought to get a
five star rating from everyone. A big DTO/GWT problem has been solved.

My parting (IMHO) thoughts on eliminating DTOs this way:
1) It's going to be rare that model objects are amenable to this,
since they will often contain or object graphs, and so either are
unserializable, or the graphs cannot be flagged "transient".
2) It's worth doing if it is faster than running a mapper. For
example, a hibernate named query could return model objects for RPCing
directly, thus skipping the step of mapping them to RPC-able DTOs.
3) It may also be worth doing to avoid overly complex, tedious
mappers.
4) One should always weigh the danger that such model objects could be
"writable" when they should only be readable. DTOs help prevent
"writing accidents".

Best,
/r:b:

[Caleb]

Isaac,

Thanks very much for your informative posts. I have been following
this discussion with interest. However, I have encountered an import
error that I can't seem to resolve.

I have a package structure like this:

a.b.c.d.client
a.b.c.d.model
a.b.c.d.model.bean

There is a module called "GWTApp.gwt.xml" defined in package a.b.c.d:

<module>
<inherits name="com.google.gwt.user.User"/>
<entry-point class="a.b.c.d.client.GWTApp"/>
<source path="client"/>
<source path="model.bean"/>
<servlet path="/appService" class="a.b.c.d.server.AppServiceImpl"/
>
</module>

The interface a.b.c.d.client.AppService imports
a.b.c.d.model.bean.Document.

When I run the GWT compiler, I get the following ouput:

[ERROR] Errors in '.../a/b/c/d/client/AppService.java'
[ERROR] Line 5: The import a.b.c.d.model.bean cannot be resolved

I think that I'm doing all the things you have mentioned so far. Can
you see what my problem is, or do I need to provide you with more
information?

Thanks,

Caleb

[krispy]

Use directory paths, not package names:

<source path="model/bean"/> or <source path="model\bean"/>, I'm not
sure which one GWT prefers. Either way, you should probably just put
<source path="model"/> and be done with it, since GWT will look
recursively through directories (and since you'll probably end up
putting something in /model anyways). Does that fix it?

-krispy

[mP]

Personally i would create three projects

The first is your client project, the second your "shared components"
this includes stuff like model, exceptions that cross the bridge
between client and server. THe third and last project is your server
project.

Both the client and server projects reference the shared components
project. Naturally both your client and shared components include
their own *.gwt.xml, with the client project also referencing the
shared comp module.gwt.xml.

hth

mP

[Caleb]

Krispy,

That does work, thanks. Of course, I forgot that all our model beans
are annotated up the wazoo as JPA entities. So it was a moot point,
after all.

mP,

We are actually in the process of pulling our model code out into a
separate project, and will probably do the same with the client and
server stuff. This is our first attempt at incorporating GWT, so we
have some adjustments to make. Thanks for the suggestions.

Caleb

[gazarcher]

Hello everybody, and thank you for continuing the discussion.
Unfortunately I couldn't be involved with it for a few weeks because
right in the middle of it I had to return home to England for a family
emergency. In any case, after returning and getting back up to speed
with my projects and this GWT problem, I tried the solution Richard
Bondi posted on July 12th at 1:35 PM which worked for him.

So, like Richard, I created a module called Model.gwt.xml in my src/
com/abc/common/model directory. It's entire contents were:

<module>
<source path="model" />
</module>

I then compiled this module successfully (I use IntelliJ IDEA which
has a GWT plugin).

Next, in my application specific GWT module called MyApp.gwt.xml in my
src/com/abc/def/ghi/myapp directory, I added the line:

<inherits name="com.abc.common.model.Model" />

Then I compiled this module, also successfully.

At this point, my understanding is that the MyApp GWT module now knows
about the interfaces and classes in my com.abc.common.model package
and any subpackages since those interfaces and classes should now be
on the MyApp GWT module's classpath.

Next, I edited one of the classes in the MyApp GWT module client to
reference my interfaces and classes in my com.abc.common.model
package. For example:

src/com/abc/def/ghi/myapp/client/model/impl/FooModel.java now includes
this import:

import com.abc.common.model.Bar; // an interface from my common
models package

and I have a new class attribute and new class method:

private Bar bar;

public void setBar( final Bar barIn )
{
bar = barIn;
}

IntelliJ immediately complains, "Class 'com.abc.common.model.Bar' is
not presented in JRE Emulation Library so it cannot be used in client
code'

Even if I compile the MyApp GWT module I get compiler errors:

"The import com.abc.common.model cannot be resolved"
"Bar cannot be resolved as a type"

So my client code is *STILL* not seeing my common model classes from
outside of the application specific GWT module. I thought I followed
Richard's example almost exactly, yet I still seem to be doing
something wrong or missing something.

Any help is appreciated!!!

Cheers,
- Garry Archer

[Isaac Truett]

That's a problem with IntelliJ, not GWT. Is there a place in your
plugin to add inherited modules?

[Isaac Truett]

Oh, Model.gwt.xml should be in com/abc/common not com/abc/common/model
unless your java package is com.abc.common.model.model.

[gazarcher]

Well, I think I answered my own question.

It didn't make any sense to me to have my Model.gwt.xml file inside
the src/com/abc/common/model directory. The source path entry was
pointing to a "model" package (or directory) and that did not exist in
the src/com/abc/common/model directory. I misinterpreted Richard's
directory diagram. The Model.gwt.xml file must be moved up one level
to src/com/abc/common. Now the source path entry makes sense, since
the "model" directory exists in src/com/abc/common.

After changing

<inherits name="com.abc.common.model.Model" />

to

<inherits name="com.abc.common.Model" />

in my MyApp.gwt.xml file and then tried to compile everything I can
now see the GWT compiler attempting to compile the interfaces and
classes in the src/com/abc/common/model directory and subdirectories.
Finally!

BUT!

The classes were written with Java 1.5 or above in mind and the latest
GWT uses Java 1.4, so GWT is complaining about Java 1.5 features, "GWT
does not yet support the Java 5.0 language enhancements; only 1.4
compatible source may be used" Additionally, the GWT compiler cannot
resolve many types used in those classes, for example,
java.util.Calendar or java.util.TreeMap, or it cannot resolve some
methods like getClass() inherited from java.lang.Object. In fact, I
ended up with 492 compiler errors, which is no trivial thing to fix
just to make GWT work with classes outside of GWT modules.

So, it looks like I'm pretty much back to square one with mapping data
from the server side to be used on the client side (having near
duplicate models in order to display data).

If GWT was using Java 1.5 and emulating more java.util classes I think
I would be a lot closer in terms of having to do away with this
awkward and costly (in time and memory) mapping.

Thanks for everyone's attempt to help.

Cheers,
- Garry Archer