Naming a single class in source path

15 views
Skip to first unread message

Mark

unread,
Apr 9, 2007, 4:57:02 PM4/9/07
to Google Web Toolkit
Trying to add GWT to a large existing multi-tier application code
base. We already have (java) serializable classes for passing data
between tiers of this application. Those data holder classes are used
for RMI (EJBs) between the app server and thick clients. We want to
re-use the same class definitions for passing data between the GWT
browser application and the web server. We really don't want to
define parallel, duplicate classes just for GWT RPC. These are simple
data holders classes.

Two problems with trying to reuse these classes in GWT:

1) They exist in packages that have many other unrelated classes in
them. Some of those other classes cannot be compiled by GWT and/or
contain references to other packages outside the scope of the GWT
project. I cannot find a way to include just specific classes in the
GWT module -- the <source path...> element only works down to the
package level. How can I limit the module to just some specific
classes in a larger package?

2) Because our classes are used in RMI/IIOP, of couse they implement
java.io.Serializable. I totally understand why GWT does not use that
interface for its RPC marker, but why does GWT not define the
java.io.Serializable interface at all? These classes will not compile
because 'java.io.Serializable' is not defined. Would it not be
trivial to add java.io.Serializable to the emulated JRE class set (it
does nothing anyway)? Then classes such as this would compile without
errors. To get around this, I created a java.io.Serializable source
file and a GWT module to include it. Now our classes are compilable
with GWT. Sure would be nice to not have to play games like that.

Thanks,
-Mark

Jason Essington

unread,
Apr 9, 2007, 5:15:11 PM4/9/07
to Google-We...@googlegroups.com
Unfortunately, you can't just include some classes from a particular
package.

I guess the solution here would be to just copy those files to an
interim folder during compile (maybe using ant), and include that
interim folder in GWTCompile's source path. just make sure that those
classes remain in the same package structure that they started in.
depending upon your architecture, you may need to create a module
(.gwt.xml) to hold your data objects, then include (inherit) that
module in your main .gwt.xml

As for issue #2, you may be able to get away with just adding the
interface Serializable to:
/com/google/gwt/emul/java/io/ in YOUR source path. GWT will pick it
up and compile away.

One other nasty hack (if your Data Objects don't inherit from other
serializable classes) is to define Serializable like:

public interface Serializable extends IsSerializable{}

and then you don't even have to implement IsSerializable in your data
objects. Of course there is a bit of a bug in GWT that prevents that
from working if your data objects extend other serializable objects.

-jason

Reinier Zwitserloot

unread,
Apr 9, 2007, 7:52:47 PM4/9/07
to Google Web Toolkit
GWTx has Serializable for you. It doesn't do anything (doesn't make
classes transportable between server and client over GWT-RPC, still
need IsSerializable for that), but at least it's there so compiling
won't fail.

Other than that, what jason said.

Mark

unread,
Apr 10, 2007, 4:17:41 PM4/10/07
to Google Web Toolkit
Would it be possible to extend the <source...> tag to support pattern-
based filtering like the <public...> tag? Then I could include/
exclude as needed. We can copy the files during an ANT build, but not
so easy to do in the Eclipse environment (and just adds another level
of complexity/obscurity to the entire process).


Jason Essington

unread,
Apr 11, 2007, 1:22:43 PM4/11/07
to Google-We...@googlegroups.com
Actually, there was some discussion about that (and maybe even a
feature request), but I think that idea was shot down.

I agree, it would be nice to be able to use ant style patterns to
identify additional source files, like you can with the <public>
element:
http://tinyurl.com/3ywt4f

-jason

greensunie

unread,
May 2, 2007, 3:05:47 PM5/2/07
to Google Web Toolkit
Here's a curve ball. I have POJOs that we did modify to implement
IsSerializable, BUT those classes are generated in another application
and dropped into our app as a jar. The jar is outside the "src"
folder.

So..

/dependencies/
pojos.jar

