Project Avatar was open sourced at this year’s JavaOne Conference, but the framework has been under development for a while, and was first announced at JavaOne in 2011. The primary purpose of Avatar is to give Enterprise developers the ability to develop “modern” applications with Java EE 7, by leveraging much of the “Future Tech” that EE 7 brings to the enterprise realm.
Developing applications under Glassfish presents its own set of challenges for those developers coming from a more-contained development experience. Having developed Grails applications on the regular for the past few years has definitely spoiled me to the seamlessness of the embedded container during development and testing. Even developing Java EE web applications is pretty easy if you are able to benefit from an embedded container like Jetty or Tomcat. Suffice it to say, the process to get Glassfish up-and-running is less streamlined than a simple grails run-app.
Nevertheless, the appeal of Avatar was enough for me to undertake getting Glassfish going, so that I could see if the framework lives up to its promise. My final assessment of the framework is that it does deliver on its sales pitch, and it is very exciting to see Oracle moving the direction of polyglot implementations on the JVM. I’ve been very opinionated, and remain to be, on the matter that I believe that the web frameworks that will win in the long-run are those that are able to support a variety of languages in their application implementations. Seeing Avatar as the premise to that future is validating, and a welcome refreshment to the enterprise web development space.
However, I was still faced with the problem of bootstrapping a development environment that would make me as productive with Avatar as I am with other frameworks. Luckily, the Glassfish developers have gone to the extent to provide an all-inclusive embedded artifact, which can be used to fire-up a standalone container instance. Though perhaps not as perceptually seamless or streamlined as its counterparts in the field (and certainly not as well documented), after much trial and error, I was able to produce a project under Gradle that leveraged the embedded context for compilation and development runtime. The result is a project structure where I can write, compile, and archive Avatar applications.
The project defines a source directory under src/main/avatar, which is where the Avatar application code and resources are homed. The run task is handed off to the com.objectpartners.avatar.Main class, which is what’s responsible for bootstrapping the Glassfish container and deploying our application.
As expected, the verbosity of code for this process is greatly reduced when utilizing Groovy, so that is the core-language of choice in this example. Given that the Gradle task is simply a JavaExec type, any runnable Java class will do.
You may notice from the project build file that some of the dependencies are resolved from the lib directory of the project. The reason for this is that (at the time of this writing) the Avatar artifacts are not available in a Maven repository. Given that, you’ll have to download a zip file of the project and extract it somewhere. Once it’s extracted, you can copy all of the jar files from the glassfish4/glassfish/modules/ directory into your project’s local lib directory.
When you’re ready to go, you can write your Avatar application and fire it up with gradle run.
I’ll be delivering a webinar this week on developing web applications in Avatar, which will demonstrate its features and functions. All of the project demos will be self-contained and runnable given the above project configuration. If you or your organization are interested in the webinar or Project Avatar, please do not hesitate to contact us today!