Can't include remote files across directories about gwt-maven-archetypes HOT 8 CLOSED

Never ask questions cus you always end up figuring it out 15 minutes later. I think the archetype should put the files in the equivalent of src/main/java/com/yourcomp/client or similar. There's a namespace conflict putting them directly in src/main/java/com/yourcomp/ for each project. I don't understand how it worked with out specifying imports..

Note: after adding client, server, and shared directories client and server builds fail with: No source code is available for type com.tapsavvy.shared.AppFactory; did you forget to inherit a required module?

One more thing: I think GreetingResponseProxy should be public.

from gwt-maven-archetypes.

If you add a shared package, you have to add the following to the gwt.xml (because the default is to only include client):

<source path="client" />
<source path="shared" />

You're right about the visibility of GreetingResponseProxy and I'll fix it (thanks).

And as for using explict client, shared and server packages, I'm not opposed to the idea but it IMO unnecessarily duplicates what we already have with the Maven modules.

from gwt-maven-archetypes.

You must not be using an IDE :) When you have a namespace conflict (both com.name) the IDE won't let you click > import because it thinks the source you want to include is already in the same package (which it's not). I would consider that a pretty big motivation for eliminating the namespace conflict.

from gwt-maven-archetypes.

Er, sorry, which namespace conflict?!
The archetype does not have 2 classes named the same (even between client and server, where they wouldn't even conflict).
If you introduce a conflict, it's your fault. And if you want to introduce subpackages to help you avoid conflicts, well, just do it!

from gwt-maven-archetypes.

Now I'm fighting the RequestFactory validator. A lot changes when you break up the namespace! Originally the server's pom runs validation on the shared classes (AppFactory). I get the validation error when trying to build the server so I'm thinking that the validation tool should be run by the shared project.. fighting the lifecycle execution on that one.

Also: The GuiceServiceLayer constructor should probably be public too.

from gwt-maven-archetypes.

I can avoid actual name space conflicts between projects (no problem) but my point was about the way IDE's work. If somebody on your team wants to use Eclipse this structure will break. If I try to import a class in com.name (from the shared project) into com.name (in the server project) the IDE assumes that the class is in the same package and the importing mechanism where you click on a class and say "import" breaks.

EDIT: I think you were right to just do the validation on the server. I think the problem is the @ServiceName reference of the server-side service from the shared project. Does inclusion work in that direction? I would leave you out of this but if the project structure only works when the services and proxies have the same package signature, I think you'd agree that's not a very flexible structure ;)

from gwt-maven-archetypes.

GuiceServiceLayer is instantiated by Guice, and follows the best practice of keeping the constructor as hidden as possible.

RF interface validation is not just about validation: it generates a DeobfuscatorBuilder. That class is only needed on the server-side (or on the client-side of a Java –non-GWT– app, such as an Android client) and, on the server-side, must know the server-side classes, so it cannot be generated in the shared module. Furthermore, the DeobfuscatorBuilder not being translatable to JS, and being required to live in the same package as its associated request factory interface, generating it in the shared module wold cause warnings in the client module.

Finally, as for your issues with Eclipse, if a class is in com.name and you use it from a class in com.name, then you don't need an import statement, whether the class lives in the same physical folder or JAR or not: this is about the classpath, not files or folders or JARs or modules or whatever. So, I don't see an issue here.

from gwt-maven-archetypes.

After starting fresh I can confirm that this setup works with a more complex project structure. The only necessary change was to add a shell gwt.xml to the shared project and inherit the module from the client. I don't think that should cause any problems..

btw you might want to change the: "cd gwt-maven-archetypes && maven clean install" in the wiki to mvn clean install.. but now i'm just nitpicking ;)

from gwt-maven-archetypes.