/src/
......../gwt/MyModule.gwt.xml

In MyModule.gwt.xml it lets me specify source packages anywhere
beginning in the the /gwt/ folder and down, but it doesn't let me
specify source packages above the gwt folder in the /src/ directory or
within the /dependencies/ directory. using "/src/..." gives an
error, and using "../../../" dependencies also produces an error.

So it seems the source tag in the gwt.xml module files only allow you
to specify source locations at or below the location of the gwt.xml
file itself.

Doesn't that seem odd? Has anyone found a way around this?

-B


On Apr 11, 10:22 am, "Jason Essington" <jason.essing...@gmail.com>
wrote:


> Actually, there was some discussion about that (and maybe even a
> feature request), but I think that idea was shot down.
>
> I agree, it would be nice to be able to use ant style patterns to

> identify additionalsourcefiles, like you can with the <public>
> element:http://tinyurl.com/3ywt4f
>
> -jason


>
> On 4/10/07, Mark <mcmil...@engineous.com> wrote:
>
>
>
>
>
> > Would it be possible to extend the <source...> tag to support pattern-
> > based filtering like the <public...> tag? Then I could include/
> > exclude as needed. We can copy the files during an ANT build, but not
> > so easy to do in the Eclipse environment (and just adds another level

> > of complexity/obscurity to the entire process).- Hide quoted text -
>
> - Show quoted text -

Reinier Zwitserloot

unread,
May 2, 2007, 4:14:23 PM5/2/07
to Google Web Toolkit
It's intentional.

The way around it is to add a .gwt.xml file in the jar, and include
that (which CAN 'escape' up to parents of the path where the
original .gwt.xml file is)

You'll have to modify your .jar generator to add this file.
Alternatively, take the jar, unpack it, and add it yourself. You can
automate this quite simply with e.g. ant.

greensunie

unread,
May 4, 2007, 1:39:11 PM5/4/07
to Google Web Toolkit
I guess I could do that. But every GWT module wants an entry point...
I could have an empty entry point and have my real client entry points
inherit from it....
Something to think about
Thanks,
-B

> > > - Show quoted text -- Hide quoted text -

Mark Volkmann

unread,
May 4, 2007, 2:25:38 PM5/4/07
to Google-We...@googlegroups.com
On May 4, 2007, at 12:39 PM, greensunie wrote:

> I guess I could do that. But every GWT module wants an entry point...

That's not required. I have module that contains custom widgets used
by another module. It's module element only contains a source element.

> I could have an empty entry point and have my real client entry points
> inherit from it....

The module that uses it does inherit it, but no entry point is needed.

Reinier Zwitserloot

unread,
May 4, 2007, 9:18:32 PM5/4/07
to Google Web Toolkit
Any GWT module THAT YOU COMPILE OR RUN needs an entry-point.. but:

unlike java, in GWT land you only ever compile the main unit -
anything that it inherits is automatically compiled as well. In fact,
compiling a dependent unit does absolutely nothing to help the main
compilation process from working any faster.

Becky

unread,
May 7, 2007, 12:50:43 PM5/7/07
to Google-We...@googlegroups.com
Good to know.  To summarize for other newbies:
 
