After many hours of

• acquiring knowledge for the SVN-Git migration
• preparing and doing the SVN-Git migration
• getting acquainted with and learning Apache Maven and the Tycho plugins
• reading poms of other projects (Platform Build [1], Minerva [2])
• structuring and restructuring the Eclipse Scout bundles and features
• normalising lineendings for Git (several times)

Eclipse Scout builds since Kepler M3 CBI-style. So Eclipse Scout is ready for 2013 and 2113 and further into the future – Eclipse Scout is LTS ready [3].

The Adventure Begins

This adventure started with more and more customer of BSI asking about Maven builds and Eclipse Platform switching to Maven/Tycho. Several customers used already Maven to build J2EE projects and wished that our project will be built with Maven or at least not break other Maven builds. For getting LTS ready the Eclipse Foundation suggests or even defines using Maven/Tycho. And finally early 2012 Eclipse Platform started migrating the builds to Maven/Tycho. These three points made it clear for us, that this is the right path to take. Tycho had and may still have some issues — but we have and will find and solve them together with all projects migrating now or soon. Soon Tycho will be as great as we’d all like it to be. Look at the bugfixes and features already implemented in the last two releases [4,5] — and I’m sure more will follow until Kepler. Nice work Tycho Team!

End of june 2012 I started migrating our ant-custom-pde-build-bash-script builds to CBI-style Maven/Tycho builds [6]. This work is based on the migration of the Scout sources from SVN to Git [7].

Migrating from SVN to Git

Although the source history of Eclipse Scout isn’t that long and just starts two years ago [8] we wanted to keep this history and migrate from SVN to Git and not just push the whole source tree into a fresh Git repository. Also I wished to have a valid migration path for other SVN repositories in our company. The migration guide from eclipse.org suggests using svn2git [9]. svn2git does a great job extracting the history of an SVN repository to a git repository. What it lacked was the ability to update a bare Git Repository. Unfortunately Kevin Menard seemed to be under water with other projects or unavailable for other reasons. The svn2git project seemed unattained (Kevin picked up attaining svn2git in october 2012). So I forked it [10] and merged some other forks which added needed functionality and added the ability to update a bare Git repository from SVN (which reminds me to write a pull request).

I was now able to create a Git Clone from a SVN Repository and update it if needed. This laid the groundwork for migrating any SVN Repository to Git at BSI including our Eclipse Scout SVN Repository at eclipse.org. Now began the study how to resolve the old mistakes of committing big binaries into SVN. As SVN doesn’t clone the whole history, this doesn’t hurt a lot. But by moving to Git every binary and its history hurts. Sure, we have now huge disks and Gigabit LAN/WAN, but as everyone wants to have a SSD space gets limited again and sometimes the network isn’t as fast as we’d like to. So relieving the repository of its unnecessary binaries will help. Here is the script I use to get rid of big binaries (any improvements are welcome).

Preparations are done and we where ready for migration. Just one tiny problem: Git isn’t as easy to work with as SVN. Sure many things like branching and merging are faster and easier than svn IF you know how to work with Git. But the daily workflow is different and beside the current project work the developer has to learn and to adapt how to work with Git. So we decided to migrate Eclipse Scout in two steps. First, only the branch for the Kepler release. After Juno SR2 we will move all the other branches and tags to the Eclipse Git Repository and make the SVN readonly.

Shortly after opening the bugzilla request [7] I could push the Kepler branch to the Eclipse Git repositories [11,12]. The groundwork was done for the CBI-build.

To make it possible to merge changes made in the Juno branch to the new Git Kepler branch we have now the following setup. On our SVN repository server is an update script which updates the Git bare repositories from the SVN repositories at Eclipse.org and also from internal repositories. This is done with help of svn2git. From the eclipse repositories the Juno branches are pushed to Github [13] and from here I can add them to the “Remote Repositories” in EGit. Now I’m able to merge new commits from Juno to Kepler.

Migrating from PDE-build to CBI-build

