Making GWT DevMode embedded Jetty server play with Vaadin
Vaadin can be of great help if you need to develop web application quickly and without much effort. Of course, there is a price to pay (like performance, scalability, etc.) but in overall it’s a quite interesting framework.
One thing I was not expecting to see was necessity to store results of GWT widgets compilation inside <web application root>/VAADIN/widgetsets directory. At first, this seems like not a big deal. But eventually it becomes clear that running both GWT hosted mode shell and external web server (as shell’s -war parameter points to web application root and GWT output directory (which in case of Vaadin differs), prohibiting embedded servlet container from correct work) is a bit odd.
So, the trick is to specify correct <web application root> directory and use it through custom servlet container launcher (source code is available here). I’ve used it on Intellij IDEA but same should apply to Eclipse, as launch configurations are similar.
Intellij IDEA Run Configuration example (Application type):
Main class: com.google.gwt.dev.DevMode
VM parameters: -Ddev.mode.app.root=target/project-name
Program parameters: -server com.github.shyiko.gists.vaadin.DevModeJettyLauncher -war target/project-name/VAADIN/widgetsets com.example.ProjectNameWidgetSet -startupUrl http://localhost:8888/
If you do not want to build vaadin-gwt-jetty-launcher.jar yourself take it from here. It should be available on the classpath when GWT shell starts.
Intellij IDEA native2asciiplug
One of the projects I’m currently working on uses i18n property files through ResourceBundles. Those files contain non-ASCII characters and as a result should be converted before loading. Under Intellij IDEA there is Native2Ascii plugin. The problem is – it wasn’t updated for years and is not compatible with IDEA 9+ (previous versions?) and Maven plugin (which runs it’s own ClassPostProcessingCompiler). Thus I wrote native2asciiplug which during compilation phase automatically converts property files with native-encoded characters. One-click installation and no additional work.
Cheers 😉
Achieving Gradle code completion through GroovyDSL in Intellij Idea
Recently I’ve came across quite an interesting topic Scripting IDE for DSL awareness. In a nutshell, it’s about using GroovyDSL in conjunction with Intellij Idea open API. The reason I became instantly interested in it was that one of the projects, I’m currently working on, uses Gradle as a build tool. It’s very powerful and promising alternative to the Maven, Ant+Ivy, Gant, etc. But it has no code completion support in Intellij Idea and as far as I know same applies to Eclipse.
So, in an half of an hour or so I came up with the code below.
/**
* @author Stanley Shyiko <stanley.shyiko[at]gmail.com>
*/
def injectMethods(def builder, def fullClassName) {
def psiClass = builder.findClass(fullClassName)
psiClass?.methods.each {
if (it.containingClass.name != 'Object') {
def params = [:]
it.parameterList.parameters.each {
params[it.name] = it.type.canonicalText
}
builder.method name: it.name, type: it.returnType.canonicalText, params: params
}
}
}
def scriptName = 'build.gradle'
def projectContext = context(scope: scriptScope(name: scriptName))
contributor(projectContext) {
injectMethods delegate, 'org.gradle.api.Project'
}
def closureContext = context(ctype: 'groovy.lang.Closure', scope: scriptScope(name: scriptName))
def methodClosureTypeMap = [
'repositories': 'org.gradle.api.artifacts.dsl.RepositoryHandler',
'dependencies': 'org.gradle.api.artifacts.dsl.DependencyHandler',
'copy': 'org.gradle.api.file.CopySpec',
'fileTree': 'org.gradle.api.file.ConfigurableFileTree',
'javaexec': 'org.gradle.process.JavaExecSpec',
'exec': 'org.gradle.process.ExecSpec',
'buildscript': 'org.gradle.api.initialization.dsl.ScriptHandler'
]
contributor(closureContext) {
for (e in methodClosureTypeMap) {
if (enclosingCall(e.key)) {
injectMethods delegate, e.value
break
}
}
}
Just save it as a build.gdsl (or whatever you like as long as extension is gdsl) to the project’s source directory so that Intellij Idea activated it (you may need to activate it yourself by hands – just click Activate link once you open this file). As an example, I keep it in <project_dir>/<some_module>/src/main/groovy. You can also save it to <IDEA_HOME>/plugins/Groovy/lib/standardDsls directory. Doing this way will free you off the obligation to activate it by hands and necessity to include to every project that makes use of Gradle.
It doesn’t provide support for custom configurations, artifacts recognition. Its purpose was solely to give a basic (even though, the only one you can get so far) code completion for gradle build scripts. You are free to modify it whatever you like. The result of its work is provided in the picture below.
NOTE: If code completion isn’t working after you have either activated build.gdsl or added it to the standardDsls directory – just make sure you have Gradle libraries in classpath.
Yet another Java Server-Side Testing framework
I believe everyone at least once heard of Apache CACTUS project. It’s goal is to provide server-side testing facilities. While it works perfectly well in some situations, there is a serious problem with it – it is tied to JUnit 3. Of course, it may not be the case for everyone but personally for me, being more allegiant to the TestNG, it is.
Because of that, I’ve decided to write new java server-side testing framework, named JSST. It’s not coupled to JUnit 3.x and can be used in conjunction with any testing framework, e.g. JUnit 4, TestNG. In a nutshell, all the magic is made behind the scenes by AspectJ and all you need is just to add LTW as a java agent, create few files and make NO changes to the regular tests you’ve already wrote. For more information please refer to the online documentation and samples from distribution.
Project’s source code, ready-to-use distribution and wiki are available at https://github.com/shyiko/jsst. Feel free to ask any questions with regard to JSST. Any suggestions are also highly appreciated.
Stanley Shyiko's Blog 