Archive

Posts Tagged ‘vaadin’

Devoxx France 2013 – Day 1

March 28th, 2013 No comments

Rejoice people, it’s March, time for Devoxx France 2013! Here are some notes I took during the event.

Java EE 7 hands-on lab by David Delabasse & Laurent Ruaud

An hands-on lab by Oracle for good old-fashioned developers that want to check some Java EE 7 features by themselves.

This one, you can do it at home. Just go to this page and follow instructions. Note you will need at least Glassfish 4 beta 80 and the latest NetBeans (7.3).

You’d better reserve a day if you want to go beyond copy-paste and really read and understand what you’re doing. Besides, you have to some JSF knowledge if anything goes wrong (or have a guru on call).

Angular JS by Thierry Chatel

The speaker comes from a Java developer background. He has used Swing in the past and since then, he has searched for binding features: a way to automate data exchange between model and views. Two years ago, he found AngularJS.

AngularJS is a JavaScript framework, comprised of more than +40 kloc and weights 77 kb minified. The first stable version was released one year ago, codenamed temporal-domination. The application developed by Google with AngularJS is Doubleclick for publishers. Other examples include OVH’s future management console and Youtube application on PS3. Its motto is:

HTML enhanced for web apps

What does HTML enhanced means? Is it HTML6? The problem is HTML has never been designed to create applications: it is only to display documents and link between them. Most of the time, one-way binding between Model & Template is achieved to create a view. Misko Hevery (AngularJS founder) point of view is instead of trying to go around this limitation, we’d better add this feature to HTML.

So, AngularJS philosophy is to compile the View from the Template, and then 2-way bind between View & Model. AngularJS use is easy as pie:

Yout name: <input type="text" ng-model="me">
Hello {{me}}

AngularJS is a JavaScript framework, that free developers from coding too manyJavaScript lines.

The framework uses simple concepts:

  • watches around expressions (properties, functions, etc.)
  • dirty checking on events (keyboard, HTTP request, etc.)

Watches are re-evaluated on each dirty checks. This means expressions have to be simple (i.e. computation results instead of the computations themselves). The framework is designed to handle up to 2000 simple watches. Keep note that standards (as well as user agents) are evolving and that ECMAScript next version will provide Object.observer() to handle x50 the actual number of watches.

An AngularJS app is as simple as:

<div ng-app="myapp"></div>

This let us have as many applications as needed on the same page. AngularJS is able to create single-page applications, with browser navigation (bookmarks, next, previous) automatically handled. There’s no such thing like global state.

AngularJS also provides core concepts like modules, services and dependency injection. There’s no need to inherit from specific classes or interfaces: any object is available for any role. As a consequence, code is easily unit-testable, the preferred tool to do this is Karma (ex-Testacular). For end-to-end scenarii testing, the same dedicated tool is also available, based on the framework and plays tests in defined browsers. In conclusion, AngularJS is not only a framework but also a complete platform with the right level of abstraction, so that developed code is purely business.

There are no AngularJS UI components, but many are provided by third-party like AngularUI, AngularStrap, etc.

AngularJS is extremely structuring, it is an opinionated framework. You have to code the AngularJS way. A tutorial is readily available to let you do that. Short videos dedicated to a single focused theme are available online.

Wow, this the second talk I attend about AngularJS and it looks extremely good! My only complaints are that is follows the trend of pure client-side frameworks and that is not designed for mobile.

Gradle, 30 minutes to change all by Sébastien Cogneau

In essence, Gradle is a Groovy DSL to automate build. It is extensible through Java & Groovy plugins. Gradle is based on existing principles: it let you reuse Ant tasks, it reuses Maven convention and is compatible with both Ivy & Maven repositories.

A typical gradle build file looks like this:

apply plugin: 'jetty'

version = '1.0.0'

repositories {

    mavenCentral()
}

configuration {
    codeCoverage
}

sonarRunner {
    sonarProperties {
        ...
    }
}

dependencies {
    compile: 'org.hibernate:hibernate-core:3.3.1.GA'
    codeCoverage: 'org.jacoco....'
}

test {
    jvmArgs '...'
}

task wrapper(type:Wrapper) {
    gradleVersion = '1.5-rc3'
}

task hello(type:Exec) {
    description 'Devoxx 2013 task'
    group 'devoxx'
    dependsOn wrapper
    executable 'echo'
    args 'Do you have question'
}