As the process of migrating to Git took quite some time I started learning Maven and migrating the Scout bundles and  features between the migration steps. It helped me a lot, that the Eclipse Platform had already done quite some work for the CBI build. From their parent project I copied a lot which gave me a kickstart. From here, I learned how to manage the maven plugins and create profiles for the singing process.

Build Structure

Like the Platform build we have for the Runtime and SDK bundles two different Git repositories which gave us the possibility to create an aggregator project which contains the parent pom with the build information and where we can add other releng bundles / pom projects. The Runtime and SDK bundles have their own parent which have the aggregator (releng) parent as parent project.

Target Platform

As Eclipse Scout has many dependencies to other Eclipse Projects and 3rd party libraries we need to build p2 repositories. With Tycho it is possible to place the repository informations into the parent pom or use a target file. We chose the second option because the target files can also be used from the IDE to develop and compile Eclipse Scout. As we have customers who use Eclipse Scout based products within IBM Lotus Notes Eclipse Scout has to be compatible with Eclipse >=3.4. To achieve this, there are target files for all platforms from 3.4 up to the current staging.

Challenges

As described by Daniel Wiehl [14] we need two jars (javax.jms_1.1.0.jar, javax.mail.jre16_1.4.3.jar) in the endorsed folder of the JRE. These two jars are also needed at build time. As the build has to work on any machine we can’t rely on having those two jars in place. This means that we have to include and add them into the build process somehow. The next gist shows how you can modify the bootclasspath of the java compiler. There we can add the two jars. The problem is, that this method overwrites the bootclasspath calculated by Tycho (there is already a fixed bug 394387 [15] concerning this. Howerver, I wasn’t able to check it out so far).

Another issue regarding the bootclasspath is that a class in Eclipse Scout makes use of internal stuff located in the tools.jar. The tools.jar isn’t part of the JRE but of the JDK. (The functionality isn’t used in the runtime, its part of the JAX-WS part and used to build sources from a WSDL.) As the tools.jar isn’t in the JRE consequently it isn’t taken into the bootclasspath by default. So we somehow have to “manually” write it into the bootclasspath as the two jars above. What we face here is another problem which I’m not sure is solved by bug 394387 [15]. For the tools.jar we need the path to the java.home directory and from there  (relative) to the JDK and its lib folder. java.home now is the running JRE (which runs maven) and not the one we want to use at compile time (BREE). It works for now, as the used classes and methods aren’t different but this is a ticking time bomb. I hope the aforementioned bug can solve this.

Contributing to Eclipse Scout

According to the main goal of the CBI initiative [16] I hope we have made it easier to contribute to Eclipse Scout. I will update the Contribution Guidelines [17]. Surely the Build is much easier to run on any machine. All things that need a special configuration are put into profiles so a “mvn clean install” can be done by anyone. No prerequisites are necessary.

If you wan’t to know more details to anything concerning the Eclipse Scout CBI Build please do not hesitate to ask via forum or twitter. I’ll be happy to answer the questions.

