The second build of Vaadin 7 beta is already out and we are steadily approaching the 7.0. One of the targets for the final 7.0 release is that we have converted the official and certified add-ons to be compatible with the new APIs. This is work-in-progress and that is why you will see a lot of updates in the Directory in the following weeks.
The other side of the story is that there are well over 250 contributed add-ons for Vaadin available today. This is one great achievement from the open source community.
However, most of these 3rd party add-ons are only compatible with Vaadin 6. Vaadin 7 will be such a big update that they will not work without some changes and rebuild. What we want to do is to help add-on authors in their effort to make their add-ons compatible with Vaadin 7 as early as possible.
As a first aid I have, together with my colleagues, started to go through my own add-ons and finding out best (or sometimes the only) way to make them Vaadin 7 compatible. Here are some of our findings and ideas to help you.
Start with tooling
One of the changes you will encounter is that Vaadin 7 will is now packaged in separate jar files. This makes perfect sense with dependency tools like Maven and Ivy, but it might feel little overwhelming for a single-jar enthusiast like me. For larger projects this most likely isn't any problem as they already tend to use a dependency tool or another.
Overall, my suggestion is to just go for it. The current set of dependencies makes it too hard to track jar files by hand. And really, if you want to support people using these tools you should see how they do it.
Get yourself a branch - or a new project
One of the first things you will notice that you cannot build an add-on that supports both Vaadin 6 and 7 at the same time. The naming of classes and some of the concepts are so different that you are better off by starting over. Existing Maven users may only need a branch, but changing the directory layout completely you might consider creating a completely new project setup.
(Note: If you completely start over there is a Vaadin add-on Maven archetype that should use, but at the time of writing this it still does not support Vaadin 7.)
Structure your code
First, Maven suggests a directory layout that you should try follow. It clearly separates the source code from the test code and build results. And hopefully encourages you to do some more testing.
Secondly, the client-server communication layer is redesigned in Vaadin 7 widgets. This suggest you to create a Java packages for client, server and shared classes. This makes perfect sense if you have done your widgets like you should have: a separate GWT widget together with a Vaadin server-side API and client-side integration. And if you haven't built you widgets properly, this is also a good time to start doing so.
Getting into the good stuff
Once you have revised your mindset, the good news is that there are many features in Vaadin 7 that will actually make the add-on author's life a lot easier. For example the state is much easier to synchronize and there is now support for invisible client extensions. Actually making some of my add-ons obsolete on Vaadin 7. And this is nice thing from maintenance point of view.
This blog post was titled "Part 1" suggesting that there will be a sequel. In the next part we dig a little deeper and go through some of the API changes introduced by the new major.
Stay tuned for part two!