Adding plugins add tasks to the available build. For example, by adding jetty, we get jettyStart. Moreover, plugins have dependencies so you also have tasks from dependent plugins.

Gradle can be integrated with Jenkins, as there is an available Gradle plugin. There are two available options to run Gradle build on Jenkins:

  • either you install Gradle and configure its installation on Jenkins. From this point, you can configure your build to use this specific install
  • or you generate a Gradle wrapper and only configure your build to use this wrapper. There’s no need to install Gradle at all in this case

Gradle power let also add custom tasks, such as the aforementioned hello task.

The speaker tells us he is using Gradle because it is so flexible. But that’s exactly the reason I’m more than reluctant to adopt it: I’ve been building with Ant for ages, then came to Maven. Now, I’m forced to use Ant again and it takes so much time to understand a build file compared to a Maven POM.

Space chatons, bleeding-edge HTML5 by Phillipe Antoine & Pierre Gayvallet

This presentation demoed new features brought by HTML5.

It was too quick to assimilate anything, but demos were really awesome. In particular, one of them used three.js, a 3D rendering library that you should really have a look into. When I think it took raytracing to achieve this 15 years ago..

Vaadin & GWT 2013 Paris Meetup

Key points (because at this time, I was more than a little tired):

  • My presentation on FieldGroup and Converters is available on Slideshare
  • Vaadin versions are supported for 5 years each. Vaadin 6 support will end in 2014
  • May will see the release of a headless of Vaadin TestBench. Good for automated tests!
  • This Friday, Vaadin 7.1 will be out with server push
  • Remember that Vaadin Ltd also offers Commercial Support (and it comes with a JRebel license!)
Categories: Event Tags: , , ,

Announcing More Vaadin

February 12th, 2012 3 comments

During the writing of ‘Learning Vaadin‘, I had many themes I wanted to write about: components data, SQL container filtering, component alignment and expand ration, separation of concerns between graphic designers and developers, only to name a few. Unfortunately, books are finite in space as well as in time and I was forced to leave out some interesting areas of Vaadin that couldn’t fit in, much to my chagrin.

Give the success of ‘Learning Vaadin’, I’ve decided to create a site that is meant to gap the bridge between what I wanted and what I could: More Vaadin. Expect to see there articles related to Vaadin! I’ve also decided to open the platform to other contributors, for those interested.

As a bonus, this is the first article (original article here).

Table generated buttons

Before diving in the middle of the subject, let’s have a use-case first. Imagine we have a CRUD application and our current screen lists the datastore entities in a table, a line per entity and a column per property.

Now, in order to implement the Delete functionality, we use the addGeneratedColumn method of the Table component to display a “Delete” button, like in the following screenshot:

The problem lies in the action that has to take place when the button is pressed. The behavior needs to be determined when the page is generated, so that the event is processed directly on the server-side: in other words, we need a way to pass the entity identifier (or the container’s item or even the container’s item id) to the button somehow.

The solution is very simple to implement, with just the use of the final keyword, to let nested anonymous class methods access parameters:

table.addGeneratedColumn("", new ColumnGenerator() {

    @Override
    public Object generateCell(final Table source, final Object itemId, Object columnId) {

        Button button = new Button("Delete");

        button.addListener(new ClickListener() {

            @Override
            public void buttonClick(ClickEvent event) {

                source.getContainerDataSource().removeItem(itemId);
            }
        });

        return button;
    }
});

Remember to regularly check More Vaadin for other reindeer articles :-)

Categories: Java Tags:

‘Learning Vaadin’ contest winners

November 28th, 2011 5 comments

Dear readers,

Thanks for your participation in the ‘Learning Vaadin’ contest. It’s my pleasure to announce the winners:

  • Adolfo Benedetti who commented on the integration side of ‘Learning Vaadin’
  • Sebastian who also commented about integration
  • A. Jansenn who noted the Vaadin team is very positive about ‘Learning Vaadin’ and that it’s a good complement to the available documentation

The winners will be contacted by a Packt representative about the details.

The choice was hard and I know there will be some deception for not having won a copy. Nevertheless, you can always purchase the book at Packt or Amazon.

Categories: JavaEE Tags:

‘Learning Vaadin’ is out

October 30th, 2011 8 comments

This is it! After 10 monts of work, my first book is out: ‘Learning Vaadin’ is now available at Packt and Amazon.

