{"action":"created","issue":{"url":"https://api.github.com/repos/gwtproject/gwt/issues/9451","repository_url":"https://api.github.com/repos/gwtproject/gwt","labels_url":"https://api.github.com/repos/gwtproject/gwt/issues/9451/labels{/name}","comments_url":"https://api.github.com/repos/gwtproject/gwt/issues/9451/comments","events_url":"https://api.github.com/repos/gwtproject/gwt/issues/9451/events","html_url":"https://github.com/gwtproject/gwt/issues/9451","id":187496116,"number":9451,"title":"GWT Development Mode Launcher and GWT-DEV external code Issues","user":{"login":"dfht","id":6401382,"avatar_url":"https://avatars.githubusercontent.com/u/6401382?v=3","gravatar_id":"","url":"https://api.github.com/users/dfht","html_url":"https://github.com/dfht","followers_url":"https://api.github.com/users/dfht/followers","following_url":"https://api.github.com/users/dfht/following{/other_user}","gists_url":"https://api.github.com/users/dfht/gists{/gist_id}","starred_url":"https://api.github.com/users/dfht/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dfht/subscriptions","organizations_url":"https://api.github.com/users/dfht/orgs","repos_url":"https://api.github.com/users/dfht/repos","events_url":"https://api.github.com/users/dfht/events{/privacy}","received_events_url":"https://api.github.com/users/dfht/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-11-05T13:07:45Z","updated_at":"2016-11-08T11:20:33Z","closed_at":null,"body":"Because the GWT Development Mode Launcher (in GWT Plugins rather than GPE but same applies to both) also runs the code server for superdev mode, it seems that it also puts gwt-dev on the runtime class-path of the server. This causes lots of problems due to GWT-DEV having duplicated code from many other third party jars. In our application, there have been a number of clashes over the last few years. The latest was in the version of Xerces bundled in GWT-DEV, but there have been many more. \r\nThis has led to me eventually using a separate WTP Tomcat server set-up and separate code server that specifies a launcherDir, which of course means the server no longer has this issue and GWT dev is only used by the process that actually needs it - the code server. \r\nHowever, this involves more configuration for our users in setting up Tomcat etc. (domain expert developers etc.), and is not ideal. \r\nIs there a way of using the embedded Jetty on its own without the same launcher/process also running the code server so that I can at least avoid users having to download and set up Tomcat etc.?\r\nAlternatively can the launcher be changed so as to run the code server and embedded Jetty as separate processes under the covers (If it doesn't already !) and hence provide them with different run-time class-paths so the server doesn't have gwt-dev and the code server does (so it would to the user only be starting and stopping a single thing but under the covers there'd actually be two processes)?"},"comment":{"url":"https://api.github.com/repos/gwtproject/gwt/issues/comments/259111694","html_url":"https://github.com/gwtproject/gwt/issues/9451#issuecomment-259111694","issue_url":"https://api.github.com/repos/gwtproject/gwt/issues/9451","id":259111694,"user":{"login":"dfht","id":6401382,"avatar_url":"https://avatars.githubusercontent.com/u/6401382?v=3","gravatar_id":"","url":"https://api.github.com/users/dfht","html_url":"https://github.com/dfht","followers_url":"https://api.github.com/users/dfht/followers","following_url":"https://api.github.com/users/dfht/following{/other_user}","gists_url":"https://api.github.com/users/dfht/gists{/gist_id}","starred_url":"https://api.github.com/users/dfht/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dfht/subscriptions","organizations_url":"https://api.github.com/users/dfht/orgs","repos_url":"https://api.github.com/users/dfht/repos","events_url":"https://api.github.com/users/dfht/events{/privacy}","received_events_url":"https://api.github.com/users/dfht/received_events","type":"User","site_admin":false},"created_at":"2016-11-08T11:20:32Z","updated_at":"2016-11-08T11:20:32Z","body":"First I just want to say thanks and to say that I basically agree with all that you've all said about the problems with DevMode and the relative merits of the separate code server approach and I use that a lot already, so it's not a case of moving to the new way (at least for me - my users are a different matter :)). I have now written code in my plug-ins (against WST server core and server core UI code) to set up a Tomcat server and code server launcher with the required set-up I need, so much of the 'drudgery' I referred to earlier (which was just the downloading of e.g. Tomcat , the manual creation of the WTP Tomcat server, the setting of the code server class-path, the insertion of system properties and vm arguments I need into the two kinds of launcher etc.) are all accomplished by a single click now in my set-up. That's all fine and I'll tell my users to follow this approach. It was necessary to avoid these steps for my users. Previously, a single persisted 'dev mode' launcher in one of the projects has accomplished the goal of having a 'ready to use' set-up, which was definitely more simple and elegant.  However, the class-path issues caused by duplication in the GWT-Dev jar have been a constant headache (especially considering Maven's necessary but often troublesome tendency to drag in the whole world via transitive dependencies), and the latest duplication of jars ruining resource look-ups has been the final straw for our use of 'dev mode' launchers I think :).\r\n\r\nOn a more positive note, the state of GWT and the ease (and speed) of developing with it is (in my opinion) excellent now compared to when we started development on our current platform 3 1/2 years ago. Indeed I have worked with it over many years before that (more or less since it first came out), and compared to back then, well, let's just say that it has come a long long way....\r\nIn the last few years we've seen Super Dev mode come along, incremental compilation (now of course even between server restarts even), source maps debugging, JSInterop etc., and what I think have been great strides also in Eclipse and related plug-ins. I'm very very happy with it in general now, although slightly concerned (and puzzled!) about its future direction (GWT 3), especially as it seems to me that it has finally matured into something great....\r\n\r\nWhilst I have your attention, let me explain a bit more about my set-up and ask a few more questions.....\r\nMy set-up is based on all projects using Maven. I use Eclipse Neon, and I use m2e to entirely manage the class-paths etc. in Eclipse. I have a single lowest level war project  that brings in all of the other projects (there are many of our own GWT modules and of course back-end server projects), so everything is nice and simple for class-paths - this lowest project is enough to specify all dependencies for most purposes (launchers etc.). \r\n\r\nAnother ingredient in this soup is the mojo GWT Maven plugin (I'm aware of Thomas's alternative plug-in and I will likely switch to it eventually - for now this works just fine for me).\r\nThere are many other ingredients like Spring, WTP natures and above all the fact that most structures are in fact generated from models, but I'll try and stick to what's relevant...\r\n\r\nThe lowest level war project is a dynamic web module. \r\n\r\nNow to the questions. In my set-up, when (and only when) I run the dev-mode launcher,'something' put's all of the jars (including third party Maven jars and transitive dependencies) into the target/XXX-0.0.1-SNAPSHOT/WEB-INF/lib of the lowest level web project. This only happens when I start the dev mode launcher. It doesn't happen when I build the project in Eclipse (e.g. Project/clean...) or run the M2E 'Maven/Update Project...' action, or even when I start up a standalone Tomcat server on the project (which publishes instead to a folder in the workspace metadata). It ONLY happens when I start the server as a DevMode launcher. It's like the embedded Jetty is using this folder (XXX/target/XXX-0.0.1-SNAPSHOT) as its equivalent to the wtp.deploy folder to 'publish' all of the jars into a war structure... If that is so (and it certainly seems to be the case for me at least!) then my question is \r\n\r\n'Why do the jars from the local Maven repository also get put on the class-path of the DevMode server?'\r\n\r\nNow I don't want to use dev mode, but it'd be nice (as it is there already) to be able to make use of the embedded jetty as just a web server (without gwt-dev on its runtime class-path, and without the local maven jars on its path, and to use the target/XXX-0.0.1-SNAPSHOT as the launcherDir for a code server launcher). That way, I'd be able to have a ready to use solution tied just to a persistable (in a project and hence SCM) Eclipse launcher so (lazy?) people can at least have the option of running this way.... \r\n\r\nAnyway, I am going to have go at making this work (possibly via my own launcher type - I'm not sure yet) so users will then have this option as well as my other generative solution to create a ready to use server/code server combination (the latter still has the single disadvantage that needs a Tomcat installation 'somewhere' - I do realise that it also has many advantages btw!).\r\n\r\nAs a start, I am looking at the SevletContainerLauncher/Jettylauncher hierarchy..... \r\nThomas said:\r\n\r\n'to run Jetty in the same way as the default launcher except without the classloader broken tricks'\r\n\r\nDo any of you happen to know where in the plug-ins code to find these 'broken tricks' :)? \r\n\r\nIf not, then no worries and thanks again for your help......\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n                                        "}}
{"actor":{"display_login":"dfht"}}