The Scout Explorer View shows all Scout Bundles and provides folders below them to manage the typical objects for a bundle type.
The detection and layout of this bundle entries (the green, orange and blue nodes) have been redesigned for Scout 3.9:
The layout of the tree is completely based on the dependencies of your bundles. As the dependencies between bundles build up a graph, the Scout Explorer may show a single bundle at various places in the tree considering all paths in the actual dependency graph.
As a consequence, each bundle can contain several bundles of the same type (breaking the trinity client-shared-server) for a more flexible layout.
The tree also shows Scout bundles that are in your target platform (binary) and are only referenced by your workspace bundles.
Fragments are shown as well
There is a context menu Add Scout Bundles… on the bundle nodes that allows you to create sub modules or new bundles within your existing project.
Scout 3.9 comes with an enhanced web user interface (RAP) that is optimized for smartphone (mobile) and tablet devices.
By creating a new Scout Project using the Scout SDK you automatically get the mobile support when choosing to create a RAP user interface bundle. In the default setup you get four servlets prepared:
web for normal personal computers or laptops
mobile for smartphone devices
tablet for tablet devices
root entrypoint for all browsers that will autodetect your device and dispatch to the best of the servlets above.
Furthermore you get a client.mobile bundle prepared that includes all modifications to your client that should apply to mobile and tablet devices only (e.g. if you want to hide or replace some features).
In Scout 3.8 when creating a new object using a wizard you already have the possibility to choose from a list of possible super classes. But the super class selected by default is always the same. So if you e.g. have defined a project specific template for forms called ‘AbstractMyProjectForm’ you always have to remember to change the selected super class when creating forms.
With Scout 3.9 you now have the possibility to configure the super classes that should be used by default for each Scout project independently: Go to Window -> Preferences -> Scout -> Default Super Classes. There you can specify the default super class to use for each object type and Scout project.
This configuration is also considered if you don’t explicitly have the possibility to choose a super class in the wizards: E.g. when creating a new Form by default there are also ‘Cancel’ and ‘OK’ buttons created. If you now modify the default super class for OK buttons, this is automatically used by the new Form wizard as well.
This mechanism also respects the new extensible Scout objects defined in ‘org.eclipse.scout.rt.extension.client’: If your project has this dependency, the Scout SDK prefers those objects over the standard ones (unless you have modified the defaults).
The settings are stored in the project preferences so that you can share them with your team using e.g. a team provider like SVN, CVS or Git.
In Scout 3.9 the SDK does no longer rely on a specific package structure.
This affects the Scout Explorer which now searches for objects in a whole plugin instead of specific packages. As a consequence the folder ‘Process Services’ and ‘Outline Services’ have been merged to a general ‘Services’ node containing all services except lookup and the common ones. This gives you more flexibility in usage and design of your services.
Furthermore you have the possibility to specify the target package when creating new Scout objects using the Scout SDK Wizards. The packages where new objects are created by default can be configured using the preference page: Window -> Preferences -> Scout -> Default Packages.
These settings are stored in the Scout project preferences and can therefore be shared using a team provider like SVN, CVS or Git.
We have changed the sorting and presentation of the NLS proposal field so that the list behaves more intuitive and that it is more clear why a match is included in the list. This includes separation of the matches depending on type and sorting according to relevance.
For the discussion about testing Scout applications, it is helpful to have a rough understanding of the architecture of a Scout client server application.
The Scout client Application (on the left side in the above picture) contains a UI plugin , a client plugin, (orange) and a shared plugin (green).
The UI plugin (the white cube) renders the UI part of the modeled client using a specific technology, (Swing, SWT, or RAP). The modeled client UI (the orange cube) contains a client plugin that is independent from the UI library used. A shared plugin (the green cube) containing common resources such as service interfaces, data transfer objects, text translations, … is shipped in both the client and the server application. The server plugin (the blue cube) contains server logic such as persistence.
A possible data flow (the red dotted line) is for example:
Fetching data from the server
Putting the data it into transfer objects
Sending the transfer objects to client
Importing the data from the transfer objects into the UI
Then, user input may flow back to the server using the same path in the other direction.
To follow the discussion below we need to add some more details. As shown below, your application plugins depend on plugins from the underling Scout framework. We can also get an idea which application parts communicate through the framework layer.
What Should I Test?
Usually, everybody agrees on the importance of automated tests. However, agreeing on the correct granularity is not always easy (unit test, function tests, integration tests, UI automatized tests…).
In an environment with limited resource and time I suggest to set the focus of your automated tests on your code, your business logic and your use cases. This implies, that testing the framework itself should not be your top priority.
Start with defining a clear limit for your tests and start with the simple things first. Use JUnit tests for your (manually written) code that is independent from the framework and doesn’t have external dependencies. This works great for utility classes. You can even use this approach to testing as a desing guideline (or as a hint to refactor existing code).
Whe we assume that we have implemented some input validation logic in the application’s shared plugin we can use JUnit for automatically testing this without any external dependencies. This scenario is illustrated in the following diagram.
But sometimes you might want to test a larger context of the use case that also depends on the Scout framework. In this situation, the difficulty is to identify the system boundaries for your test: it might be easier to mock away (with the yellow cube) the server and to fake its response, rather than putting test data in a database to produce the desired test setup.
Another approach might UI black box testing. In this case the whole software is considered as a black box. The goal of these tests is to ensure that the workflows and use cases required can be performed correctly. For this matter a tool like Jubula can be used.
getting acquainted with and learning Apache Maven and the Tycho plugins
reading poms of other projects (Platform Build , Minerva )
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 .
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 . This work is based on the migration of the Scout sources from SVN to Git .
Migrating from SVN to Git
Although the source history of Eclipse Scout isn’t that long and just starts two years ago  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 . 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  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  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  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.
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.
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.
As described by Daniel Wiehl  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  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 . 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  I hope we have made it easier to contribute to Eclipse Scout. I will update the Contribution Guidelines . 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.
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
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
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)
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).
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:
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!