First things first, what’s is Vaadin? Vaadin is a presentation-layer web framework that let you easily develop Rich Internet Applications. It does so by provding an abstraction over the Servlet API and by letting developers assemble components to design screens (as opposed to pages as in previous generation web frameworks). If you got 5 minutes to spare, you can go try the tutorial and be convinced yourself. Note that I do not hold Vaadin for a golden hammer, but in most contexts, it just is the right tool.

Now, why write a book? An imperative prerequisite is to believe in the subject. For me, it was love at first sight… I already wrote on Vaadin and used it in real pre-sales demos. During a conversation with Joonas Lehtinen, Vaadin’s CEO, he mentioned he had been approached by Pack to write a book on the subject. My brain processed the information and mere minutes later, I proposed myself.

Although writing a book is like coding in a project in many ways: there’s a schedule, limited time, reviewing (testing), rewriting (bug fixing), ups and downs, it has not been easy for me. I’m admirative of people who regularly write books in their spare time. They need discipline, of course, but also a supportive family and the right publisher. Fortunately, I had these assets this time and I’m now proud to have finished the book.

But is it finished? The strangest is that I do not realize yet. I’m waiting to hold a hard-copy in my hands to really think ‘I’ve done it’. Once received, I believe I will be entitled to some much-deserved R&R :-)

‘Learning Vaadin’ in the news:

You’re welcome to mention other references I may have missed.

Categories: JavaEE Tags:

Vaadin courses on JavaBlackBelt

May 16th, 2011 2 comments

For those of you who haven’t heard of JavaBlackBelt, it’s an e-learning community site. Once registered, users can use the site in a variety of ways:

  • First, one can take courses on a variety of programming-related subjects.
  • Then, one can pass exams on these subjects. Each exam is made of questions one has to anwser in a limited time frame. Passing an exam gives you knowledge points; with enough knowledge points, you get the next belt, until the fabled black belt!
  • One can also contribute to the questions pool. Questions give you contribution points: after a certain belt, one needs paying a certain amount of contribution points in order to pass an exam, thus ensuring you give back to the community.
  • Finally, the last version of JavaBlackBelt – also known as BlackBeltFactory – brings the notion of coach: one can offer and/or receive individual mentoring.

I’m a JavaBlackBelt user since a couple of years. At first, it was in order to get my black belt (boys and their toys). Then, recently, my interest in it was renewed, primarly due to two things:

  • BlackBeltFactory was remade using the Vaadin framework. At this time, it was the biggest reference for Vaadin.
  • Given their freshly acquired Vaadin skills, the BlackBelt team created  a new subject for the community to work on, Vaadin.

Since Vaadin is becoming more and more an option for the presentation layer, at the beginning of the month, JavaBlackBelt announced the addition of Vaadin Advanced Core, in order for the existing Vaadin Fundamentals not to become bloated.

People interested in the effort of creating and reviewing both courses and questions are welcomed (and encouraged) to do so!

PS: remember JavaBlackBelt is first and foremost fun. Don’t take your belts (however high they are) too seriously. John Rizzo, the site’s founder, is only a blue belt while Marko Grönroos, a Vaadin Fundamental leader is white belt. Be humble…

Categories: Technical Tags: ,

New Filter API in Vaadin 6.6

May 2nd, 2011 2 comments

Vaadin is available in version 6.6 preview since this week. Among other interesting enhancements, one surely caught my attention, the new Filter API.

To understand why it’s so interesting, one must know how it’s handled in version 6.5 and before. But first, a word about filters in Vaadin: they are used in containers, which handle collections of items, in order to sort out eligible items. The Container.Filterable interface define a method to add a single filter, whose signature is:

addContainerFilter(Object propertyId, String filterString, boolean ignoreCase, boolean onlyMatchPrefix)

So, we can only filter on string equality, and this equality can be loosened/tightened toward case and position. Morevoer, filters on the same property are additive. If you need to go beyond that, your goose is cooked. In a previous proposal to a request, the filter had to be accent insensitive, which is not supported. I had to hack like mad to implement it. In effect, since most of the container API’s code is private, I copied it to offer the needed option alternative. It did the trick but it’s pretty dirty.

However, the new API supplies a true extensible model for filters which renders my previous development obsolete. Facts worth mentioning are the following:

  • The Container.Filterable interface becomes Container.SimpleFilterable, with no other changes in the method signatures
  • A brand-new Container.Filterable is added, with the method:
  • addContainerFilter(Container.Filter filter)
  • The Filter interface becomes public, and brings an entire hierarchy, with boolean composition in mind (meaning you can OR, AND or NOT you filters in combination). The interface has two methods:
  • appliesToProperty(Object propertyId)
    passesFilter(Object itemId, Item item)