[1] wiki.eclipse.org/Platform-releng/Platform_Build
[2] wiki.eclipse.org/Minerva
[3] wiki.eclipse.org/LTS
[4] wiki.eclipse.org/Tycho/Release_Notes/0.16
[5] wiki.eclipse.org/Tycho/Release_Notes/0.17
[6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=384958
[7] https://bugs.eclipse.org/bugs/show_bug.cgi?id=384960
[8] git.eclipse.org/c/scout/org.eclipse.scout.rt.git/commit/?id=3f93b1c1c7b1208477e198a91ac3f8f23365dfcd
[9] https://github.com/nirvdrum/svn2git
[10] https://github.com/sleicht/svn2git
[11] git.eclipse.org/c/scout/org.eclipse.scout.rt.git
[12] git.eclipse.org/c/scout/org.eclipse.scout.sdk.git
[13] https://github.com/BSI-Business-Systems-Integration-AG
[14] www.eclipse.org/forums/index.php/m/647259/
[15] https://bugs.eclipse.org/bugs/show_bug.cgi?id=394387
[16] wiki.eclipse.org/CBI#Primary
[17] wiki.eclipse.org/Scout/Contribution

Scout Links: Project Home, Forum, Wiki, Twitter, Instagram

As announced in our last blog post we are now ready with the crowdwriting setup of the Eclipse Scout book. The goal of the Scout book is to significantly lower the entry barrier into Eclipse Scout. That’s why this book is primarily targetet at Eclipse beginners. To start working with the book, we only assume a meaningful understanding of the Java language and hands on experience covering the Java SE.

In its current form, this setup does the following things:

• Provides an initial structure for the table of content.
• Per book section: Provides links to most of the existing documentation.
• Contains examples on how to include links, footnotes, references, screenshots, codefragments.
• Builds the output (PDF, HTML, EPUB) based on tex-files, images, and files from workspaces containing Eclipse Scout projects.
• Coming with a contribution workflow based on GitHub, make, LaTeX, Calibre

Below, some shortcut links and first screenshots are provided

• Latest PDF book output from CI Servers at BSI
• Github repository for all the sources on
• Documentation of the contribution workflow in the Scout wiki

The intended schedule is organized around the Kepler release train milestones. Therefore, described features, code snippets and similar are based on Eclipse Scout 3.9 that will be shipped with Kepler. Until May 3rd (=M7=Feature Freeze) we try to get in as many contributions as possible. The reminder until Kepler GA is reserved to fine tuning, corrections and other improvments.

We are fully aware that this is an experiment. As it is running in the open, we might even get contributions from places we did not expect. But whatever the outcome, we are sure to learn a couple of things until June 2013

Scout Links: Project Home, Forum, Wiki, Twitter, Instagram

A while ago we were asking for community feedback regarding the Eclipse Scout roadmap in our forum. We now have consolidated the feeback and aligned it with available resources.

With the Kepler release Eclipse Scout 3.9 will address the following topics:

• Support for mobile devices
• Support for modular applications
• Build infrastructure (CBI)
• Test infrastructure
• Documentation
• Staying on the release train

The individual points will be covered by separate blog posts over the coming months. For now, some additional context is provided below.

Support for Mobile Devices is in the workings since a year. As it is based on Eclipse RAP, we have been collaborating with the guys from EclipseScource since then. With Kepler, developing mobile applications with Scout will become  as simple as creating apps for the desktop, or the web. There has been a talk at Eclipsecon Europe, and there is a proposal for Eclipsecon Boston.

Support for Modular Applications. A first glimpse of this enhancement was provided in a corresponding forum topic. Many of the necessary runtime aspects have already been developed in the context of the Juno release. As we were not able to complete this feature in time for Juno, and a complete implementation does require corresponding Scout SDK tooling, the feature will now be included in the Scout 3.9 release.

The Scout Build Infrastructure will be moved to the Eclipse CBI. A large part of he work is already done and we expect to complete these efforts with the Kepler M5 milestone. As a by-product we have added a tutorial for a Maven Tycho Build for Scout applications.

With the Scout Test Infrastructure we will move the testing code for the Scout framework from BSI to Eclipse. This step is planned to begin early next year. In addition we want to make life easier for Scout devlopers by providing some infrastructure for testing Scout applications. Have a look at this bug or the joint talk proposal with the Jubula people for Boston.

Finally, we want to write an Eclipse Scout Book. Almost from the beginning people have been asking for a book so we couldn’t help notice the demand. As the task of writing a useful book is demanding and Scout is covering many aspects of writing business applications, we never really got off the ground in actually beginning to write. We have now decided to make an experiment by defining a setup that allows for “crowdwriting” in order to take advantage of our growing community. An initial description of the chosen setup is described in the Scout wiki. There is still work left to do, such as defining a proper contribution workflow so what you see now is still very preliminary. As soon as the is ready, we will write more about the Scout book project in our blog (and on some other channels).

Scout Links: Project Home, Forum, Wiki, Twitter, Instagram

Thank you for the interesting talks and keynotes at the Eclipse Con Europe 2012 in Ludwigsburg.

We were presenting our new “scouty” there: the Lego minifigs.
Congratulations to the winners of our #scoutminifig competition. Find all the photos of the competition here.

For everyone with a Scout Minifig: Please keep on posting and show us your minifig around the globe!
Simply post your photo to Instagram or Twitter with the hashtag #scoutminifig.

For everyone without a Minifig: Last chance to get your own at the Eclipse Con in Boston in late March next year.
We are looking forward.

We are lo0king forward to Eclipse Con Europe next week. Besides our Scout talks we will bring Lego blocks and many many of our new #scoutminifig. Come and get a “Scouty” at our booth. It would be cool to get back pictures from places around Europe and the rest of the world (use hashtag #scoutminifig on instagram or twitter)

As you are still reading please also consider to visit our talks:

• BahBah Chat “in Multi-Frontent”  Wednesday, October 24th 10:30 @ Seminarräume 1-3
• Eclipse Scout goes Mobile Thursday, October 25th 14:00 @ Theater Stage

Scout Links: Project Home, Forum, Wiki, Twitter, Instagram

Next to valuable input into our Scout Roadmap discussion in the forum, the last weeks did see the first three external patch contributions to Eclipse Scout. All coming from three different individuals – and two already make into the Scout Juno SR1 Package!

• 388941: JmsTransactionMember unupdatable … from Boy D\\\’Poy
• 389163: BundleBrowser.getClasses doesn’t … using maven/tycho build from Nils Israel
• 388722: Calendar field improvments from Bertin Kiekebosch

It looks as if there’s a growing Community around Eclipse Scout. Thank you all so much 

Scout Links: Project Home, Forum, Wiki, Twitter

Just in time for the GA of the Juno Release train we have a couple of introductionary video tutorials on our youtube channel for Eclipse Scout kindly provided by Patrik Suzzi.

Seven individual videos between 1 and 5 minutes each cover many things from creating a new project, adding a form, adding form fields, some interaction and finally a deploy to a tomcat web server.

Check it out and let us know if you like it

Scout Links: Project Home, Forum, Wiki, Twitter

In two weeks we talk about Eclipse Scout at this years Jazoon in Zurich. In our talk (Schedule changed to Tuesday 2012-06-26 16:30 – 16:50, Arena 7 (130)!!!) we will focus on the multi-frontend capability.  With the possibility to create Scout web applications we have already done a significant step into this direction with Juno. Improved support for tablets and mobile phone will arrive next year with the Eclipse Kepler release.

Scout Links: Project Home, Forum, Wiki, Twitter

The new Eclipse Scout 3.8 release shipped with Juno brings some big new features like web ui with Eclipse Rap, Jax-WS integration, Rayo look & feel for the Swing ui and SVG support. Beside these great features, many little enhancements have been made to make your life easier. One of them I’ll show you now.

Those who are familiar with scout know that every field on a form consists of a label and the actual field. Scout already provides a mechanism to control the position of that label. Until now it has been possible to position the label on the left side of the field (which is the default) or on the field itself. The property to control this behavior is called “Label Position” and has been extended for Eclipse Scout 3.8.0 to allow a positioning on top of the field.

Wondering how it works? Then have a look at the Top Label Demo Project which you can import into your Eclipse Juno workspace. Also keep an eye on the New & Noteworthy site which will regularly be updated until Eclipse Scout 3.8.0 officially gets released.

Scout Links: Project Home, Forum, Wiki, Twitter

With the new 3.8 Juno release the Scout SDK offers support to integrate external JAR files into a Scout application with a few clicks. To demonstrate this new Scout SDK feature we recently added a tutorial  that shows how you can add  Jython (=Python for Java) support into your Scout application.