On Friday, December 2, 2016 at 5:48:36 PM UTC+1, vitrums wrote:
Even though I can read .pom configuration files, I'm not strong in configuring them myself, when it comes to multi-module project. Especially when it comes to packaging servlets as jar.
Well, servlets are nothing more than Java classes extending from a specific abstract class. What makes it a servlet is how it's used at runtime (when used in a WAR to be deployed to a servlet container, then there needs to be a servlet mapping, defined either using a @WebServlet annotation or some XML in either a WEB-INF/web.xml file in the WAR, or a META-INF/web-fragment.xml in a JAR sitting in the WEB-INF/lib of the WAR.
So I introduced the new module sandbox-server-lib. But which files should it consume from sandbox-server? E.g. if I move only com.mycompany.GreetingServiceImpl.java under sandbox-server-lib I won't have servlet mappings, necessary for jetty to operate during tests in sandbox-client (should I duplicate some files and have them in both modules)?
There's no "servlet mappings […] for jetty to operate during tests"; the servlet mapping for GWTTestCase tests is defined by a <servlet> element in a gwt.xml file.
In other words, when everything is in a single project (like the one generated by webAppCreator, or the wizard in Eclipse, or the archetype from the org.codehaus.mojo:gwt-maven-plugin), the src/main/webapp/WEB-INF/web.xml is completely ignored during tests.
If I move /src/main/webapp, then I'm not even sure what will be left for sandbox-server to package as war and how to deploy it in container. And which dependencies, plugins and configurations would sandbox-server-lib's pom require (and what left from sandbox-server after all these operations)?
Try with "nothing" :-)
Well, in the server-lib you'll need a dependency on javax.servlet to be able to compile your servlet, and in server (the WAR) you'll add a dependency on server-lib. No plugin should be needed.
I know I'm terribly lost :)
Yes, you look like you're lost :-)
I'm afraid you can't develop in any given technology without learning the "basics" (between quotes, because it can mean a lot of things; learning curves are steep these days, and tending to become each year steeper than the preceding) : what is the classpath, a classloader, a JAR, a WAR, how to build a (simple) JAR (using the command-line, or some build tool), how to build a (simple) WAR. GWT adds a lot of things to those "basics", particularly when your build tool is as opinionated (and broken-by-design) as Maven.
I'm a bottom-up learner, first learning how things work (from documentation, not experimentation) before doing something with them, rather than a top-down learner, first doing things (possibly copy/pasting snippets here and there "until it works") then trying to understand how and why it all worked. That makes me a terrible teacher for top-down learners, who are better served with heavy full-stack frameworks and full scaffolding (ultimately leading to a huge amount of third-party code to do a simple hello world, if you ask me). Please note that I'm not judging "top-down learners", everybody is different and learns differently; I'm only acknowledging I'm generally unable to help them. I'm not sure what kind of learner you are, just letting you know that if you're a top-down one, then I'm probably not the right "teacher", and my gwt-maven-archetypes haven't been tailored for you (I am expecting average knowledge of Maven and GWT).
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment