How to run GWT Super Dev Mode code server with Buildship?

Help/Discuss Buildship
,
1

We are trying to convert to using Buildship. After some troubles with v1.x and an early success with v2.0.0.v20160714-1015-s (inside Eclipse Neon) and Gradle 2.14 we are facing a problem launching a GWT Super Dev Mode code server - the runtime classpath is not complete. It starts but fails to load various *.gwt.xml files that are inside the jars that are transitive dependencies of our projects. These jars are downloaded from a Maven repository and contain both *.class and *.java (source) files in them - there is no separate resources/sources jar. For example:

Turning off precompile in incremental mode.
Super Dev Mode starting up
   workDir: C:\Users\...AppData\Local\Temp\gwt-codeserver-541360710207059603.tmp
   Loading inherited module '... our project 1 ...'
      Loading inherited module '... our project #2 ...'
         Loading inherited module '... our project #3 ...'
            Loading inherited module 'com.googlecode.gwt.crypto.Crypto'
               [ERROR] Unable to find 'com/googlecode/gwt/crypto/Crypto.gwt.xml' on your classpath; could be a typo, or maybe you forgot to include a classpath entry for source?

GWT code server expects the source code to be available on the classpath, same as the compiled version (bytecode). This is how we have been using it so far. The problem is now that, even though the jar is listed in classpath of one of the projects that is itself listed in the launch/runtime classpath, it is not visible. When I explicitly (manually) add it, I move on to the next problem of the same kind. Problem is that I cannot manually add these dependencies as they come from the Gradle cache and change all the time.

I tried checking the checkbox of “Project and external dependencies” in the “Order and Export” tab in Eclipse Java build path properties (for all projects) but that didn’t help either. I did not restart Eclipse but I do not expect that I have to. I also have not found the way to automatically mark these dependencies as exported - and I am not sure that I should do this either. I also tried removing all classpath entries and adding them again, assuming that something different may be done with Buildship, but that did not help.

Any recommendations as to what I should do?

2

Update - some progress made. I manually edited the launch configuration in a text editor. What I did does not seem to be possible from the Eclipse UI. I took the example of the default project classpath entry and used it as a template for all other dependency projects. I turned all of these:

<listEntry value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry path=&quot;3&quot; projectName=&quot;our.project.name&quot; type=&quot;1&quot;/&gt;&#13;&#10;"/>

into these:

<listEntry value="&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;no&quot;?&gt;&#13;&#10;&lt;runtimeClasspathEntry id=&quot;org.eclipse.jdt.launching.classpathentry.defaultClasspath&quot;&gt;&#13;&#10;&lt;memento exportedEntriesOnly=&quot;false&quot; project=&quot;our.project.name&quot;/&gt;&#13;&#10;&lt;/runtimeClasspathEntry&gt;&#13;&#10;"/>

To make it easier to read here, the entry changed XML changed from:

<runtimeClasspathEntry path="3" projectName="our.project.name" type="1"/>

to:

<runtimeClasspathEntry id="org.eclipse.jdt.launching.classpathentry.defaultClasspath">
  <memento exportedEntriesOnly="false" project="our.project.name"/>
</runtimeClasspathEntry>

This configuration is still failing but much later - I have yet to check the cause.

3

I discovered that cause - test dependencies are included in the runtime classpath. They should not be - they should only be included for tests. This is related to Main vs. test, compile vs runtime classpaths in Eclipse - once and for all, how?

4

What trouble did you have with 1.0.x? 2.0.0 is not stable. All bug fixes are also contained in 1.0.x.

I don’t know how you configured the launch configuration, but just adding the default classpath of a project is enough. You don’t need to re-export anything, Buildship already includes the transitive dependencies in the classpath container.

We are aware of this problem, but don’t have a clear time line for when it will be fixed. If someone in the community would like to step up, I’d be happy to guide them through the design and review for such a change.

5

Thanks for the response!

We tried v1.0.16. We were hitting “Error importing gradle project into Eclipse”.

We also need some features not available such as the above and “Binary dependency substitution”.

Speaking of community help, we MAY be able to help but would need help ourselves - guidance as to where things are and the preferred way to accomplish things. We already planned to do something like this for the coexistence with Maven projects in Eclipse (replacing binary dependencies with in-Eclipse Maven projects) but also crucial to us is the classpath separation - it actual breaks the build (classpath is scanned, classes that should not be found are and cause errors). This affects things like Spring classpath scanning (may find beans it shouldn’t) and GWT code servers (will try to transpile test code to JavaScript but fails to find the source code for dependencies such as JUnit, for example).

6

That said, re the original question - I am not sure that my workaround for the problem (manual editing of the .launch file classpath) is valid and am worried that it could break at any time if someone tries to edit this in Eclipse. Are there any official comments/recommendations re that?

7

That’s fixed in 1.0.17

There are several ways to go about this:

  • fix the classpath separation problem in Buildship, either by developing it yourself (with some help form us) or by letting us develop it (with your sponsorship)
  • have separated projects for production and test code
  • use IntelliJ (just for completeness sake :wink: )

I can certainly help with that. Let me know if you want to work on this.

8

Re:

have separated projects for production and test code

That is what we are doing now using a lot of Gradle magic (test projects are entirely virtual, created on demand by our Gradle scripts, linking to test sources and dependencies in the main project and hiding the tests from there). This is undeniably ugly, though, especially when there are many projects involved.

Re:

I can certainly help with that. Let me know if you want to work on this.

We have the approval to get involved developing Maven coexistence. Did not really plan on handling classpath separation too, but we can talk about that. I can pass info on, but what would be the next step for us? Note that we prefer to remain anonymous to the public, in the forums but we could contact you otherwise directly.

9

I do not know if this helps and if it will work with Buildship: there is a GWT-Plugin at https://github.com/steffenschaefer/gwt-gradle-plugin

10

Re GWT plugin… GWT is not really the problem here. Were it not for other needs as well, we could just run GWT code server from Gradle / command line directly. We have a present approach using user libraries too that works. However, we are trying to simplify the development environment setup and Buildship aligns with that well, but is missing a few things… The point is that we have to be able to (at the same time):

  1. Use only main compile and runtime classpath entries / dependencies and NOT any test.
  2. Replace our “binary” dependencies with Eclipse projects if they exist, otherwise use the binary ones. This is also for GWT. This cannot be done outside Eclipse (i.e. command-line Gradle) as those projects can only be discovered and used from within Eclipse.
  3. Do #2 even if those Eclipse projects are not using Gradle but Maven, as we (still) have a number of projects in Maven. Migration to Gradle for these projects is very complicated due to large investment in some custom scripting and coding so it is not planned for them (we have other and future projects in Gradle, but this is also made complicated by the lack of this Gradle-Maven cooperation, so projects that must cooperate with other Maven projects presently must be Maven…
11

OK, here:

I can see that many of listed features are of direct interest to us, I wasn’t aware (yet) that some were missing:

  1. Separation of compile and runtime classpath
  2. Separation of compile classpath for each source set
  3. Run tests in debug mode
  4. Run tasks on Eclipse auto-build

And, to not-as-critical extent:

  1. Run tasks on project synchronization
  2. Preferences API integration

I am not sure if we could help with all of these but, at the very least, I can vote for them as we are hitting those use cases today and would need a replacement before we move on to Buildship.