I have a utility module for GWT which doesn't have an UI (hence, there is no class which inherits from com.google.gwt.core.client.EntryPoint. When I try to compile this module with GWT 1.7.1, I get this error:
[ERROR] Module has no entry points defined
How do I get rid of this error? Do I really have to define a dummy entry point? How did Google ever compile their own utility modules???
Utility Jars do not need to be compiled by GWT.
If you just want to reuse this as a library in other GWT applications then you just have to jar the .class and .java files in one jar and make sure that you have a .gwt.xml that says where the client source is. If you follow the conventions (client classes in client) then you can get away with just otherwise you need to specify a tag for the client package
Then make sure that you inherit this .gwt.xml in the projects where you want to compile an entry point.
No you don't need an EntryPoint. Here is an example of one of my modules that doesn't have one:
<?xml version="1.0" encoding="UTF-8"?>
<module>
<source path="grid" />
<inherits name="com.google.gwt.user.User"/>
</module>
The short answer is you don't compile code in modules. GWT just needs them as source code. When you compile your main module (the one with the entry point) it uses the source from any other modules you have inherited in your .gwt.xml file to compile the entire project.
I'm using the gwt-maven-plugin Maven2 plugin to compile my code. I migrated the code from an old version of the maven-googlewebtoolkit2-plugin plugin. For the old plugin, I had to specify which modules were entry points like so:
<compileTargets>
<param>com.project.module.Module</param>
</compileTargets>
For the new plugin, it's
<module>com.project.module.Module</module>
Since the plugin couldn't find which modules to compile, it search for "*.gwt.xml" and compiled all of them into "UI modules" (which must have an entry point).
We've got a utilities module, which constructs & handles some common UI elements, and a bunch of javascript/json common tasks.
It looks like what we did (also migrated from the totsp plugin to the codehaus plugin somewhere along the line) was to include an entry point in the util module; it was just empty. (It includes the comment "Intentional no-op").
Then the pom just refers to the thing as a dependency.
If using eclipse GWT plugin just remove the module without an EntryPoint from the moduleslist that pops up just before compiling.
Related
Just recently started using Eclipse and ran into an issue with exporting the plugin I'm working on. I tried to search but so far no luck - but if the answer is already here I'd be grateful if someone can point me to it.
I'm writing a n OSGi/Equinox plugin with Eclipse. The plugin is for a 3rd party system, which allows extensions: basically all jars placed in the application's plugin folder are automatically loaded into the application at startup. I have managed to put together my plugin, it's loading fine and it works.
The issue is that I rely on another plugin which is placed beside mine in the plugins folder. For obvious reasons I do not want to package that plugin into my plugin jar file. I have tried to add the dependency as an external archive, but this breaks the export: when I try to export my plugin project ant complains about missing dependencies and types. (If I actually include the other jar file in my plugin everything works, but obviously this is less then ideal.)
So: how do I set up my plugin project dependency, that it's a) an external dependency and b) doesn't need to be specified with a path or a variable - i.e. how do I tell my exporter to "don't worry, it will be there right beside you"?
Edit: Apparently there's an important detail I didn't mention. The external jar file I depend on is not an OSGi plugin, just a regular jar file with some classes in it. To the 3rd party system it seems all the same (all are under the plugins folder, all are loaded into the application), but for Eclipse the distinction seems important.
If you reference the other plug-in as a dependency in your plug-in's MANIFEST.MF the export should work without errors. The plug-in should be listed in the Require-Bundle list in the MANIFEST.MF.
You can do this in the MANIFEST.MF editor by adding to the 'Required Plug-ins' list on the 'Dependencies' tab of the editor.
Note: When referencing other plug-ins you must always use this method. Do not try adding the plug-in jar to the Java build path or anything like that.
If the jar you want to use is not an Eclipse plug-in you must should include it as part of the plug-in and list the jar in the Bundle-Classpath in the MANIFEST.MF. If you cannot do this you can reference an external jar in the Bundle-Classpath using something like:
Bundle-Classpath: .,external:$LIB_LOCATION$/lib.jar
. is the normal entry in for the plug-in code. external:$LIB_LOCATION$/lib.jar looks for lib.jar in a location defined by the environment variable LIB_LOCATION. This method can be difficult to get right.
In the end the solution to my specific problem was to add the external jar file as an Extra Classpath Entry on the build properties tab (this translated to a "jars.extra.classpath = .jar" entry in the build.properties file). I have also added the jar file to the project itself - after adding the extra class path entry that got changed into an external dependency automatically.
With these two changes I was able to successfully export my plugin, which didn't contain the external jar file, but was able to reference it when loaded into the 3rd party system.
The GWT documentation states that all the source code for compilation to JavaScript on the client-side must be in a subpackage of the gwt.xml file. How does this work for when one references third party libraries?
Specifically, if I have a library foo.jar and I want to use some POJOs (which are Serializable) and do not suck in any non-Serializable code, how can I use these POJOs? How do I tell GWT where the source code is for them?
Remember too that the GWT compiler needs actual Java source to compile to javascript, so it isn't enough that the classes are available and that all are serializable. For RPC to send the classes over the wire, they must be able to be used as JS when they get to the client.
That said, take a look in gwt-user, at the module javax/validation/Validation.gwt.xml. This file is put there so that other packages in javax.validation - even in other jars - can be compiled into JS for client-side validation. if you have a jar (and sources) on your classpath with code in com.thirdparty.pojos, you can create a module file in your own project in that same dir in your own source (something like com/thirdparty/pojos/ThirdParthRpc.gwt.xml, and put a <source path="" /> element in it to indicate that the entire package is legal for translation to JS. There will likely be some files that cannot be translated - use the exclude tag to deal with those.
If you have control over packaging foo into foo.jar, and you have all the sources, then it's easy.
If you have a packaged foo.jar, and happen to have the source code, then you need to expand the foo.jar, copy the source into the exploded .jar directory, generate a simple GWT module.xml file and add an tag to your project’s module.
I'm wanting to use some java code as a reusable component jar in my GWT 2.4 application.
I need access to that code on the client side, so I've read that the steps involved are to
add an entry in the main projects gwt.xml file pointing to this project,
include a gwt.xml file in the jar
and put the java code under a client folder.
I assume that this has to be a gwt project itself, otherwise there would be no need to add the inherits entry or is it not possible to use a regular java project client-side?
Is there anything else I need to do for this (other than ensure the libraries in the jar fall under the JRE Emulation Reference list)?
We don't use the plugin functionality in Eclipse, but to use another project in your GWT project all you need to do is define a .gwt.xml module file in your project that you want to use in your GWT project and reference that module file with <inherits.../> in your main GWT project. You will also obviously need to add that project as a reference in the build path in Eclipse, so you don't get compilation errors. And all of that is besides the fact that your referenced project has to comply to the JRE emulation reference so it can be fully GWT compilable.
I am currently using gwt 2.3 and smartgwtpower 2.5 nightly and using Eclipse on Linux. My web app is using common code, developed in house, and packaged to a jar called commonsmartgwt.jar. In this jar is the entry point class and has its own gwt.xml file. In my web app's gwt.xml file I inherit from the entry point class
<inherits
name="common.code.Common"/>
and I use the entry point common.code.client.Common as my web app's entry point. All my classes in my web app extend classes in the common code. Compilation and running works
fine but when I try to run a test using eclipse method Run As > GWT Junit Test, I get the following error.
Unable to find common/code/Common.gwt.xml on your classpath; could be a typo,
or maybe you forgot to include a classpath entry for source.
If I create the folder common/code/ under classes and extract the .gwt.xml file from the commonsmartgwt.jar and put it in that directory, I get a different error.
'my.package.client.MyFirstTest' was not found in module
'common.client.Common'; no compilation unit for that type was seen
Is there a way to Unit test this application. Please let me know if my situation is not clear. What if I moved the entry point from the common code to my web app? I tried following the instructions here: [Error resolution][1]
[1]: http://raibledesigns.com/rd/entry/testing_gwt_applications "Link"
but this did not work.
I had the incorrect module name returning in the getModuleName test method.
I have a GWT project in eclipse with the following structure for the GWT module
com.foo.gwt -> Dashboard.gwt.xml
com.foo.gwt.client
com.foo.gwt.server
I have different packages com.bar.baz1, com.bar.baz2, etc. whose contents I want to include in client side code. All the files are GWT JAVA->JS conversion compatible.
The problem is that the <source> tag in Dashboard.gwt.xml, treats the path as relative to the directory of Dashboard.gwt.xml. So I cannot reference anything outside com.foo.gwt hierarchy.
So I created a new module MyNewModule.gwt.xml in com.bar and included baz1 and baz2 sub packages using relative paths in tag. Finally I made Dashboard.gwt.xml to inherit the new module.
This works fine when I compile the Dashboard module but fails when I compile MyNewModule.
That's because some classes in MyNewModule reference classes of Dashboard module.
I tried inheriting Dashboard module in MyNewModule. This creates a circular reference, but GWT doesn't complain about it. Everything works but I am not comfortable with the circular reference. I don't need MyNewModule, all I need is a way to include code from packages outside Dashboard module's hierarchy.
I am wondering why GWT does not allow absolute source paths.
Am I missing something here?
You dont need to compile each module separately. When you compile your com.foo.gwt project, GWT compiler will look for all dependencies in your com.foo.gwt.xml file and will compile ALL .java files both your com.foo and com.bar.baz. (and other libraries) to javascript.
As you said, its correct to put MyNewModule.gwt.xml in the com.bar.baz project and "inherit" it in your DashBoard.gwt.xml file. The part you are missing is to make a .jar file with MyNewModule project and put in war/WEB-INF/lib folder (just gwt.xml file and compiled java classes).