Group items tagged

Vaadin is a Rapid Application Development (RAD) framework for RIA applications. I only know it for a few months but since I started experimenting with it, I'm really in favor of it. I see a lot of advantages compared to Sun's Java EE standard front-end framework JSF. First of all Vaadin is a java library, so you only have to write Java to build a complete frontend. No need for a specific frontend language, no need for converters (for comboboxes),… This also implies that you can use the full Java power on the frontend side and that's an huge advantage because frontend code is now type-safe and easily refactorable. You can unit test your frontend with JUnit. You can also use all existing java libraries on the frontend side, for example LOG4J. Another advantage is the fact that Vaadin is easy to learn (JSF isn't!) and to use: it's straigtforward. It feels like developing desktop apps and for me developing desktop apps feels much more intuitive than developing web-apps the way I'm used to. Vaadin uses convention over configuration. No need to register new components, validators or whatever in different xml files. Themes have a default folder and a default folder structure. Vaadin is very well documented. There's the book of Vaadin wich explains every aspect of the framework very clear. On the site there's a blog, a FAQ section, a wiki, a forum, examples with Java source code, … It's very easy to extend. Want to create your own Validator? Just implement an interface or extend another Validator and use it. Want to create your own custom server side component? Just extend the CustomComponent class or extend from another component. There's also an add-on directory where you can download UI components, data components, tools, themes, …

"The past year I've been learning a lot of Scala and I'm currently working on a new project using Scala. I use LiquiBase, which is a database-independent library for tracking, managing and applying database changes. I'm also using the simple-build-tool (SBT) for my project. So I've put together a little SBT plug-in for running LiquiBase maintenance commands (update, rollback, …) from within SBT. For example, whenever I want to apply new database changes with LiquiBase I can now simply run sbt liquibase-update which sets up a new instance of LiquiBase and executes the LiquiBase update command which migrates my database to the latest version. At the moment the plug-in supports the following commands: liquibase-update, liquibase-drop, liquibase-tag, liquibase-rollback and liquibase-validate. What are the benefits of using the plug-in and not just the LiquiBase CLI? * no download/install of LiquiBase * classpath handled by SBT * no need to provide a big list of parameters or writing shell scripts The plug-in is called liquibase-sbt-plugin and you can find it here on GitHub. Feel free to use it or fork it and suggest changes. I'm still relatively new to Scala and especially SBT so any remarks are very welcome."

Last weekend while pondering the question "Is Scala ready for the enterprise?" I decided to write a simple Java EE 6 app entirely in Scala, without using any Java. I had three main reasons for doing this: one was just to see how easy/difficult it would be to write everything in Scala (it was easy).  Another was to document the process for others journeying down the same road (the entire project is on github).  Finally, I wanted to identify advantages of using Scala instead of Java that are specific to Java EE apps (I found several). Background The specific app I created was an adaptation of the Books example from Chapter 10 of Beginning Java™ EE 6 Platform with GlassFish™ 3. It's a simple web app that displays a list of books in a database and lets you add new books. Although it's a pretty trivial app, it does touch on several important Java EE 6 technologies: JPA 2.0, EJB 3.1 and JSF 2.0.