These updates make creating an accent-insensitive a breeze. Conclusion is, if you’re interested in Vaadin, you have to take a look at the new version, if only for the filter API!

To go further:

  • Vaadin 6.6.0 pre1 is available here
Categories: JavaEE Tags:

Learning Vaadin

March 21st, 2011 2 comments

Vaadin is a Rich Internet Application framework in Java that let developers code applications in a very productive way. For more information regarding Vaadin, please consult its site.

When one wants to learn a framework, one needs to read some documentation. In this regard, Vaadin provides plenty resources:

This amount of documentation and its level of quality is rarely seen in OpenSource projects. However, I do think there’s a missing link since the book’s intended audience is developers who will “just” code.

But my experience taught me many will want to go beyond that and understand the big picture as well as nitty-gritty implementation details. In order to provide just this kind of information, I’ve begun the writing of a “Learning Vaadin” book with Packt Publishing, since I believe Vaadin can be be for the presentation layer what Spring was for Java EE: an excellent productivity-oriented tool that ease development. “Learning Vaadin” targets developers who start from the very beginnings but want to deeply understand what they do.

I got excellent working relationship with the Vaadin’s team as well as the support of Joonas Lehtinen, Vaadin’s fater (thanks Joonas for answering my many questions). Book reviews will be done by members of Vaadin’s team.

Writing is well underway, having written 5 draft chapters on a total of 10. You can support me in this new challenge by acquiring a copy of the book when it’s delivered (exp. Jan. 2012) or if you can’t wait, the ebook in RAW (draft) mode is available now! Note that since Vaadin is OpenSource, Packt will pay royalties to the project itself.

Categories: JavaEE Tags:

Second try with Vaadin and Scala

January 31st, 2011 3 comments

My article from last week left me mildly depressed: my efforts trying to ease my Vaadin development was brutally stopped when I couldn’t inherit from a Java inner class in Scala. I wondered if it was an impossibility or mere lack of knowledge on my part.

Fortunately, Robert Lally and Dale gave me the solution in their comments (many thanks to them). The operator used to access an inner class from Java in Scala is #. Simple, yet harder to google… This has an important consequence: I don’t have to create Java wrapper classes, and I can have a single simple Maven project!

Afterwared, my development went much better. I tried using the following Scala features.

Conciseness

As compaired to last week, my listener do not use any Java workaround and just becomes:

@SerialVersionUID(1L)
class SimpleRouterClickListener(eventRouter:EventRouter) extends ClickListener {

 def buttonClick(event:Button#ClickEvent) = eventRouter.fireEvent(event)
}

Now, I can appreciate the lesser verbosity of Scala. This becomes apparent in 3 points:

  • @SerialVersionUID : 10 times better than the field of the same name
  • No braces! One single line that is as readable as the previous Java version, albeit I have to get used to it
  • A conciseness in the class declaration, since both the constructor and the getter are implicit

Trait

CustomComponent does not implement the Observer pattern. Since it is not the only one, it would be nice to have such a reusable feature, in other words, a Scala trait. Let’s do that:

trait Router {

