Re: About running tests in a project built via tbroyer's maven multi-module archetype
On Friday, December 2, 2016 at 9:47:44 AM UTC, Thomas Broyer wrote: > > > > Because, actually, using in GWTTestCases is not seen as a good > practice (anymore). GWTTestCases should be unit tests, running in a > GWT/browser environment, not integration tests. For that, the preferred way > is to use end-to-end tests. > > Hi Thomas, What is state of the art for "end-to-end tests" for GWT apps with server side component? The generic solutions like WebDriver? Cheers Sam -- 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+unsubscr...@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.
Re: About running tests in a project built via tbroyer's maven multi-module archetype
On Friday, December 2, 2016 at 8:06:23 PM UTC+1, vitrums wrote: > > Is it safe to leave it like this? > Absolutely. And actually, there's no bug in gwt:test. gwt:test (actually, GWTTestCases, whether run through gwt:test or surefire:test or whatever) simply expects the sources to be on the classpath. What you faced was just a limitation of Maven's linear lifecycle when combined with reactor builds: because source:jar-no-fork in shared-lib was bound to the package phase, and you didn't run it (you only run the lifecycle up to the test phase, in each module) the source-jar wasn't available (and neither was the jar BTW). When Maven needs to resolve a dependency from the reactor build and no artifact has been attached to the project, it simply defaults to using target/classes (it actually depends on the packaging), so you never got your sources when running tests. By attaching the source:jar-no-fork to the process-classes phase, when the test phase is run, the source-jar is attached to the project so it can be resolved. My take on this is that you shouldn't ever run any lifecycle phase prior to package (at least in a reactor build), and this is why I attached the source:jar-no-fork to the package phase in the gwt-maven-archetypes. Failing to run at least up to the package phase means that your artifacts aren't fully built and attached, and Maven uses heuristics to replace them, and it can fail you and cause all sorts of issues (generally breaking your build, but it could also cause false-positives). All this discussion makes me want to write (yet another) blog post on why Maven is broken by design, and how to avoid failing into its traps (basically: use "mvn verify" instead of "mvn install" as that's what you want 99% of the time, never run anything prior to the package phase in a reactor build, and use -DskipTests or -Dmaven.test.skip if you want to skip tests, or -Dtest= to filter tests to run) -- 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+unsubscr...@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.
Re: About running tests in a project built via tbroyer's maven multi-module archetype
You might have just uncovered a bug in gwt:test. I think a workaround would be to move the maven-source-plugin to the process-classes phase. -- 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+unsubscr...@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.
Re: About running tests in a project built via tbroyer's maven multi-module archetype
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 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+unsubscr...@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.
Re: About running tests in a project built via tbroyer's maven multi-module archetype
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*. 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)? 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)? I know I'm terribly lost :) -- 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+unsubscr...@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.
Re: About running tests in a project built via tbroyer's maven multi-module archetype
On Friday, December 2, 2016 at 5:53:46 AM UTC+1, vitrums wrote: > > It's also not clear for me why greetingService test classes must've been > completely excluded from the *modular-webapp* archetype. > Because, actually, using in GWTTestCases is not seen as a good practice (anymore). GWTTestCases should be unit tests, running in a GWT/browser environment, not integration tests. For that, the preferred way is to use end-to-end tests. > Archetypes in general serve to unify the maximum of core best practices > relevant to some particular project structure (tests including), don't they? > Archetypes are meant as scaffolding tools to cut boilerplate down. Putting "too much" things into an archetype means that you have to delete/refactor many things before actually being able to use the generated project. The gwt-maven-archetypes could include some tests, but the code is so light that it'd be far-fetched and not realistic. In your specific case, if you want to replicate the test using GreetingService; you'd have to create a new standard JAR module with your server code. The WAR module would depend on it (to include into the WAR/webapp); and the client (gwt-app) module could depend on it with test. -- 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+unsubscr...@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.
Re: About running tests in a project built via tbroyer's maven multi-module archetype
It's also not clear for me why greetingService test classes must've been completely excluded from the *modular-webapp* archetype. Archetypes in general serve to unify the maximum of core best practices relevant to some particular project structure (tests including), don't they? -- 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+unsubscr...@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.
