Launch and Debug from within Eclipse

[tschulte]

Currently it is only possible to launch an application using ./gradlew run. To debug, you have to use ./gradlew debug and attach a remote debugger.

This also means there is no support for hot code replacement.

I was experimenting with creating a launch configuration using org.eclipse.equinox.launcher.WebStartMain as main class, program arguments -application org.eclipse.e4.ui.workbench.swt.E4Application -product appid.productid -user @user.home/.kratzer/user -data @user.home/.kratzer/data -configuration @user.home/.kratzer/configuration and vm arguments -Djnlp.osgi.bundles=org.eclipse.core.runtime@start,org.eclipse.equinox.ds@2:start,org.eclipse.equinox.common@2:start -Djnlp.org.eclipse.update.install.features=true -Djnlp.equinox.use.ds=true, because WebstartMain can discover all bundles at runtime, but this did not work, because it expects all dependencies as jars.

I was able to successfully launch the application using a launch configuration with main class org.eclipse.equinox.launcher.Main and program arguments -application org.eclipse.e4.ui.workbench.swt.E4Application -product appid.productid -user @user.home/.kratzer/user -data @user.home/.kratzer/data -configuration ${project_loc:projectname}/build/run/configuration. But this only works after having executed ./gradlew prepareRunConfig. Also this does not allow hot code replacement, because after every change, prepareRunConfig has to be executed.

Another idea is to use the Eclipse PDE tools:

apply plugin: 'eclipse'
eclipse {
    project {
        natures 'org.eclipse.pde.PluginNature'
        buildCommand 'org.eclipse.pde.ManifestBuilder'
        buildCommand 'org.eclipse.pde.SchemaBuilder'
    }
    classpath {
        containers 'org.eclipse.pde.core.requiredPlugins'
    }
}

But I think this assumes that there is the META-INF/MANIFEST.MF and build.properties in the root dir. I have just happily removed these two files.

Is there any way for being able to run or debug an application build with wuff from within eclipse with hot code replacement?

[mcmil]

At some level it is possible to do this in Intelli J IDEA. I am able to add a gradle run task, start it in debug and Intelli J automatically connects a remote debugging session. It allows me to replace code on the fly (after hitting Build/Compile) in handlers, renderers etc. The problem is that there is no support for editing E4 specific files in Intelli J (like Application.e4xmi).

The biggest problem, I think, its the startup time - currently between hitting the Run task from the IDE and seeing the app it takes around 15-20 seconds. Way longer than in plain PDT. I think that your proposition with a main class could somehow speed up the process. I'll try to look into the idea with org.eclipse.equinox.launcher.Main.

[akhikhl]

Regarding hot reload: I used springloaded library in another project, Gretty: https://github.com/akhikhl/gretty How springloaded works:

1. You must add '-javaagent:pathToSpringloaded', '-noverify' to jvm args (where pathToSpringloaded must be replaced with file path to springloaded jar).
2. You are expected to compile .class files (for example, via gradle "classes" task). Effect: As soon as some .class file is changed, springloaded automatically reloads the class within running program. Please try it and let me know, if it helps improving development/debugging lifecycle for you. I would even consider integrating springloaded support into Wuff.

[tschulte]

I might have a look at this later. But I think ./gradlew classes will not suffice, because the run configuration does depend on the jars. Does springloaded also work with changed jars? The question is if it does also work in OSGI? In any case, having to call gradle to see the effect of a change is less direct than just having to save the file. I'm used to just save the file.

So for now it seems using wuff as direct replacement for tycho with build.properties, manifest.mf, manifest-first dependencies, etc. and configuring the target platform in eclipse will get the best results. But this does not work when having dependencies on non-osgi artifacts.

Another way might be to have a look at the platform source code to see how it manages to use a project as OSGI-bundle.

[akhikhl]

I will think in the direction of general solution for OSGi-aware hot reloading.

[mcmil]

I've managed to implement an Intelli J plugin that reloads the classes in the bundles pregenerated by Wuff. The application can now be restarted without invoking a gradle build, as long as you don't mess with dependencies and manifests (in that case, a prepareRunConfig execution is required). It still needs some work, but I think for me it will solve the most problematic issue (long startup time for developers). It is a little hacky, because I rebuild the jars using IntelliJ's compiler output, but well... it works for now.

Maybe something similar could be done for Eclipse? I've published the project on github. I'll try to prepare some samples this week and finish up the existing issues. I was checking it out using Your contact-griifon project tschulte. I must say it was a great help for me when I've tried to startup e(fx)clipse with Wuff, thanks for publishing :)

[akhikhl]

@mcmil , did you succeed starting e(fx)clipse under Wuff? And, yes, what you say is cool news!

[mcmil]

Yes, It works flawlessly. Last week I've ported our project (around 33 subprojects) from Tycho + Eclipse Target Platform to Wuff. The frontend is on e(fx)clipse on Java 8 and backend is a Java EE 7 application. Everything is built by gradle (was maven earlier), and we even use some external libs (Tyrus, Jersey and others), which are not available on update sites.

The only real barrier for adoption was the startup time. On eclipse it was basically instant. With gradle we have around 15 seconds overhead for every run. I hope, that with the Intelli J plugin I'll be able to fix it up - maybe someday even with the manifest generation. HotSwap and debug works out of the box on Intelli J so thats not an issue :) Probably we will need some e4xmi editors too, but thats not a big problem.

Edit: And as I said - I'll try to prepare some samples later this week, with up and running e(fx)clipse under Wuff (although I am relying heavily on the samples provided by @tschulte - maybe it can be done in another way).

[tschulte]

@mcmil, that sounds a lot what we were doing (JEE server, Tyrus, Jersey, etc.). Only we were doing Java 7 and SWT. But now management killed the project. So I am back to only doing it in my spare time. And there I just moved to IntelliJ. I will have a look at your plugin.

[mcmil]

@tschulte I've added a sample of my current Wuff build script for e(fx)clipse. Its based on your initial contacts-griffon build. Its available at wuff-efxclipse-samples - not much currently, but will start with run task - I'm using it to test my intellij plugin. Maybe you'll find it useful.

[aalmiray]

@mcmill: I made and attempt to run the application on OSX, Gradle 2 and JDK8u20. Unfortunately the run task hangs indefinitely. HEAD is at 67e2f39bf7e64aa9d58b6373f35fa7a985a2ec49

[mcmil]

@aalmiray I'm not sure whats the status of e(fx)clipse on OSX - I think there were some issues in the past. I'll try to reproduce the problem today on linux and newest jdk8u20 and I'll let you know if I had any luck. I don't have access to any OSX instance unfortunately.

[aalmiray]

@mcmill: thanks! I also stumbled upon your wuff-intellij-plugin. Unfortunately I can't get it to work on OSX too. Tried old and alpha versions with IntelliJ 13.1.4 :crying_cat_face:

[mcmil]

@aalmiray: We use it on multiple machines, but unfortunately only on Windows. I'll try to get it up and running on Linux, and hopefully OS X will work too :)

[mcmil]

@aalmiray: I've tested e(fx)clipse with wuff on Ubuntu and JDK8u20. Worked straightly from ./gradlew run without any issues. I'll try to get an access to an OS X instance to reproduce it, but if you have any debug information both on the plugin or e(fx)clipse (from --debug or --info) let me know.