  val eventRouter:EventRouter = new EventRouter()
}

Note to self: next time, I will remember that Class<?> in Java is written Class[_] in Scala. I had the brackets right from the start but lost 10 minutes with the underscore…

Now, I just have to declare a component class that mixin the trait and presto, my component has access to an event router object.

Late binding

Having access to the event router object is nice, but not a revolution. In fact, the trait exposes it, which defeats encapsulation and loose coupling. It would definitely be better if my router trait would use the listener directly. Let’s add this method to the trait:

def addListener(clazz:Class[_], method:String) = eventRouter.addListener(clazz, this, method)

I do not really know if it’s correct to use the late-binding term in this case, but it looks like it, since this references nothing in the trait and will be bound later to the concrete class mixing the trait.

The next stop

Now, I’ve realized that the ClickListener interface is just a thin wrapper around a single function: it’s the Java way of implementing closures. So, why should I implement this interface at all?

Why can’t I write something like this val f(event:Button#ClickEvent) = (eventRouter.fireEvent(_)) and pass this to the addListener() method of the button? Because it doesn’t implement the right interface. So, I ask myself if there is a bridge between the Scala first-class function and single method interfaces.

Conclusion

I went further this week with my Scala/Vaadin experiments. It’s getting better, much better. As of now, I don’t see any problems developing Vaadin apps with Scala. When I have a little more time, I will try a simple app in order to discover other problems, if they exist.

You can find the sources of this article here, in Maven/Eclipse format.

To go further:

Categories: JavaEE Tags: ,

Mixing Vaadin and Scala (with a touch of Maven)

January 24th, 2011 6 comments

People who are familiar with my articles know that I’m interested in Vaadin (see the “Go further” section below) and also more recently in Scala since both can increase your productivity.

Environment preparation

Thus it is only natural that I tried to embed the best of both worlds, so to speak, as an experience. As an added challenge, I also tried to add Maven to the mix. It wasn’t as successful as I had wished, but the conclusions are interesting (at least to me).

I already showed how to create Scala projects in Eclipse in a previous post, so this was really a no-brainer. However, layering Maven on top of that was trickier. The scala library was of course added to the dependencies list, but I didn’t found how to make Maven compile Scala code so that each Eclipse save does the compilation (like it is the case with Java). I found the maven-scala-plugin provided by Scala Tools. However, I wasn’t able to use it to my satisfaction with m2eclipse. Forget the Maven plugin… Basically what I did was create the Maven project, then update the Eclipse configuration from Maven with m2eclipse and finally add the Scala builder: not very clean and utterly brittle since any update would overwrite Eclipse files. I’m all ears if anyone knows the “right” way to do!

Development time

Now to the heart of the matter: I just want a text field and a button that, when pressed, displays the content of the field. Simple enough? Not really. The first problem I encountered was to create an implementation of the button click listener in Scala. In Vaadin, the listener interface has a single method void buttonClick(Button.ClickEvent event). Notice the type of the event? It is an inner class of Button and wasn’t able to import it in Scala! Anyone who has the solution is welcome to step forward and tell it.

Faced with this limitation, I decided to encapsulate both the listener and the event class in two standard Java classes, one in each. In order to be decoupled, not to mention to ease my life, I created a parent POM project, and two modules, one for the Java workaround classes, the other for the real application.

Next obstacle is also Scala-related, and due to a lack of knowledge on my part. I’m a Java boy so, in order to pass a Class instance, I’m used to write something like this:

eventRouter.addListenerVisibleClickEvent.class, this, "displayMessage")

Scala seems to frown upon it and refuses to compile the previous code. The message is “identifier expected but ‘class’ found”. The correct syntax is:

eventRouter.addListener(classOf[VisibleClickEvent], this, "displayMessage")

Moreover, while developing, I wrote a cast the Java way:

getWindow().showNotification(button.getCaption() + " " + (String) field.getValue())

My friend Scala loudly complained that “object String is not a value” and I corrected the code like so:

getWindow().showNotification(button.getCaption() + " " + field.getValue().asInstanceOf[String])

Astute readers should have remarked that concatenating strings render this cast unnecessary and I gladly removed it in the end.

Conclusion

In the end, it took more time than if I had done the example in Java.