JSF 2.0, CDI, Scala 2.8 using Eclipse, Maven and Tomcat Tools used: * JDK 1.6 * Maven 2.2.1 * Eclipse 3.5 * Eclipse Scala plugin (I am using nightly build - http://www.scala-lang.org/scala-eclipse-plugin-nightly) * m2eclipse plugin Download the source from here

I am working on a web site that will help students practice their Scala programming skills. As I labored along, writing my JSF app code, I thought "this is silly-why not practice Scala at the same time?" But I like JSF and wasn't ready to jump to Lift or Vaadin. With Eclipse, this isn't all that hard. Install the Java plugin. Make a dynamic web project in the usual way, using the Java EE perspective. Then, switch to the Scala perspective, right-click on the project, and, if all planets are aligned correctly, you will get a menu item "Add Scala nature". (If they are not, see here for a manual approach.) Add your managed beans as Scala classes. Finally, switch back to the Java EE perspective, select the project properties, and add the Scala library JAR as a Java EE module dependency. But I like NetBeans and wasn't ready to switch to Eclipse. (Unfortunately, JSF 2 support in Eclipse is pretty minimal, the Glassfish integration is a bit flaky, and the Scala plugin has very little usable code completion.) NetBeans doesn't let me add a "Scala nature" to a web project. If I add Scala files to the project, I can edit them with the Scala editor, but they just get copied to the WAR file, without any compilation. I had one look at the Ant scripts for a Scala and a web project and decided that I wasn't going to figure out how to merge them. This blog shows how you can use Maven to make a mixed Scala/Java project in NetBeans. So I gathered up JSF and Scala pom.xml files from here and here, cut out the considerable crud from the JSF POM file that was probably meant for supporting Tomcat, and merged the results to the best of my ability-see below. You use the usual Maven directory structure, but with a src/main/scala directory instead of src/main/java:

Google provides a scalable application hosting environment called Google App Engine (GAE). One of the many benefits of GAE is that hosting small scale applications is 100% free. Google starts charging for hosting when your application resource requirements start to grow.

There is no migration system in vanilla grails (although possibly in Grails 2.0 …. ?) but there do exist several plugins that provide  some migration functionality. As of this post I am aware of three: dbMigrate, Liquibase, and Autobase. Of these, I prefer Liquibase and cannot recommend it enough. While it uses XML to describe its changesets it is a mature open-source Java project that works flawlessly (and has some excellent documentation). I did not have much luck using DbMigrate and Autobase when including in an existing project… which is a shame as Autobase (which is built on Liquibase) uses a nice DSL syntax to build the migrations.

DdlUtils is a small, easy-to-use component for working with Database Definition (DDL) files. These are XML files that contain the definition of a database schema, e.g. tables and columns. These files can be fed into DdlUtils via its Ant task or programmatically in order to create the corresponding database or alter it so that it corresponds to the DDL. Likewise, DdlUtils can generate a DDL file for an existing database. DdlUtils uses the Turbine XML format, which is shared by Torque and OJB. This format expresses the database schema in a database-independent way by using JDBC datatypes instead of raw SQL datatypes which are inherently database specific. An example of such a file is:

"I've had an opportunity recently to work on a product that needed an RIA web interface, and I chose my recent favorite tool for this, Vaadin. The services for this project needed to be highly scalable, and lent themselves well to functional techniques, so I selected Scala as my language of choice. I build my projects with Maven, for reasons I won't go into right now, and I do much of my JVM-language work in Intellij's excellent IDEA IDE. Given these tools, I found a way to facilitate very rapid development of web UI's, and I thought I'd pass it along. Another technique I use, which I'll expound on later, is creating "dummy" implementations of all of my backing services for my application. The "real" implementations are written as OSGi services, in separate modules from my UI. The UI is packaged as a war, but is also OSGi aware, with a bundle activator. This activator only gets called if the war is deployed into an OSGi container, and not otherwise. This allows the app to select which implementation of the services it uses - the "dummy" ones when it's deployed outside of OSGi, and the "real" ones when they're available. This means I can use the handy Maven jetty plugin to quickly spin up my application and test it on my local workstation, without needing all of the dependencies (like a data store and such) of my real services. That's good, in that I can get my "cycle time" down to a few seconds, where "cycle time" is the time between making a change and actually being able to test it in my browser. We can do better, though. I'm using Scala as my language of choice for building the UI as well, as it works just fine with Vaadin (and with everything else in the JVM ecosystem, for that matter, which is why I didn't choose a non-JVM language - but that's yet another rant). I compile my Scala with the Maven scala plugin - here's where the next handy bit comes into play. Turns out the Scala plugin has a goal cal

"Neo4j is a graph database. It is an embedded, disk-based, fully transactional Java persistence engine that stores data structured in graphs rather than in tables. A graph (mathematical lingo for a network) is a flexible data structure that allows a more agile and rapid style of development."

"A lot of people have asked me to document the reasons I want to migrate Hibernate from Maven to Gradle as its build tool so I enumerate those reasons here. If you are completely new to Gradle, I suggest having a look at their overview page. Up front I want to point out that this is not intended as a "Maven bash session" nor as a means to directly compare Maven and Gradle. It is just a means to describe the issues and frustrations I have seen in my 2.5+ years of using Maven for Hibernate builds; in many cases the cause is simply an assumption or concept in Maven itself which did not line up cleanly with how I wanted to do build stuff in Hibernate. Some of the list aggregated by Paul comes directly from Hibernate use-cases; I'd suggest reading through those as well. It is also a means to describe why I decided on Gradle as opposed to other related build tools out there now (Buildr, SBT, etc). Note that there is a comparison wiki between Gradle and Maven, but that it is quite old and out of date in many respects especially in regards to Gradle. The issues I had with Maven (note that these are largely chronological, not in order of "importance") are as follows:"

"A better way to build. Project automation is essential to the success of software projects. It should be straight-forward, easy and fun to implement. There is no one-size-fits-all process for builds. Therefore Gradle does not impose a rigid process over people. Yet we think finding and describing YOUR process is very important. And so, Gradle has the very best support for describing it. We don't believe in tools that save people from themselves. Gradle gives you all the freedom you need. Using Gradle you can create declarative, maintainable, concise and highly-performing builds. "

The default EMF UML2 repository implementation was changed from UML2 1.x to UML2 2.x, in order to support the most current versions of the MagicDraw and Rational tools. Due to conflicting dependencies in the uml libraries, both implementations could not be supported at the same time.

""Coming from desktop application development, I have found the IT Mill Toolkit [Vaadin] to be a lot of help in the transition to web application development. With the toolkit, writing AJAX enabled web applications is as easy as writing Swing based GUI code. It hides so many frustrating details, and handles browser independence so I don't have to worry about it. Using the toolkit makes it quite easy for me to write sophisticated web applications." Bo Thorsen, Monty Program AB"

Apache ServiceMix is an open source ESB (Enterprise Service Bus) that combines the functionality of a Service Oriented Architecture (SOA) and an Event Driven Architecture (EDA)  to create an agile, enterprise ESB. Apache ServiceMix is an open source distributed ESB built from the ground up on the  Java Business Integration (JBI) specification JSR 208 and released under the Apache license. The goal of JBI is to allow components and services to be integrated in a vendor independent way, allowing users and vendors to plug and play.

Gaelyk is a lightweight Groovy toolkit for Google App Engine Java. Gaelyk lets you deploy small applications on Google App Engine Java. Gaelyk gives you the choice to use Groovy for developing your applications. Gaelyk builds upon Groovlets. and the Groovy template servlet Gaelyk allows you to cleanly seperate your views with Groovy templates and your actions in Groovlets. Gaelyk simplifies the usage of the Google App Engine SDK by providing more concise and more powerful shortcuts when using the datastore, memcache, the blobstore, the images service, the URL fetch service, when sending and receiving emails or Jabber messages, and much more. Gaelyk lets you define friendly REST-ful URLs thanks to its URL routing system Gaelyk provides a simple plugin system for improving code reuse and code sharing You can: download Gaelyk in the download area, learn how to create Gaelyk applications by reading the extensive tutorial, and participate in the community.

A few weeks back, I wrote a blog entry lamenting the attitude toward IDEs in the Scala community. A few people told me that the tooling situation was better than I'd implied, so I thought I'd spend a bit of time looking at using Scala (and Lift specifically) in Eclipse. I think the situation is still a ways away from the tooling situation for Java, but it is actually quite good, and I wanted to post a quick tutorial for those interested in developing Lift in Eclipse. Prerequisites This post assumes that you already have Scala 2.8 final and Eclipse 3.6 on your system. For Eclipse, I recommend upping the Xmx setting if you haven't already - I had issues when I had multiple Lift projects imported with Xmx set to 386. Also, this tutorial is going to use Maven, not SBT. SBT may be a better build tool for Scala projects, but I'm not sure how well it works with m2eclipse - I'm going to play with that more later. I also assume you know how to install plugins into Eclipse - I will create a more in-depth screencast for doing all of this if there is enough interest.

In this article I'll describe the setup I use to do develop Lift applications. While more heavy-weight than if an interpreted language is used, I find this setup provides fairly decent turnaround times. So, it took a little longer than expected to write this article which continues where the previous stopped. But all good things come to he who waits The software used in the previous article all had major updates in the meantime: Scala 2.8 (2.8.1 is just around the corner) Eclipse 3.6 Scale IDE for Eclipse (though a nightly build is currently needed for Eclipse 3.6) Gradle 0.9 RC1 Lift 2.1 RC2