I can make a <name>.gwt.xml module at the root of my jar, with no entry point, and include only the packages that I want as "source" tags (to limit what's generated to what I need, by package).
 
Then I can inherit ("inherits" tag in gwt.xml) from it in any other module that needs access those POJOs.  It will automatically generate JS versions of those classes (so long as they conform to the requirements) when I generate my module's JS.
 
Thanks,
-B

dablackgoku

unread,
Jun 5, 2007, 5:56:52 PM6/5/07
to Google Web Toolkit
I am trying to do this, however, I am running into a few errors...

I made a jar with the following file structure

com/application/Constant.java
com/application/Serial.gwt.xml
com/application/model/Address.java
com/application/model/Person.java
com/application/resources/messages.java

Inside my com/application/Serial.gwt.xml, I have..

<module>
<source path="com/application" />
<source path="com/application/model" />
<source path="com/application/resources" />
</module>

This jar has been added to my classpath, and in my
MainApplication.gwt.xml, I inheirted it:

<inherits name='com.application.Serial'/>

When I do a GWT compile, I am getting errors like:

[ERROR] Line 38: CONSTANT cannot be resolved
[ERROR] Line 48: messages cannot be resolved to a type

Am I doing something wrong here?

John


On May 7, 12:50 pm, Becky <greensu...@gmail.com> wrote:
> Good to know. To summarize for other newbies:
>
> I can make a <name>.gwt.xml module at the root of my jar, with no entry
> point, and include only the packages that I want as "source" tags (to limit
> what's generated to what I need, by package).
>
> Then I can inherit ("inherits" tag in gwt.xml) from it in any other module
> that needs access those POJOs. It will automatically generate JS versions
> of those classes (so long as they conform to the requirements) when I
> generate my module's JS.
>
> Thanks,
> -B
>

Dan Morrill

unread,
Jun 5, 2007, 11:03:36 PM6/5/07
to Google-We...@googlegroups.com
Hello!

Your problem is probably here:

On 6/5/07, dablackgoku <john...@gmail.com> wrote:
Inside my com/application/Serial.gwt.xml, I have..

<module>
     <source path="com/application" />
     <source path="com/application/model" />
     <source path="com/application/resources" />
</module>

The paths specified in the <source> tag are relative to the location of the Module.gwt.xml file.  For example, since you are defining the module "com.application.Serial", with the <source> tags you cited, you are actually referring to the packages " com.application.com.application",
"com.application.com.application.model", etc.

I suspect you probably want:
<module>
  <source path="model"/>
  <source path="resources"/>
</module>

Note that if you have classes actually in "com.application.*" that you want to be translated, you'll need to move your Module.gwt.xml one package/directory level higher.  (This probably means you'll want to insert another package level -- which is why GWT normally standardizes on the "client" subpackage by default.)

Hope that helps!

- Dan Morrill

dablackgoku

unread,
Jun 6, 2007, 10:59:23 AM6/6/07
to Google Web Toolkit
Hi Dan,

Thanks for the response. I have tried your suggestion and its picking
up the right packages now. But I am back to my original problem of
trying to include specific files in my source.

Inside my main application, I have com/application/model and this
package contains all possible hibernate generated classes. Inside my
jar, I have com/application/model and this package only contains a
subset of the generated classes, the ones that the GWT compiler needs.

So, having <source path="model"/> in my com/application/Serial.gwt.xml
seems pull in all the hibernate generated classes which isn't what I
want. Am I doing something wrong here? Any suggestions would be
greatly appreciated.

John


On Jun 5, 11:03 pm, "Dan Morrill" <morri...@google.com> wrote:
> Hello!
>
> Your problem is probably here:
>

krispy

unread,
Jun 6, 2007, 11:06:42 AM6/6/07
to Google Web Toolkit
dablackgoku,

Maybe your problem is more or less that you need to separate your
hibernate classes better? Perhaps you should have all the hibernate
classes you need to keep inside of its own package, i.e.
com.application.model.export, then you could make your <source> target
more specific to account for it. It sounds like its simply a problem
of organization - or am I missing some unknown complexity here?

-krispy

dablackgoku

unread,
Jun 6, 2007, 11:19:57 AM6/6/07
to Google Web Toolkit
The hibernate classes are generated and shared with other classes in
my main application. I was hoping to eliminate the overhead of
managing or duplicating these classes and just give the GWT compiler
the minimal set of hibernate classes to work with. I thought wrapping
this subset of classes inside a jar file would work, however, that is
not the case.

This is necessary as my application no longer compiles with GWT 1.4.

John

> > > - Dan Morrill- Hide quoted text -

Reply all
Reply to author
Forward
0 new messages