Eclipse Scout is the perfect choice for an open source business application framework. It is simple to learn and substantially reduces development time for client-server software. User-friendly applications are easily implemented with Scout’s comprehensive set of user interface components. Completely based on Java/Eclipse, Scout applications integrate well in existing IT environments.
http://www.bsiag.com/en/technology/eclipse-scout.html
It was really nice to meet the Eclipse Community in Toulouse last week at the first EclipseCon France.
We had a lot of interesting discussions at our booth. It was nice to see that the interest in the Scout project has been growing. A lot of people are looking for a solution to write form-based, client-server business applications. Choosing Eclipse Scout is a very good option for them. The tooling support (Scout SDK) allows to get fast and good results, even if you are new to RCP, OSGi and plugin development.
Since we had been asked several times: Yes, we are an Eclipse project! It is open-source (EPL license, git repository, no community vs commercial edition).
We took back some photos from Toulouse that we posted on Facebook:
Visit our Facebook Page
And on Google+:
Visit our Google+ Page
Do not hesitate to follow us there (likes, +1 and other feedbacks are highly appreciated).
On Wednesday and Thursday this week, we will be in Toulouse for the first EclipseCon France.
Come and meet us at booth #1. We are looking forward to meeting you and discussing about your experiences with Eclipse Scout. We will also discuss and demonstrate the new features getting released with Kepler:
And yes, we have some Lego Minifigs at the booth!
BrowserSim is a Browser Simulator to test quickly how a web-application looks like. It is integrated in Eclipse (because it is developed as part of the JBoss tool), so it can be installed in the Scout SDK.
The installation is straight forward, but you need to carefully complete each step described in the BrowserSim FAQ. I had no trouble to install it in the latest version of the Eclipse SDK (eclipse-scout-kepler-RC1-win32.win32.x86) on my window machine.
Here my steps list:
Thanks to the JBoss team for their work!
Last week we had a great time at the Eclipse Stammtisch Zurich.
Eclipse Scout Talk
Ken Lee and Matthias Zimmermann presented Eclipse Scout. The motto this year: “Write your application once – run on rich, web and mobile”. Since last year Application written on top of the Eclipse Scout Framework can be rendered in a Browser with Eclipse RAP (Remote Application Platform). With Kepler this renderer was extended (model transformation, optimized components, optimized theme) to support mobile and tablets. Scout application can be rendered as web applications for those devices.
Xtext meets Orion Talk
Holger Schill demonstrated his prototype that allows editing Xtext based DSL in web editors. It is based on Orion (with some modifications) and it uses some help of an Eclipse IDE running as a server (it calculates the editor behavior: quick tip, validations…). It was a really interesting talk, only one slide and a big demo.
Eclipse Orion Talk
Eclipse Orion: “It is not Eclipse in the browser; it is a new editor in the web (using the browser as a platform)”. That is what Mike Milinkovich explained during its talk. The demonstration was really impressive. The primary targeted programming languages are coming from the web (html, javascript, css…). It is really impressive, in comparison to the editor providing only syntax highlighting. You can try it online on orionhub.
Measure for Measure Talk
The presentation of Werner Keil was about Eclipse UOMo, a project that ease the correct use of units in a Java project. This is particularly useful when different system communicate which each other. As illustration Werner choose the Shakespeare quote “Say what you will, my false outweighs your true”. Indeed, when not properly handled a system might define 32 liters, where another understands 32 gallons.
We will be happy to meet the Eclipse Community in Zurich for the Kepler Democamp. It will take place on 27th June at the ETH main building.
Meet the Eclipse Scout team at the following other events.
The last Milestone build of Eclipse Scout is live and ready for testing. You can update your Eclipse via P2-Updatesite: http://download.eclipse.org/scout/releases/3.9. The Kepler M7 Package is available from here: http://www.eclipse.org/downloads/packages/node/988
The extension point org.eclipse.scout.rt.ui.swing.appextensions allows running multiple swing Scout features in a single Eclipse application.
Example: Create multiple applications extensions (e.g.):
public class App1 extends AbstractSwingApplicationExtension {
public App1() {
super("App1");
}
@Override
protected IClientSession createClientSession(UserAgent userAgent) {
IClientSessionRegistryService service = SERVICES.getService(IClientSessionRegistryService.class);
return service.newClientSession(ClientSession.class, userAgent);
}
@Override
protected ISwingEnvironment createEnvironment() {
return new SwingEnvironment();
}
}
Register ExtensibleSwingApplication as application and the previously created applications extensions:
<?xml version="1.0" encoding="UTF-8"?>
<plugin>
<extension id="app" name="Application" point="org.eclipse.core.runtime.applications">
<application>
<run/>
</application>
</extension>
...
<extension
point="org.eclipse.scout.rt.ui.swing.appextensions">
<swingApplicationExtension
ranking="1">
</swingApplicationExtension>
</extension>
...
A marker icon is now displayed in an editable cell in an SWT table (similar to the swing table).
The icon can be changed by setting the extension org.eclipse.scout.rt.ui.swt.scouticons for the cell_editable icon.
For Kepler, Scout has moved to GIT: http://git.eclipse.org/c/scout/ and changes are pushed to Gerrit: https://git.eclipse.org/r/.
For more information see Getting_the_Scout_Sources.
Two features for testing have been added to the updatesite:
These features contain plugins that provide support (Utility classes, Test Runner…) in order to test scout applications.
—
You can find these new features and more here: http://wiki.eclipse.org/Scout/NewAndNoteworthy/3.9.
The last Milestone build of Eclipse Scout is live and ready for testing. You can update your Eclipse via P2-Updatesite: http://download.eclipse.org/scout/releases/3.9. The Scout Kepler M7 Package is available from here.
Scout Explorer View
The detection and layout of this bundle entries (the green, orange and blue nodes) have been redesigned for Scout 3.9:
bug 394127 and bug 378151
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:
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).
Default Super Classes Preference Page
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.
Configure the default packages
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.
—
You can find these new features and more here: http://wiki.eclipse.org/Scout/NewAndNoteworthy/3.9.
Part 2 will follow next Wednesday.
In our last post we did announce our EclipseCon Boston talks about building mobile apps with Scout and testing Scout applications. In this post we will elaborate a bit on the testing talk to make sure it gets the attention it deserves 
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:
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.
Interested? Meet us in our talk: Testing a Scout Application with JUnit and Jubula. We would love to hear from your ideas and experience.
See you in Boston.
Scout Links: Project Home, Forum, Wiki, Twitter, Instagram
In 3 weeks we will be at the EclipseCon Boston to present the latest news of the Eclipse Scout project. Come and meet us at booth #3.
If you are new to Eclipse Scout or if you are already developing with Scout: We would love to meet you and listen to your experience so far, or find out how Scout may be of help to you.
Scout talks at EclipseCon
Looking forward to meet you.
Scout Links: Project Home, Forum, Wiki, Twitter, Instagram
After many hours of
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].
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].
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.
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 [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.
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] http://wiki.eclipse.org/Platform-releng/Platform_Build
[2] http://wiki.eclipse.org/Minerva
[3] http://wiki.eclipse.org/LTS
[4] http://wiki.eclipse.org/Tycho/Release_Notes/0.16
[5] http://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] http://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] http://git.eclipse.org/c/scout/org.eclipse.scout.rt.git
[12] http://git.eclipse.org/c/scout/org.eclipse.scout.sdk.git
[13] https://github.com/BSI-Business-Systems-Integration-AG
[14] http://www.eclipse.org/forums/index.php/m/647259/
[15] https://bugs.eclipse.org/bugs/show_bug.cgi?id=394387
[16] http://wiki.eclipse.org/CBI#Primary
[17] http://wiki.eclipse.org/Scout/Contribution
Scout Links: Project Home, Forum, Wiki, Twitter, Instagram
Recent Comments