  • For sure, some of the lost time is due to a lack of Scala knowledge on my part.
  • However, I’m not sure the number of code lines would have been lower in Java, due to the extra-code in order to access inner classes .
  • In fact, I’m positive that the project would have been simpler with Java instead of Scala (one project instead of a parent and 2 modules).

The question I ask myself is, if Scala cannot extend Java inner classes – and that being no mistake on my part, should API evolve with this constraint? Are inner classes really necessary in order to achieve a clean design or are they only some nice-to-have that are not much used?

In all cases, developers who want to code Vaadin applications in Scala should take extra care before diving in and be prepared to have a lower productivity than in Java because there are many inner classes in Vaadin component classes.

You can find the sources for this article here in Maven/Eclipse format.

To go further:

Categories: JavaEE Tags: , ,

Playing with Spring Roo and Vaadin

January 17th, 2011 6 comments

One year ago, under the gentle pressure of a colleague, I tried Spring Roo. I had mixed feelings about the experience: while wanting to increase productivity was of course a good idea, I had concerned regarding Roo’s intrusiveness. I left it at that, and closed the part of my memory related to it.

Now, one year later, I learned that my favourite web framework, namely Vaadin, had set their sight on a Roo plugin. That was enough for me to get back on my feet and try again. This article tries to describe as honestly as possible the good and the bad of this experience related to both Roo and the Vaadin plugin.

Pure Roo

First of all, I download the free STS 2.5, that includes Roo 1.1.1 and install it. No problem at this time. Then, I create a new Spring Roo project inside STS. Unluckily, STS does not create the default maven directories (src/main-test/java-resources): errors appear in my Problems tab. Trying to solve the project, I type the project command into Roo’s shell inside STS. Roo complains I should give it my top-level package, though I already did that with the wizard. OK, I am a nice guy and do as asked:

project --topLevelPackage ch.frankel.blog.roo.vaadin

This time, Roo successfully creates the aforementioned directories as well as a Spring configuration file and a log4j properties file.

Next step is to create my persistence layer. The use of CTRL+SPACE is real nice and helps you much with command parameters. Combined with hint, it’s real easy to get comfortable with Roo.

persistence setup --provider HIBERNATE --database DERBY

Roo nicely updates my Maven POM and let it download the latest version right dependencies (JPA, Hibernate, Derby, etc.). I can always change version if I need a specific one. It even adds JBoss Maven repo so I can download Hibernate. I just need to update my database properties, driver and URL. Uh oh: when I open the file, I see Roo has strangely escaped colons characters with backslash. I just replace the example escaped URL with an unescaped real one.

Meanwhile, I notice an error in the log: “The POM for org.aspectj:aspectjtools:jar:1.6.11.M1 is missing, no dependency information available”. Roo updated my POM with version 1.6.11.M1. If I check on repo1, the latest version is 1.6.10. Replacing 1.6.11.M1 with 1.6.10 removes the error.

Now would be a good time to create my first entity:

entity --class ~.entity.Teacher --testAutomatically

STS now complains that the target directory doesn’t exist, like before it complained for source directories. In order to remedy to that, I just do as before, I launch an instruction. In this case, I order Roo to launch the tests with the perform test command. In turn, Roo launches mvn test under the hood and Maven does create the target directory.

Entities without fields are useless. Let’s add a first name and a name to our teacher.

field string --fieldName firstName
field string --fieldName name

It would be cool to have courses attached.

entity --class ~.entity.Course --testAutomatically
field string --fieldName name
focus --class Teacher
field set --fieldName courses --type Course

Notice that since Roo works in a contextual manner, I have to use the focus command so that I do not create the courses Set inside the Course class but inside the Teacher class.

Vaadin plugin

Until now, there was nothing about Vaadin. Here it comes: following the instructions from Vaadin’s wiki, I download the latest Vaadin Roo plugin snapshot and put in in my Roo local OSGI repository. In order to the new bundle to be seen by Roo, I have to restart it which I don’t know how to do inside STS. Instead, I restart STS.

There comes the magic command:

vaadin setup --applicationPackage ~.web --useJpaContainer false

This command:

  • adds Vaadin dependency
  • adds web directory with images
  • updates the POM to war packaging

Yet, when I try to add my new web project to Tomcat, STS complains it doesn’t find candidate projects. The problem lies in that Eclipse is not synchronized with Maven and as such, my project lacks the Web facet. The solution: right-click on my project, go to the Maven menu and click on “Update project configuration” submenu. When done, I can add the project to Tomcat like any other web project (since it is anyway).

Starting Tomcat and going to http://localhost:8080/vaadin, I can see Vaadin handling my request. I just miss the views over my entities, which is done with the following:

vaadin generate all --package ~.web.ui --visuallyComposable true

Conclusion

Well, that was quick, if not perfect. I do miss some features in Roo:

As for the Vaadin plugin, it lacks updating Eclipse files after having changed the POM. Someone not familiar with m2eclipse inner workings could lose some time with this behaviour.

On the other hand, I have a simple webapp in a matter of minutes, that I can now update how I choose. CTRL+SPACE and hint are Roo killer features. Moreover, like the Vaadin add-on showed, you can add whatever functionality is lacking with your own plugin (or use one already available). What’s really important for me though, and without it, I wouldn’t even consider using Roo is that it is completely removable in 3 easy steps. As such you can use Roo’s productivity boost, not tell anyone and remove Roo just before passing your project to the maintenance team.

Thanks to Joonas Lehtinen and Henri Sara for their work on Roo Vaadin’s plugin and sending me ahead of schedule the wiki draft explaining the Vaadin part.

Here are the sources for this article in Maven/STS format.

To go further:

Categories: JavaEE Tags: , ,