Re: SDM incremental recompiles in non-servlet projects?

It would be nice if we could trigger de code-server using a URL parameter like we did before with devmode.

Our app is using jboss fuse (using osgi bundles to deploy apps) and there I don't see how I could handle running a bundle from some folder iso a jar. We use bnd to generate the required manifest entries so it only gets generated in the jar.

Every time that I reload the page I need to remember to press the compile bookmark again or I risk running the "old" version of my app.

On Wed, Feb 4, 2015 at 11:47 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

-launcherDir is an argument of CodeServer. If using DevMode, then use -war instead.

On Wednesday, February 4, 2015 at 1:03:27 AM UTC+1, Ali Akhtar wrote:

When I specify -launcherDir gives an 'unknown argument' error . I'm passing it as a devMode parameter in my IntelliJ Run configuration.

When I use -workDir , that works, however in my specified dir I see com.foo.myProject, and inside I see compile-1, which then contains war/moduleName , which in return contains the nocache.js file

However, each reload produces a new compile-X directory within the workDir, so I can't have a static way of serving the nocache.js files

Any ideas?

Here's a screenshot of my run configuration: http://i.imgur.com/NRzYz9L.png

This is the error given by gwt when I specify launcherDir:

Unknown argument: -launcherDir

Google Web Toolkit 2.7.0

DevMode [-[no]startServer] [-port port-number | "auto"] [-whitelist whitelist-string] [-blacklist blacklist-string] [-logdir directory] [-logLevel level] [-gen dir] [-bindAddress host-name-or-address] [-codeServerPort port-number | "auto"] [-[no]superDevMode] [-server servletContainerLauncher[:args]] [-startupUrl url] [-war dir] [-deploy dir] [-extra dir] [-modulePathPrefix ] [-workDir dir] [-XmethodNameDisplayMode NONE | ONLY_METHOD_NAME | ABBREVIATED | FULL] [-sourceLevel [auto, 1.6, 1.7]] [-XjsInteropMode [NONE, JS, CLOSURE]] [-[no]incremental] module[s] 

On Mon, Feb 2, 2015 at 7:42 PM, Thomas Broyer <t.broyer@gmail.com> wrote:

Anything that can serve files from the file-system can be used with SDM: just pass "-launcherDir path/to/some/directory" to the CodeServer and it will output a  *.nocache.js in there that triggers a recompile on page load.

On Monday, February 2, 2015 at 2:30:40 PM UTC+1, Ali Akhtar wrote:

I'd like to use GWT with SDM in a project that doesn't use servlets, instead its using the vert.x framework, with IntelliJ.

Currently, I have two run configurations in IntelliJ. 

The first one starts the vert.x web framework which listens on port 80, and on http://localhost , it sends my host.html file.

The second run config is a standard GWT SDM run configuration from IntelliJ. That one starts the gwt code server on localhost:1978

My host.html file contains this tag during development:

<script type="text/javascript" src="http://127.0.0.1:9876/MyModule/MyModule.nocache.js"></script>

and during production, it switches to: 

<script type="text/javascript" src="MyModule/MyModule.nocache.js"></script>

When I first visit http://localhost , the module auto re-compiles. However on subsequent refreshes, it doesn't recompile, and I have to use the old bookmarklet method to trigger a recompile manually. This also seems to do a full recompile rather than incremental.

Is there a way to trigger incremental recompiles automatically on reload, even though I'm not using the standard servlet based project layout?

Does GWT check the source files to see if they've changed when it triggers a recompile on reload, or does it check compiler output (e.g in target/classes)?

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/rxQ2WlG-_14/unsubscribe.
To unsubscribe from this group and all its topics, 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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 http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.