BSI Business Systems Integration AG BLOG

Eclipse Scout 9 release: out now!

Fri, 05 Apr 2019 07:07:09 +0200

The official Scout version 9 has been released as part of the Eclipse simultaneous release 2019-03 and is now publicly available. In this article we highlight some of the new features such as improved responsiveness, support for OpenJDK and more.

With the Eclipse simultaneous release 2019-03, the new Scout version 9.0 has been released. As usual, it contains a lot of changes. We are happy to share some of the highlights with you. The complete release notes can be found here.

Support for OpenJDK and newer Java Versions

Long requested and finally here: Scout now supports running on OpenJDK, and on Java versions up to 11. Note that this requires a bit of work on the side of developers; and RedHat's OpenJDK version is not compatible out of the box due to missing elliptic curves. For more details, see the Java 11 section in the release notes and the migration guide.

Dark theme

You enjoy the dark theme of Eclipse, and want your Scout application users to enjoy the eye-friendliness of a dark theme too? Good news: A dark theme is now included with Scout and the widgets have been adjusted to blend in properly.

Improved Usability

To improve responsiveness if the window becomes narrow, group boxes can reduce their width by moving their field labels to the top automatically. The Scrollbar handles should be easier to catch, while the trees (treeboxes, navigation) scroll to show you a better view of your data when you expand or collapse an entry. Don't forget to check out the improved options for menu bars and how you can control what happens if there isn't enough space for all the menus.

Denser layout option

Sometimes screen space can be scarce and the generously spaced elements of Scout will show only a small amount of data in these instances. If you need to display more data at once, you can switch to the "Dense" layout, which reduces the amount of whitespace, which especially increases the number of table rows that are visible at the same time. Below you can see an example from our Contacts demo application:

New widgets: Mode Selector and Popup

Many widgets got small but awesome improvements – and for sure we have some new widgets too! For instances, check out the model selector and the popup widget.

Widget 1: Mode Selector

Similar to a Radio Button Group, the new Mode Selector allows you to switch between predefined options, but with a "regular button"-like interface that is quite common on smartphones.

Widget 2: Popup

With the new "Popup" (also known as popover on some platforms), you can display additional information in an overlay. You have many options to embed widgets here - we can't wait to see what you do with it!

The Popup has the following features:

Take any widget you like and open it in a Popup by using the WidgetPopup.
Use any widget you like as anchor and align the Popup around it.
Decide whether you want to point the Popup to the anchor by using the property withArrow.
Control the behavior of what should happen if there is not enough space to display the whole Popup using various properties.
Choose how the popup should react when the user clicks on the outside or on the anchor.

try out all the widgets in our widget app

Changed property lookup order

In many technologies such as Docker or Kubernetes, changing the configuration without having to create a new deployment is essential. To support this in Scout, the lookup order for Scout properties has been adjusted: It now allows overriding properties in the configuration file by using environment variables.

Get to know Scout?

Visit our project page, make your first steps with Scout using the comprehensive documentation, and check out the Scout forum if you have questions around a particular topic!

Scout survey

Do you have two minutes to make Scout even better?

Complete survey (2 MIN)

Looking back on the first two simultaneous releases and forward to a full roadmap for 2019

Fri, 21 Dec 2018 14:38:00 +0100

Since our last major release of Scout 8 with Eclipse Photon, we have polished a few things about Scout. We were able to successfully release two releases since the switch to the Eclipse Simultaneous Release Train. What has changed in these releases? What are Maven archetypes for Scout and where will Scout go in 2019? Keywords are "Dark Theme", "OpenJDK" and "ECMAScript6".

Simultaneous Releases September and December

With the September release, the first simultaneous release of the Eclipse platform, and the latest release in December, we mainly worked on the presentation and performance of Scout. With support for virtual scrolling, tile grids are now only calculated by the browser when the elements come into the visible area. This results in a significant performance gain in certain browsers, e.g. the Internent Explorer.

Updated release notes

Maven Archetypes for Scout

There are two Maven archetypes available for some time now. These provide a complete application architecture, from persistence to the user interface, as a Maven project. We used Jooq for the persistence, other persistence frameworks can be integrated analogously. These application blueprints show how a complete application breakthrough with Scout works. Further, we have added some additional functionality such as favorites or user administration in the archetype for the classic Scout framework.
You can find the ScoutJS archetype on Maven-Central: scout-hellojs-app
The archetype for Scout classic is available on github: ScoutJooq

The Maven Archetype for Scout makes it quick and easy to build complete business applications.

Outlook for 2019

We have set ourselves many goals for 2019. Scout 9 and 10 are the next major development steps. Various usability improvements will be implemented, some new widgets will be added for both the classic Scout and ScoutJS. A highlight is the dark theme, which can also be activated via a configuration attribute.

The new dark theme in Scout 9

Technically Scout 9 will be compatible with Java 11 and will now also support OpenJDK. Not only is the Scout Javascript Client Code put on a new technological basis with ECMAScript 6 in the course of 2019. We are also examining new tooling support, a possible conversion to TypeScript and much more.

Get to know Scout?

Visit our project page, make your first steps with Scout using the comprehensive documentation, and check out the Scout forum if you have questions around a particular topic!

Scout Survey

Do you have two minutes to make Scout even better?

Complete survey (2minutes)

Eclipse Scout 8 release: now available!

Thu, 28 Jun 2018 10:42:19 +0200

We are proud to announce the release of the new Scout version 8! The official release has been published together with the new Eclipse Photon release as part of the Eclipse simultaneous release train.

For details, check out the Release Notes of Scout 8. To download the latest Scout release use the Eclipse package download page.

Hands-on and demo application

As usual, you can try out all the widgets and functionality provided by Scout online: Scout widgets
A demo application of Scout is available here: Demo application
The widgets application for Scout JS has been greatly expanded: JS widgets

New UI widgets and Scout JS

As with every Scout release, Photon comes with a nice set of new UI widgets. Already with the Oxygen release some initial steps called “Scout JS” were implemented to decouple the new Scout HTML5 widgets from the rest of the framework. With Photon the Scout JS library made significant progress and many new features are available. The highlights among the new UI widgets are the tile grid, hierarchical table, the tag field, but there are many more features to discover…

Examples of new Scout 8 widgets: File upload button, tile grid, hierarchical table and the tag field.

New outline overview

The Scout 8 release offers a new “OutlineOverview”. It typically is the first thing a user sees when an outline based application starts and is the widget displayed in the desktop bench when no page of the outline is selected. The previous OutlineOverview has been very simple, it basically just displayed the title and the icon of the outline. With this Scout 8 release a new widget has been added, it is called TileOutlineOverview. As the name implies it is based on the new TileGrid and shows the top level pages of the current outline. The new outline overview is enabled by default. If you don’t like the new style you can either use a defaultDetailForm which will be used instead of the outlineOverview. Or you can use the old OutlineOverview or even create a custom one.

The new outline overview in Scout 8

Extended REST framework capabilities

With Oxygen it was possible to auto-register REST services. Now, with Photon, we introduce data objects and improved the error handling in this Scout 8 release. This new concept will be a big benefit especially for Scout JS applications, because of its data oriented service API. Data objects are Scout beans, which can be used as data transfer objects for synchronous REST and asynchronous MOM interfaces. Furthermore, they may be used as domain objects within business logic.

Using the new DoEntity class as a base class, any kind of custom data objects can be built. An attribute of a data object is defined by adding an accessor method for the attribute. The name of the method corresponds to the attribute name; the attribute type is defined by the return value of the method.

Example of how to define attributes of a data object

Try now!

Of course, these are only a few highlights of the new Scout release. You can find the complete list in the release notes.

Try out our new Scout version 8 by downloading it from Eclipse! Make your first steps with Scout using the comprehensive documentation, and check out the Scout forum if you have questions around a particular topic.

Open source framework explained – Scout at Javaland 2018

Tue, 27 Mar 2018 15:29:00 +0200

Legacy modernization, application frameworks and browser peculiarities were just a few of the interesting topics we discussed with fellow participants at Javaland this year. Our BSI booth turned out to be a great meeting point for both Scout novices and enthusiasts. We presented the newest release of our application framework Scout and took the opportunity to answer many questions. As some questions were asked several times, we decided to write you a summary in an FAQ style.

Which framework is the right one to modernize our application landscape?

Some visitors at our booth shared the problem that they are looking for a modern application framework to renew their legacy applications. Our first question then usually was: what is your application about? Which need does it meet? We were quite happy to hear that many applications were about administrating certain data, e.g. in the public administration or scientific area. Hence, we were able to tell them that Scout is the right choice and was built with the focus on business applications, data-centric use-cases such as managing customer data and creating reports. In short,
Scout is about managing and navigating complex data.

"If tomorrow a new UI technology is state of the art, Scout will adapt and provide an efficient migration path for your project."

Pascal Gamper, Software Engineer at BSI

How does Scout differ from other application frameworks?

BSI at Javaland

Since its creation more than 15 years ago, Scout has pursued a different approach than many other existing frameworks. A main goal of Scout is to keep your application in a technical way up to date over years and decades. If tomorrow a new UI technology is state of the art, Scout will adapt and provide an efficient migration path for your project. One main advantage of Scout is that the developer is in full charge of server and client code. Scout doesn’t keep you in the dark in what the code does. You don’t like how the framework behaves for buttons in IE 9? Well, then just adapt the code. You would like to extend the framework? Then write your own components within a few steps.

Is Scout really open-source? Under which license is Scout published and why?

Scout was published as an open-source framework in 2009 under the Eclipse Public License (EPL) and has since been further developed each year. Currently, the latest stable release version is 7.0. Information about the installation and setup can be found on eclipsescout.github.io. Going open-source made us aware that every single line of code in an open-source project has to be “real” open-source. So, no copied code snippets, no 3rd party libraries which are not fully open-source. Today, Scout can be used for commercial projects and even forked for your own purposes. Back in 2009, EPL set high standards for our framework development, but we are convinced that those made us work harder, gave us more control over our code, and meets our high expectations of good quality.

How does Scout relate to Eclipse?

Overall, Scout is published under the umbrella of Eclipse as an open-source project. Hence, Scout is available under the Eclipse Public License (EPL). Scout is technically fully independent of the Eclipse platform. Therefore, you can use your preferred development environment to develop your own Scout application.

"The benefit of having pure Java code results in robust, clean and long-living business applications. Why should we let client technologies that change every couple of years influence business logic and application behavior?"

Pascal Gamper, Software Engineer at BSI

What is the architecture approach of Scout?

Scout consists of two main parts. On the one hand there is the ScoutJS widget library. The ScoutJS widgets can be used in a classic Single Page Application (SPA). You can extend the library with own components and can integrate these in existing applications. Further, you can write your own styling using CSS3.

On the other hand, ScoutJS can be used together with the Scout application model, which is a Java application model to orchestrate your application. Scout covers the application stack from the HTML/JavaScript components to the backend services where you access data and bind it to the application model. If the choice of Scout widgets is sufficient, you do not have to write any JavaScript nor HTML. Nevertheless, you can extend the application model with your own components and write your own renderer for existing or new components.

What are the advantages and disadvantages of Scout?

BSI booth at Javaland

First of all we need to distinguish between the classic Scout framework and the recently introduced ScoutJS. The classic Scout framework manages client state in the server. The benefit of having pure Java code results in robust, clean and long-living business applications. Why should we let client technologies that change every couple of years influence business logic and application behavior? We have experience with full-featured, professional applications such as BSI CRM and we have proof that Scout performs well up to thousands of concurrent users.

But sure, if you need ten thousands of concurrent users, you might need another software architecture. And the answer is ScoutJS. With ScoutJS, we extrapolated the advantages of the Scout application model to the client. This means that you will write client code in JavaScript, and the client state resides in the client. And still, the advantages of Scout remain. A perfect application scenario for ScoutJS is for instances a highly scaled web portal such as our BSI Portal.

Which browsers are compatible with Scout?

Scout provides full browser compatibility, from Chrome to Internet Explorer, from Firefox to Safari. Scout applications are responsive and are optimized for mobile devices and desktop browsers. Our client rendering code is optimized for every browser individually and the small number of issues and the responsiveness of the UI tells us this is the right approach.

All in all we enjoyed two interesting days at Javaland. Are there any questions unanswered? Please don’t hesitate to contact us! In this spirit we send greetings from our booth.

Machine Learning with Deeplearning4j and Eclipse Scout

Wed, 21 Jun 2017 11:06:00 +0200

Machine learning and deep learning in particular is developing at amazing speeds. Today, machine learning can be used to solve ever more complex tasks that have been considered impractical just a few years ago. Examples include autonomous cars, AlphaGo’s win against the world’s Go champion, photo realistic transformation of pictures or neural machine translation systems.

In this blog post we describe a simple system to recognize monetary amounts on Swiss payment slips. The user interface is implemented using Eclipse Scout and we build, train and run the deep neural net using Deeplearning4j.

Recognizing Handwritten Amounts on Payment Slips

Anagnostes is an Eclipse Scout application that uses a convolutional neural network to recognize handwritten amounts on Swiss payment slips.

The screenshot above shows an image of the scanned payment slip in the upper part. In the lower part of the form the output of the neural network is shown. The form shown above is implemented in class HcrForm.

Although all handwritten numerals are correctly recognized, the network assigns a low confidence score to the numeral six. This is indicated by the orange background which will prompt the operator to manually check the result and (if necessary) correct the output of the neural network in the user interface.

Eclipse Scout

The open source framework Eclipse Scout has been specifically built for enterprise applications with the following goals in mind.

Enterprise user deserve simple and powerful user interfaces.
Implementing and maintaining business applications must be efficient.
Business applications should be independent of specific technologies.
Learning the framework should be painless.

Scout may be used for any type of business applications such as ERP, CRM or medical data storage systems. As shown with the demo application described in this blog post innovative technologies such as machine learning are straight forward to integrate with Scout applications.

The framework has been proven in production for over a decade is currently based on Java and HTML5. Since 2010, the Scout Open Source project is hosted by the Eclipse foundation.

The latest Scout release will be shipped as part of the Eclipse Oxygen release train on June 28 2017.

Deeplearning4j

DeepLearning4J is a toolkit for building, training and deploying Neural Networks. Currently it is the most complete and mature deep learning library in the Java domain. The deeplearning4j library comes with a good documentation and is easy to integrate into Scout applications.

For the example application described in this blog post it is enough to add some Maven dependencies.

As machine learning is always about models that you train on some data and then apply on some other data we want to illustrate these steps using the Deeplearning4j library. Let’s start by constructing a new multi-layer network like the class NeuralNetwork of the Anagnostes demo application.

For now we skip the description of the network configuration object, as this is covered in more detail in the Network Architecture section below. We can then train this neural network model as follows.

The above method trains the neural network over several epochs (an epoch corresponds to cycling through the complete training data once). In each epoch the networks parameters are updated to improve the networks performance on the training data with the line m_network.fit(trainData). To verify the performance with data not seen during training the network is evaluated after each epoch using separate validation data.

The trained model can then be used to classify new data. In our demo application we want to recognize handwritten numerals. The code below takes an image as input and transforms the normalized image into an input vector for the network using Nd4j.create(normalizedImage). The network then classifies this input with the statement m_network.output(input) by assigning confidence values to each numeral class ‘0’, ‘1’ … ‘9’. The confidence value for class ‘4’ can then be accessed with output.getDouble(4).

The Data

Good data is always of central importance whenever we apply machine learning to a specific domain. For the sake of simplicity and comparability we decided to go for the best known task in the domain of machine learning: the classification of handwritten numerals. By far the most frequently used data collection is called the MNIST database. It contains roughly 60,000 images of numerals to train systems and 10,000 numerals to test systems.

The individual numerals in the MNIST database are normalized to 28 by 28 pixels of gray-level images. The picture above provides some examples.

For our demo application we also wanted to experiment with our own data in addition to publicly available MNIST data. For the data collection we asked people to fill in a simple form with their everyday writing style. See below for a picture of such a collection form.

In a simple semi-manual process the scanned form is then converted into individual image files holding a single isolated numeral. In contrast to the MNIST data the images of our numbers database are normalized for training and testing at runtime. For our experiments we now have 10,000 digit images written by 20 individuals. As in the case of MNIST our data is publicly available. In contrast to the MNIST data our scanned images are available in their original format (color or grayscale, whatever we received as contributions).

Side note: Please consider to contribute to this collection! Our next goal is to reach 20,000 images. We gladly accept pull requests containing at least the scan of your filled in form (using the template).

Image Processing

Before we can use the images of our handwritten numerals for training and/or recognition we perform an image normalization step that converts the scanned numeral into the 28 by 28 gray-level pixel format used by the MNIST database. This normalization step is illustrated below.

This normalization has the advantage that we can work with existing network architectures that have been extensively tested by the machine learning community and at the same time it allows us to use the existing MNIST data to amend our own data collection.

To match the MNIST images format the normalization process consists of the following steps:

Binarize the color or gray-level image. This results in a black and white image.
Resize the cropped numeral to a 20 by 20 pixel box while preserving the aspect ratio.
Calculate the center of gravity for the resized image
Center the image in a 28 by 28 pixel frame using the center of gravity calculated above.

Network Architecture

For the neural network architecture we use a convolutional neural network very similar to the one proposed by Yann Le Cun et al in 1998. This architecture is illustrated in the diagram below, taken from Le Cun’s publication.

The architecture can be divided into a feature extraction stage (convolutional and subsampling layers) and a classification stage (the fully connected layers at the right end). The planes in the convolutional layers implement different filters that are applied to the input image. By applying subsampling and adding more convolutional layers the network is capable to learn a set of filter combinations that prove to be highly effective for image classification. To learn more about convolutional network architectures check out Denny Britz’s blog post.

The classification stage correspond to the classical neural network architecture that have been around for over 30 years. Any neural network tutorial covering multilayer perceptrons will do to learn more.

Based on the diagram for the network architecture in our demo application below it should become clear that this implementation is very close to the LeNet architecture proposed in 1998.

This architecture is defined in the LeNet class of our demo application. The Deeplearning4j configuration for this architecture looks as follows.

This might seem somewhat intimidating at first sight. But then again, this corresponds to the result of years of research. Luckily, the Deeplearning4j library comes with an extensive set of examples that provide valuable starting points for many different machine learning use cases.

Summary

This blog posts describes a simple demo application to recognize numeral amounts on payment slips. The application has a user interface part implemented with the Eclipse Scout framework and a machine learning part implementedusing the Deeplearning4j library.

Dealing with a task for which is sufficient to work with only 6 layers roughly corresponds to a deep learning “Hello World” exercise. At the same time, the described use case covers many of the recurring topics for machine learning problems. For many more complex problems it is not unusual to work with dozens or even over hundred layers as in the case of the ImageNet challenges.

In our experience integrating Deeplearning4j with Eclipse Scout applications proved to be straight forward. In case you’d like to play around with the demo application clone the Anagnostes repository and import the project as an existing Maven project in your Eclipse IDE (please use the Scout package as described on the Scout homepage).

Feedback? Any Thoughts? Please use this forum thread.

Scout Links

Experience Report from JavaLand 2017

Wed, 05 Apr 2017 13:38:56 +0200

I really like going to software conferences. I get the chance to learn new things, to meet other developers and to discuss code and software architectures. And of course, I like JavaLand because of its rollercoasters. :)

BSI has been present at the JavaLand conference since its inception in 2014 with the goal to present our open-source framework Eclipse Scout to the participants. During these events I stopped counting the number of many times I explained the Eclipse Public License (EPL), why we decided to host the Scout framework with the Eclipse Foundation and what benefits we get in return for our project and for our company. And particularly, that Eclipse is not just an IDE but an open source community of a very broad set of projects and collaborative working groups in the domains of internet of things, science, embedded systems and many other interesting areas.

One of the many features of Eclipse Scout: You can switch the CSS on the fly.

Being in charge of our booth, I not only tried to answer many questions, but also to give a lot of demos. For this I used the Contacts application, a simple Scout application you can build in a day that has enough features to provide a good overview of the framework. A second use case for the demos was starting from an empty workspace and coding a simple “HelloWorld” project.

Based on the Scout “Hello World” demos I happily rewarded every visitor that managed to successfully complete this exercise with a tiny quadcopter.

If the visitor showed interest in Scout and wanted to see more, we went through more Java code or the general architecture of Scout applications. With the Scout framework the user gets a lot of nice features out of the box (tables with advanced filters and organization possibility, nice widgets like our date picker for example).

Sometimes, visitors were also curious about specific details: «What happens when the connection is slow or lost?» «Can the user settings be persisted somewhere?» «Why do we need an @Order annotation on top of our inner classes?» «Can the Scout framework be integrated with the Spring stack? I could answer all of those questions, expect for this one: What does "NLS" in our "NLS Editor" mean. Well, now I know. It means: National Language Support.

The NLS Editor provides access to all the translated texts in your application and also allows to add new languages and individual texts.

At a conference like JavaLand, I expected to see more developers that are using other IDEs than Eclipse, but I was happy to see I was wrong. For example, I could help an Eclipse IDE user that was wondering how he can distribute a customized version of Eclipse in his company. I gave him two pointers:

P2 Repository can be mirrored
Oomph is really a cool way to share Eclipse Installations

A lot of people asked me how we make money out of the Eclipse Scout project and who is paying for the development of new features. Well, I think, it is important to be transparent and to explain our business model at BSI: We have donated the project to the Eclipse foundation and we continue to invest in the project to develop our commercial application on top of it. So, explaining the role of the Eclipse Foundation as a business friendly platform for open-source projects was an important argument.

I remember two visitors, who had already used the Scout framework. One of them was involved with the CRM of one of our customers at BSI. The other one tried to use Scout about two years ago, but the desktop client was not what he was looking for. So, last year’s change of the Scout user interface to HTML5 was good news for him.

Last but not least, Tuesday evening at JavaLand was great: I was able to relax a bit from the conference rush at our booth and I could enjoy a beer with some of my colleagues from BSI who visited JavaLand for educational purpose.

Me and my BSI friends at the Eclipse Scout booth

#scoutminifig on tour

After-conference activities

Of course, I took a ride on the Black Mamba with friends from Itemis and just enjoyed the magical atmosphere of «Phantasialand».

I recommend everyone to visit a conference like JavaLand or EclipseCon Europe. You always come back home with new ideas and a lot of energy.

Feedback? Any Thoughts? Please use this forum thread.

Scout Links

Business Applications on Blockchains: Eclipse Scout, Ethereum and web3j

Fri, 06 Jan 2017 13:40:00 +0100

This blog post provides a brief introduction into the blockchain world and shows how to integrate the Ethereum Blockchain with a Java based Business Application. Specifically we describe the implemented "micro"-banking prototype with Eclipse Scout (the business application side), Ethereum (the blockchain) and web3j (a Java library to communicate with Ethereum).

Blockchain, Bitcoin and Ethereum

Blockchain technologies provide a fully decentralized ledger based on peer-to-peer networks. The Blockchain promise is that network participants can rely on this ledger to safely interact with each other without the need of any central authority or trusting each other. This ledger is represented by a chain of blocks (this is where the term blockchain comes from) where each block contains a number of transactions that have taken place between the network participants. A key feature of blockchain technologies is that blocks in the chain cannot be altered in any way. The only way to change the blockchain is adding new blocks.

Bitcoin – created in 2009 by Satoshi Nakamoto (an unknown person or group of persons) - represents the first successful implementation of blockchain technology. Today, Bitcoin represents the gold standard of virtual currencies and enjoys growing popularity and its currency is soaring again. Luckily, Bitcoin has also set the precedent for blockchain technology to be open source. Recommended pointers being: The whitepaper, the code and a technical book (written in Asciidoctor) are nice examples.

Ethereum was originally conceived by Vitalik Buterin and in late 2013 he described its concepts in a whitepaper. The goal of Ethereum is to provide a blockchain platform that also includes a Turing-complete programming language. Using this formal language, smart contracts can be implemented and deployed to the Ethereum network. After deploying such contracts to the network, they are permanent and available worldwide. Enforcing the contract terms and its execution is then handled by the Ethereum network alone. This concept allows such contracts to act independently of any central authority or infrastructure.

All in all, Ethereum can be seen as the young sibling of Bitcoin. Worrying less and having fun trying new things. It does not (yet) have the stability and track record of Bitcoin but with having the smart contract concept included in its protocol Ethereum is fundamentally more powerful than Bitcoin. As in the case of Bitcoin Ethereum is open source and its codebase is developed openly on Github.

Smart Contracts and Business Applications

Smart contracts enable new application scenarios and business services and carry the potential to disrupt business models in many industries such as finance, insurance, public sector, telco, energy or internet of things.

However, blockchain technologies and smart contracts are both young technologies and its opportunities and risks are not yet well understood. Given the current hype and potential of these technologies, “now” is a good time for developers, key players and strategists to start experimenting with blockchain based services and investigating potential applications to capture open opportunities or to avoid negative surprises in the future.

To explore the potential of this technology and to rapidly identify relevant application fields one important step is to check the feasibility of blockchain-based services using proven technologies and frameworks. The combination of Ethereum and Eclipse Scout holds the potential to greatly simplify the development of such business applications and to speed up the time from ideas to working applications.

Eclipse Scout and Business Applications

Based on Java and providing an HTML5 frontend the open source framework Eclipse Scout well meets today’s technology standards and has been proven in production for over a decade. Since 2010, the Scout project is hosted by the Eclipse foundation and meets the foundation’s IP and governance policies that provided the necessary security for mission critical commercial usage.

The Scout framework has been specifically built for business applications with the following three goals in mind.

Implementing and maintaining business applications must be efficient.
Business applications should be independent of specific technologies.
Learning the framework should be painless.

Scout may be used for any type of business applications such as ERP, CRM or medical data storage systems. As Scout is agnostic to the application domain it is also a good fit to build blockchain based business applications.

Ethereum and Java: web3j

For the integration of the Ethereum network with Scout business applications the open source web3j libaray by Conor Svensson proves to be a good fit. Ethereum clients provide a JSON-RPC interface which allows external systems to communicate with the node. The web3j library brings the JSON-RPC of the Ethereum clients into our Java based business application by wrapping the communication including the JSON messages into plain Java objects as shown below.

This perfectly fits our need of our “micro” banking prototype for a clean and comfortable way to interact with the JSON-RPC of the Ethereum clients without having to deal with the raw JSON messages. Based on this approach we can take advantage of the Java type safety and write code to interact with the Ethereum network on a higher abstraction level. This results in readable and maintainable source code, which is particulary important for large business applications.

The web3j library comes with a good documentation and is easy to integrate into a Scout application. It is enough to add its Maven dependency.

Using the web3j library allows to implement many features with a few lines of plain Java code. The example method below shows how to check the balance of a given Ethereum account address.

The only method parameter is the address of the Ethereum account. First we have get the web3j object on which the method ethGetBalance is available. We also have to specify that we want the balance based on the latest block. The request is then send asynchronously to the Ethereum client to obtain a EthGetBalance balance object. Finally, the method returns the balance of the specified address using getBalance on the balance object.

The “micro”-banking prototype

As an exercise to obtain hands-on experience with blockchain technology and smart contracts we decided to extend the Eclipse Scout Contacts application in a first step to a “micro”-banking app that manages personal accounts and can transfer funds between these accounts.

As shown in the screenshot above, the “micro” banking application allows to create new accounts for the managed persons. From the blockchain perspective the account is uniquely defined by it’s address which in turn is represented by a number. This number alone is sufficient to receive funds and to accumulate a balance of Ethers (the Ethereum virtual currency).

The owner of the account must be in possession of both the account address and it’s corresponding private key. A wallet file is then used to safely store the public/private key pair. In this file the private key is encrypted with a password that needs to be kept separate from the wallet file. In order to spend the balance from an account, the account owner needs to sign every transaction for spending money with the account’s private key.

As shown in the second screenshot, our “micro”-banking prototype also allows to create offline transactions that can then be sent to the Ethereum network. In most cases the transaction is then confirmed by the network within a few minutes. The transaction can of course also be verified externally on any Ethereum blockchain explorer site, for example on etherchain.org.

The link between persons and accounts in the “micro” banking application is just added on top to keep track of the relations between persons and Ethereum accounts. The cool thing is that the application does not need to keep track of balances and managing transactions. This is provided by the blockchain.

Please note that the “micro” banking prototype described above is work-in progress. As in the case of a typical Scout application the integration of Ethereum is implemented in the backend only. Should you be interested in the code start with classes Account, Transaction and EthereumService. The code is currently available on a GitHub feature branch of the Eclipse Scout contacts application.

After having implemented and verified the basics of the Ethereum integration in a Scout application the next stage will include working with smart contracts, the Ethereum key feature.

If you want to check out web3j with a minimum of effort you may skip setting up your own Ethereum client and just use the Infura online service as described in the web3j documentation.

To get into Eclipse Scout download the package as described on the Scout homepage and follow the “Hello World” tutorial provided on the same page.

Feedback? Any Thoughts? Please use this forum thread.

Scout Links

Scout Neon: Display the keys for the localized texts in your application.

Tue, 07 Jun 2016 09:30:23 +0200

Eclipse Scout applications are multilingual per default. Scout developers work with text keys in the code and the application itself shows the translated texts in the language of the logged in user. When users asks to fix a specific text it can be tricky to find the right text key to improve the translated version of the text. In this blog post we offer a solution to force the application to show the text keys in the user interface instead of the translated text.

Eclipse Scout Applications contains out-of-the-box a mechanism to localize the user interface depending on the locale settings. It is based on Text properties files located in your code.

The Scout SDK provides a nice Editor to find the entries and to edit the text files directly as shown below:

However, it is not always easy to identify what is the text key corresponding to a label in the user interface.

The Text provider mechanism is built on top of the Scout bean manager. It is pretty easy to add an additional provider (see code bellow) having a smaller order than the other providers. This Provider just displays the key and the parameters instead of the localized text loaded from the properties files. This way you can see the labels in your application:

Such a text provider can be implemented according to the listing provided below:

Feedback? Please use this forum thread.

Scout Links

June 21st: Eclipse Democamp Zurich

Thu, 02 Jun 2016 10:07:17 +0200

Join us for the Eclipse Democamp in Zurich starting at 17:30 on June 21st. With close to 100 participants the Eclipse Democamp Zurich is amongst the larger democamps world wide.

At the democamp participants have the opportunity to learn about the cool technology offered by the Eclipse projects that showcase the latest features shipping with the Eclipse release train in June.

The event includes drinks, beer and buffet and is open and free to attend. Head over to the Wiki for the details and to Eventbrite to register.

Optional Eclipse Scout Tutorial

Prior to the Eclipse Democamp a free Eclipse Scout tutorial is offered to anyone interested. The Scout tutorial takes place at the same location and begins at 15:00.

In the tutorial we talk about important topics of the new Java/HTML5 platform that are not covererd in the Democamp session and also provide a "hands-on" opportunity for the participants.

Why Eclipse Scout?
Maven project structure, Logging and Testing
Styling Scout application with CSS3
The "Contacts" and Scout widget demo applications
Hands-on: Building your first Scout application

Participants interested in the Scout tutorial are asked to register separately and to bring their own laptop (please download and install the package Eclipse for Scout Developers prior to the tutorial session)

Democamp Outline

We are very happy to have a great line-up of projects, speakers and topics for this upcoming democamp. This includes the Eclipse Che, Xtext, AsciiDoc, Docker, Eclipse Scout, The Things Network and a closing session that presents a mash-up of IoT with the 1840s industrial revolution.

“Eclipse Che: The Next-Gen Eclipse IDE. Create Cloud IDEs with Eclipse Che” by Stévan Le Meur, Codenvy

“Xtext in the Web” by Holger Schill, itemis

“AsciiDoc Editor in Eclipse” by Max Rydahl Andersen, Red Hat

“Docker and other container Tooling in Eclipse Neon” by Max Rydahl Andersen, Red Hat

“Eclipse Scout: Going Java and HTML5” by Matthias Zimmermann, BSI Business Systems Integration AG

“The Things Network: Building an open, free and community-owned IoT network” by Gonzalo Casas

“1840s Industrial Revolution meets IoT” by Florian Pirchner and Klemens Edler, Lunifera GmbH

Registration, Location and Time

Please register via Eventbrite for the Eclipse Democamp Zurich. Participants interested in the Eclipse Scout Tutorial are asked to register separately.

Both the Eclipse Democamp and the Scout tutorial take place on June 21st at the main building of the ETH in Zurich in the lecture room HG D7.1 at Rämistrasse 101, 8092 Zürich.

Starting times:

15:00 Scout Tutorial
17:30 Eclipse Democamp

For additional details, Check the Eclipse Democamp Wiki page.

We are looking forward to meet you in Zurich on June 21st.

Feedback? Please use this forum thread

Scout Links

Eclipse Scout Neon Release

Thu, 31 Mar 2016 16:00:00 +0200

Starting with the upcoming Eclipse Neon release the Scout framework is directly based on Java and HTML5. This move allows projects to easily integrate popular Java frameworks and to use “Maven-by-the-books” for building purposes.

On the HTML5 side, full CSS3 support is now available and integration of modern JavaScript libraries to implement project-specific UI components can be achieved in a straight-forward way.

At the same time, great care has been taken to make sure that the existing Scout developer community feels at home right away and does not need to re-learn Scout from scratch.

Current state of the SDK Tooling

With the M6 release the most important parts of the Scout SDK are becoming available. The M5 release already offered Scout specific code completion for form fields, table columns, menus, and codes in the Java perspective. With M6 the Scout SDK also includes Scout component wizards for complete Scout forms, pages, code types and more.

To add a Scout component just select the appropriate Java package in the Eclipse Explorer view, press [Ctrl]-[N] and search for Scout as shown below on the left side:

To create a new Scout form simply select the Scout Form wizard and enter the name of the new form as shown on the right side of the illustration above. As in previous Scout releases the Scout SDK will then create all the necessary Java code for the new form including life cycle management, permissions and the corresponding service on the Scout backend server.

Adding new form fields can then be done directly in the Java editor with the Scout SDK addition to the Eclipse IDE code completion. Pressing [Ctrl]-[Space] opens the available templates where the applicable Scout components are presented first. As an example the screenshot below shows how simple it is to add new form fields.

Eclipse Help

With the M6 milestone we have added initial Eclipse Help content that should get you started quickly with the Scout package. This content is available via [F1] or the Eclipse IDE menu Help => Help Contents.

Chapter “Getting Started” describes how to create your first Hello World application.

The help chapter “Import the Scout Demo Applications” describes how to import the existing Scout Neon demo applications into your workspace. For this tutorial the Oomph import wizard is used which makes installing and running the demo applications much simpler than in the past.

Can’t wait? Try it now!

Open your favorite browser and head over to the Eclipse download page. To access the Neon milestone release make sure to click on the “Developer Builds” as indicated by the orange arrow in the screenshot below.

If you should run any issues or just like to share your experience with the new Scout Neon release please let us know in the Scout forum.

Outlook

For the Neon June release we plan to include Scout tablet support for the HTML5 UI. The Scout mobile support will not make it in time for the Neon June release and will be included in one of the Neon follow up releases. As soon as we can commit on a schedule regarding mobile support we will of course share this information with you.

For the remaining time for the Neon release the Scout project is concentrating on making sure that the Scout Neon release is production ready for commercial applications by the official release date.

On parallel tasks we now upgrading the central parts of the Scout documentation and co-organizing the Eclipse Neon Democamps in Munich on June 20th and Zurich on June 21st. We are looking forward to meet you there.

Feedback? Please use this forum thread

Scout Links

The Things Network and Eclipse Scout

Thu, 17 Mar 2016 07:44:00 +0100

The Things Network (TTN) is an open source project that aims at a global crowdsourced Internet of Things data network. In this blog post we describe a complete TTN show case to create real-time noise maps using the TTN in Zurich using a backend application based on Eclipse Scout and the MQTT Paho library.

TTN: A brief Introduction

After a highly successful campaign on Kickstarter last year, the project is now implementing the necessary infrastructure, designing/producing the promised hardware and spreading the word, for example at Eclipsecon next week.

Major benefits of the project are its distributed open source approach, the low price of the components, the range of several kilometers for gateways and the low power consumption of the involved LoRa technology for the “fog” part of the system.

The diagram below provides an overview over the setup including the noise measuring nodes and the TTN Gateways (the “fog”) on the left side, the TTN Cloud in frastructure in the middle and the backend application on the right side.

The described setup is currently using the somewhat simpler TTN prototype infrastructure. This setup is available since last year as well as instructions on how to set up your own gateway and your own nodes.

For the goal of this post the relevant aspects are the nodes on the left side that connect to one or more TTN gateways and the application on the right side that connects to a TTN handler service.

Low cost Nodes for measuring Noise

The goal was to assemble 40 complete nodes for less than €40. As a basis of the component selection we were using Teensy TTN node described in TTN Wiki. Due to additional taxes and some minor “mishaps” during production we ended up at €44 per node instead.

As shown below, the final node contains a microphone (1), a Teensy LC (2), a RFM95 LoRa module (3), an antenna with a company flag (4) as well as a battery box (5) inlcuding 3 AA batteries.

After being switched on, the node starts to measure differences in air pressure levels over short time windows that roughly correspond to the current noise level. Every two minutes the node then transmits the largest measured noise level and the “amount” of noise accumulated over the two minute period.

When the node is located within the range of a receiving TTN gateway, the data package is then forwarded to the TTN prototype setup.

The source code of the noise measuring node is available on Github.

The Scout Backend Application and a MQTT Paho Client

As the TTN prototype setup also includes a MQTT interface it is straight forward to implement applications that can response near real time to incoming TTN packets.

To implement an end-to-end TTN show case a backend application was implemented to display the data packets sent by the TTN noise nodes. The implementation of the user interface is based on Eclipse Scout and for the communication with the MQTT broker the Paho Java Client Library is used.

The screenshot below shows the transmitted noise levels with its corresponding time stamps. Noise levels of 10 or more indicate a train

By assigning coordinates to noise nodes, the Scout application can also show the noise levels on a real-time map. The picures below shows two situations with four noise nodes distributed at the outside of the BSI office in Zurich. During a time window with trains passing higher noise levels were measured by nodes that sit closer to the railway tracks (left image) than during a time window without any passing trains (right image)

As in the case of the noise measuring nodes, the source code of the Scout TTN application is available on Github. In addition, the application is also available as a Docker image on Docker Hub and deployed as a live instance.

Feedback? Please use this forum thread.

Scout links

Eclipse Workspaces with Oomph

Tue, 22 Dec 2015 16:26:47 +0100

Oomph is not only about eclipse installation, it changes also the way you organize your workspaces.

Multiple Eclipse installations

In my previous blog post I have explained why you can have as many eclipse installations as you want (an installation is 20 MB, the bundle pool is shared and maintenance like updates can be automatized). This solves another problem I had: I have a lot for workspaces and I never knew with which eclipse I should open it.

The basic Idea is simple: a workspace containing a scout application should be opened with “Eclipse for Scout Developers”. My Xtend experimentations should be opened with “Eclipse IDE for Java and DSL Developers” and so on… But when you start to have several versions of each IDE (if you consider some of the Milestone releases, there are a lot of Eclipse versions) you have no chance to remember it properly.

It gets worth when I try something different. I need to remember in which version of the “Eclipse Modeling Tools” I did install the MoDisco plugins to try this project out… (Was it Luna? Was it Mars?). The same goes for the Eclipse B3 tools I have installed this tool to create a maven repository for Mylyn Wikitext. Where did I install it? It is a mess!

The Oomph way

When you start to work with Oomph, you control where Oomph will install and checkout all the components needed for the setup. What is particularly interesting is that you can work with patterns that are reused for each of your installations. I have decided to stay with the default setting:

Installation location rule: “Installed in a uniquely-named folder inside the root folder”.
Workspace location: “Located in a folder named 'ws' within the installation folder”.
Git clone location rule: “Located in a folder named 'git/' within the installation folder”.

With those settings, the structure I get for each of my installations is the same:

Git clones per repositories

First I wasn’t really convinced by the idea of checking out the Git Repo each time. Now I have reconsidered it:

When we were using SVN we had a checkout in each workspace. It makes sense and we were happy with it. Applied to Git the same reasoning means that we need to clone the remote repository for each workspace. (A checkout corresponds to a “Working Tree”).

It takes disk space, but it solves problem you get when you share a git repos between multiple Eclipse Workspaces. The IDE gets lost with switches between branches that are too different. With Eclipse Scout we have a good example of different branches: our Mars branch contains Eclipse Bundles (OSGi) and our Neon Branch contains plain maven projects.

Git 2.5 has introduced the possibility to have multiple working trees for a single repo. When this feature will be available in JGit/EGit, the situation can be reconsidered. In the meantime, having each git repository cloned per workspace is a good solution.

New working workflow

I really like the workflow proposed by Oomph. The structure created by Oomph “eclipse/git/ws” makes sense. During the Oomph tutorial at the EclipseCon Europe, Wayne Beaton added that he started to consider this structure as something “really transient”. This is absolutely true for project you occasionally contribute to. You set up an eclipse for the projects you need; you contribute a patch; you remove the corresponding eclipse installation (once your patch is accepted).

It is possible to work like this, because recreating the installation if you need it again only takes a couple of minutes. This is similar to running a VM in the cloud: you no longer take extra care of it as you did with your company server, because when you no longer need it or when it is broken you kill it and you start automatically a new one. It is the same principle with your eclipse installation.

Oomph for Eclipse Scout

In the Eclipse Scout team, we see Oomph as a possibility to reduce the barrier to entry for external contributors. With oomph the knowledge required to start contributing a patch is reduced and the time it takes to do the setup should also be smaller. We have started to use Oomph inside our company and we hope to be able to share it with our open-source community in the next weeks.

Feedback? Please use this thread on our forum.

Scout Links

Project Home, Forum, Wiki, Twitter, Google+

Scout goes Java and HTML5

Wed, 16 Dec 2015 14:07:54 +0100

As announced early this year there are big news for the Scout framework with then Eclipse Neon release: Scout becomes a plain Java application framework and gets a completely new HTML5 rendering component.

With the Eclipse Neon release the Scout project addresses two pain points that many Scout projects experienced in the past years. The integration of Scout applications with Java enterprise technology and the rising standards of web applications regarding styling and usability.

Over the upcoming milestones we will report about our progress and talk about the most prominent changes and all the new features of the Scout Neon release. With Neon M4 we are proud of what has been achieved so far and would like to share our current state of development.

A new HTML5/CSS3/JS Renderer

Scout comes with a completely new HTML5 renderer that offers support for styling and theming of Scout applications.

The styling of Scout applications is based on CSS3 and Less preprocessing. Out of the box the new renderer offers a default styling that can be adapted to a customers CI/CD scheme using project specific less files.

Styling

Properties like colors, fonts and sizes of user interface (UI) components may be changed globally in a few central styling files.

For more advanced use cases it is also possible to style individual Scout UI components with project specific less files for individual components.

Theming

To build applications that offer the user a choose of different styling options the new Scout renderer also supports theming. This feature may be used to define high-contrast themes or individual themes for multi-tenant applications.

Scout also allows to switch between different themes at runtime as implemented in the Neon version of the Scout "Contacts" application.

Java Platform and Building

As Scout applications are becoming plain Java applications Maven can be used for building alone (no more Tycho needed).

Consequently, the creation of a new Scout Hello World application with the Scout SDK package is now based on a Maven archetype and the Scout SDK now comes with the Maven support offered by the M2Eclipse project.

Checking out the structure of the Scout Hello World application shows that it is organized as a classical Maven multi module project that may be built within the Eclipse IDE or on the command line using 'mvn clean install'.

Documentation

In parallel of developing the Scout Neon release we are also updating the documentation using our new Asciidoctor toolchain.

The first priority was updating the Scout installation guide and the Scout Hello World tutorial. Updating the documentation for the Neon release will require larger than usual efforts.

As the complete documentation including code examples is hosted on Github you are of course more than welcome to boost our efforts to complete/improve on the current state :-)

Feedback? Please use this forum thread.

Scout Links

Project Home, Forum, Wiki, Twitter, Google+

Oomph changes the way you handle multiple eclipse installations

Fri, 27 Nov 2015 08:53:28 +0100

Oomph is a great technology available with the Mars version of Eclipse IDE.

I work on many Eclipse projects and projects based on Eclipse technologies. I have of course the project I work on for our customer (daily job), but I also try to contribute to different open source projects and I also like trying new stuff and playing around with new technologies.

All these different tasks require different Eclipse installations. When I experiment with Xtend I use “Eclipse IDE for Java and DSL Developers”. Sometime I need an IDE with Maven support, but not always. After the EclipseCon I just installed an Eclipse supporting Gradle and Groovy development.

So far, I have never tried to install everything in the same Eclipse IDE. I feared the RAM consumption, overloaded menu trees and an IDE containing too many plugins. So I ended up with a folder containing different eclipse installations (one for each domain):

Such a folder structure both consumes disk space and maintaining each installation is time consuming and repetitive. Take the Mars.1 update release as an example. I have so many bad reasons for not updating my IDEs: it is boring, it takes time, it takes disk space, ….

At the last EclipseCon Europe I finally found the time to get into Oomph and the great new is: with Eclipse Oomph (a.k.a. Eclipse Installer), I am convinced that I can do much better than in the past.When you look at a classic Eclipse installation, it looks like this:

I wasn’t really aware of it, but this folder contains the result of 3 different mechanisms: an Eclipse installation containing the executable and some configuration, a p2 bundle pool where the plugins are effectively stored and a p2 agent that keeps everything together by storing the installation details into profiles. Oomph takes advantage of the flexibility offered by P2 and does not create a standalone installation.

The main advantage of this approach is that the Bundle Pool can be shared across your Eclipse installations. This drastically reduces the disk space for your eclipse installations. It also reduces the time it takes to install and to update each of your eclipse installations.

When you install something in one IDE, files are stored in the bundle pool. Installing the same plugin again in another IDE is straight forward. Oomph just updates the profile and reuse the files already present in your bundle pool.

In addition Oomph is all about setting up your Eclipse environment. Automation is the key word here. You can easily define setup tasks that are shared across all your Eclipse installations. This way you no longer loose time with modifying the default Eclipse settings to obtain the installation you want.

The Oomph approach is really great. In my opinion you can now have one Eclipse IDE setup for each project you work on. On this blog I will continue to explain the advantages of Oomph and what it changes when you work with it. The Scout team will of course also contribute a setup task to facilitate contributions on our framework.

Feedback: please use this forum thread.

Scout Links

Project Home, Forum, Wiki, Twitter, Google+

When reporting a bug helps to improve Eclipse.

Fri, 23 Oct 2015 09:27:27 +0200

When he writes about Automated Error Reporting Marcel Bruch uses this tagline "Because you can't fix what you don't know is broken". I can only support this message and reporting broken stuff is more rewarding than just ranting too.

A good Bug in Bugzilla that is not a duplicate, includes good description, examples and steps to reproduce typically adds a lot of value for the project. Such bugs substantially reduce the effort for the project committer to come up with a fix. This makes it more tempting to actually fix the bug which in turn improves the experience for all Eclipse users.

To illustrate this mechanism I would like to share a small story about a recent JDT bug. It started as a discussion on our private company communication platform. In our Scout application we have a lot of inner-classes. When we try to open one of this inner-class with CTRL+Shift+T

The read only Editor opens the correct file but does not jump at the correct location.

Everybody in our company has encountered this bug… This is just annoying, because we are used to scroll to the desired location. The mood of our internal discussion thread was something like "Good point, thank you for asking"; "Yes it is broken, a lot of coworkers know about it"; "We have googled for a solution, no result so far"; "It works for first level inner-classes but not for inner-classes in inner-classes". Later we figured out that nobody has ever reported it in Bugzilla. We started working on a small example to reproduce the problem. Finally my coworker opened Bug 476304.

Only one week later the bug was confirmed and a patch was proposed by a JDT commiter…

With the Neon M2, the Editor works as expected:

What are the lessons here?

Stop ranting
Open good bugs – or – amend existing bugs with better information

Investing time for high quality bugs pays off. If you need to convince your manager, feel free to cite our small example: In our case the return on investment was very high (we have invested few hours and we got a solution for a problem that annoys the wide majority of our coworkers).

If you ask me, this is nothing more than being engaged in a great open-source project. And having many engaged users is what makes Eclipse a great IDE.

Feedback? use this forum thread.

Scout Links

Project Home, Forum, Wiki, Twitter, Google+

Use the latest (neon) version of the formatter with mars

Fri, 16 Oct 2015 13:28:55 +0200

If you are using the Mars Version of the Eclipse IDE you have probably noticed the new java formatter. The new formatter solves a lot of bugs (some of them were open since a long time in Bugzilla, see Bug 303519 for a long version of the story) but as with any piece of new software, it also comes with some new ones.

A lot of bugs have already been fixed on the master branch and backported to be available with the Mars.1 release. In our company, we have already updated our IDE distribution in order to benefit from the latest fixes.

Fixing bugs is an ongoing process and we continue to see additional bugfixes on the master branch (where the Neon version of Eclipse is developed). Updating to a nightly, weekly or milestone release of the Neon version isn’t something we want to do now for all our coworkers. So we stay with Mars, but the next Mars release will only be available in February 2016 and we still would like to profit from backported bug fixes before. What to do?

We have figured out a way to take advantage of the fixes now instead of waiting until the next release. Based on the approach described by Mateusz Matela it is possible to put the latest version of the formatter (code taken on the master branch of the JDT project) in a Plugin you can use today with your Mars IDE. Our first tests with the plugin show that the fixes are working well for us. If you have similar needs you can find the plugin I have prepared on GitHub and install it from BinTray using this update site:

https://dl.bintray.com/jmini/java-formatter/

To use the new formatter, you should select it in the appropriate preference page:

If something does not work for you, reporting it might help the JDT team to further improve the java tooling. And the best part: As said above, sometimes you don't even have to wait for the next official release.

I was asked on twitter why I was doing such a thing. I must confess that I started it as a simple proof of concept, but it illustrates two very important aspects of Eclipse IDE: it is an open-source project where you can follow what is going on (bugtracker, git repository…). You are allowed to take a part of the source code and do something else with it. The projects are very modular: it is nice to see that exchanging the formatter engine is something that is as simple as adding a new plugin and changing a setting in the preferences. For me those are killer features of this product.

Please do not hesitate to send me some feedback. You can use this forum thread or your favorite social media.

Scout Links

Project Home, Forum, Wiki, Twitter, Google+

Overriding a method in Eclipse IDE and (non-Javadoc) comment lines

Fri, 02 Oct 2015 09:44:13 +0200

Do you want to change the comment lines generated by Eclipse when you override a method? Here is how to do it.

Almost everything is configurable in Eclipse. If the default values do not work for your project, you should invest time to tune your IDE. Yesterday a colleague told me about a configuration to change something I found annoying every day: By default, when you override a method in a child class in Eclipse you get something like this:

@Order(10.0)

public class ViewDetailsButton extends AbstractExtensibleButton {

 /* (non-Javadoc)

 * @see org.eclipse.scout.rt.client.ui.form.fields.button.AbstractButton#execClickAction()

*/

 @Override

 protected void execClickAction() throws ProcessingException {

 // TODO Auto-generated method stub

 super.execClickAction();

I never understood why the "(non-Javadoc)" comment lines were generated and I always removed them. This is not really a big deal (moving the cursor, pressing CTRL+D, going back to the method body) and I could live with it. Now that I know that switching off the generation of those line can be configured, I ask myself why I did not did it sooner.

Under preferences, open the "Code Templates" preference page (under the Java code style). Select "Comments > Overriding methods" in the tree and click on the "Edit…" button. In the second Dialog you can edit the pattern.

I have removed the pattern completely. After having saved the changes, it works as expected, when you override the method you don’t have the "(non-Javadoc)" lines anymore.

Even if I do not care about those comment lines, I like to understand the code patterns I meet. If I got it right, the lines were useful when @Override could not be used (@Override was introduced with Java 1.5. Since Java 6 it can also be used for methods defined in a parent interface). My guess is that the "@See" line was used by the developer to keep track of the location of the super method. In addition "(non-Javadoc)" seems to be a marker to define a third sort of comment called "non-Javadoc comment". This is something between multiline comment syntax (/* …*/) and the javadoc comment syntax (/** … */). I could not find out if some tools still understand and handle this syntax or not. To summarize: my guess was correct, this is a legacy pattern and I do not care about it (as far as I remember I never programmed with Java 1.4).

I am always happy to write a blog post about Eclipse configuration. I like to share stuff I have learned and I encourage you to tune your IDE in order to have an Eclipse that does what you need the way you want it. As always we welcome feedback on in the dedicated thread on our Eclipse Forum.

Scout Links

Project Home, Forum, Wiki, Twitter

Maven repository for Mylyn Wikitext

Sun, 27 Sep 2015 12:32:06 +0200

With this maven repository, it is possible to consume the Mylyn Wikitext jars in a maven project (the released version instead of the snapshot version).

Mylyn wikitext is a great tool to work with lightweight markup languages. It supports languages like MediaWiki, Markdown, Textile… It also provides some features to build content for the Eclipse Help Center. A lot of eclipse projects use this approach to build their help content using the Eclipse wiki as input. Since version 2.0 the project dropped the OSGi dependency, making it easier to consume the jars in a plain java and maven context.

For the Eclipse Help Center, I have published an article about creating a toc xml file for existing HTML pages on this blog. Having a Java code snippet is good, but it isn’t sustainable: what about sharing this code between multiple modules, what about tracking modifications and issues. I am happy to announce that I have released a maven plugin for this: geneclipsetoc. Maybe this code could be integrated directly in the Mylyn Wikitext project (Bug 478466 is opened for that).

During the release process of my geneclipsetoc plugin I discovered that the jars released by the mylyn wikitext project are not available from a maven repository. This is a problem when you start to build something that depends on the Mylyn Wikitext. For this use case the snapshot repository provided by the project is not enough.

Using the Eclipse B3 tool (more on this in a next blog post), I was able to publish the Mylyn Wikitext jars coming from the Simultaneous Release train into a maven repository hosted on Bintray.

I have published in a gist a minimal example (java class and pom file) that uses Mylyn Wikitext to convert a markdown snippet into HTML and print it.

I am wondering if the Mylyn Wikitext core jars should not be pushed on maven central. Have you an opinion about this?

This plain maven world is new to me. If you have an opinion about my approach or my code, I would appreciate to hear feedback from you in this forum thread or in one of the issue tracker. The debate about having a maven repository for the releases is not new for the Mylyn Wikitext project; of course I cross posted this information in the corresponding bug.

Scout Links

Project Home, Forum, Wiki, Twitter

Eclipse IDE: Get rid of the "java.awt.List" proposal in "organize imports"

Mon, 31 Aug 2015 09:44:23 +0200

Organize imports does not work for the “List” type out of the box as there is more than one “List” type in Java. Most often, we are only interested in “java.util.List” but not in “java.awt.List”. So, if you too are not programming using the AWT API, you should definitively tell it your Eclipse IDE.

As I always use the “Organize Imports” feature of Eclipse my Eclipse IDE is always configured accordingly (at workspace or at project level).

This usually works well except for the “List” type: Eclipse does not decide for you if you mean “java.util.List” or “java.awt.List”. This is absolutely fair and I am used to fix it with the corresponding quick fix: “Import 'List' (java.util)”

When I work on an Eclipse Scout application, I never need anything from java.awt. Luckily, I recently learned how to teach this to my Eclipse IDE:

In Preferences > Java > Appearance > Type Filters, then add “java.awt*” in the filter list.

With this additional setting, Eclipse is able to pick “java.util.List” as automatic import for List.

I have already adopted this setting in all my workspaces.

You can use this forum thread, to share your feedback.

Scout Links

Project Home, Forum, Wiki, Twitter

Eclipse Scout Day 2015

Thu, 27 Aug 2015 14:03:32 +0200

If you are interested in Eclipse Scout framework or if you are developing Scout applications during your day job, this is the event to attend.

On November 2nd we are organizing the Scout user group meeting as part of the Unconference right before the Eclipsecon Europe. Participation requires registration but the Event is open for anyone interested.

Dinner at the Rossknecht in Ludwigsburg

Listening to presentation about industrial use case with Scout

At the event, Eclipse Scout committers will demonstrate the current state of the Scout Neon release featuring the new HTML5 UI including full CSS styling as well as the move of Scout to a Java only framework that facilitates the integration of third party Java and Java EE technologies.

To document the event details and build an agenda that does focus on the actual interests of the participants we have created a corresponding wiki page. There is also an online poll to ask you about the topic areas of interest to you and a forum thread for public questions and comment. For anything else that you might want to ask/discuss you can contact us via scout@bsi-software.com.

The Scout user group meeting is not only about learning about the Scout framework, its new features and the change to a Java only framework. At least as interesting are the presentations from Scout adopters that tell their story and share their experiences with using Scout for their specific use case. As soon as the process is hammered out with the Unconference organizers we will update our wiki page and let you know via @EclipseScout and forum.

And last but not least, the Scout user group meeting is fun and provides many networking opportunities with fellow Scout adopters and committers. Don't hesitate and register here for November 2nd.

Looking forward to see you in Ludwigsburg.

Scout Links

Project Home, Forum, Wiki, Twitter

Gerrit inline editing Feature

Tue, 25 Aug 2015 10:56:53 +0200

Fixing Bug 473139 was the perfect opportunity for me to test the new inline editing feature offered by the Gerrit instance hosted by the Eclipse Foundation.

We have moved our Scout Blog to a new location:
https://www.bsi-software.com/en/scout-blog/

I have opened Bug 473139 to update our RSS Feed URL in the Eclipse planet configuration file.

This was for me a perfect opportunity to test the new inline editing feature of Gerrit. (See Denis Roy email on the “eclipse.org-committers” mailing list: New version of Gerrit deployed)

Here is how I created a new change for my Bug, directly on Gerrit:

1/ Search for the corresponding repository in the projects list.

2/ On the project page, click on the “Create Change”.

3/ In the dialog, select the branch, write the commit comment and click on the “Create” button.

4/ Click on the “Edit” button.

5/ Click on the “Add” button, search for the file and click on the “Open button”.

6/ Edit the File, click on “Save” and on the “Close” button.

7/ Click on the “Done Editing” button.

8/ Click on the “Publish Edit” button.

In my opinion, this is a great feature for small changes…

I like the live edit possibility on GitHub; we now have it also on Gerrit.

Please use this forum thread for your feedback.

Scout Links

Project Home, Forum, Wiki, Twitter

Eclipse Scout 5 is here

Thu, 02 Jul 2015 00:00:00 +0200

We are happy to announce that Eclipse Scout 5 is out. Taking part for the 5th time in the Eclipse simultaneous release train, Eclipse Scout 5 was released last week on 24.06.2015 as part of the Eclipse Mars Release.

Highlights of Scout 5.0.0 are:

Support for modular Scout Applications
Improvements Scout Runtime and SDK
Documentation

For details, check out our new and noteworthy page. To download the latest Scout release use the Eclipse package download page.

Scout Neon – the Outlook

As announced early this year, we have big plans on our roadmap for the Neon release. Most of the team has already been working for months on the develop branch. While the replacement of the Eclipse platform as dependency is already visible, the code of the new HTML5 renderer will be moved over later this year.

We will start to share the result with the coming Neon milestone releases over the coming months. If you have questions or would like to share your thoughts please use this forum post.

Scout Links

Project Home, Forum, Wiki, Twitter

Democamp Double Feature: Munich and Zurich

Tue, 30 Jun 2015 13:53:00 +0200

With close to 100 participants each, Munich and Zurich are among the largest Eclipse democamps. Last week, participants in the two towns north of the Alps had the opportunity to meet old and new friends and learn about a wide variety of topics in the Eclipse ecosystem.

Democamp Munich, June 23rd

The democamp in Munich was hosted for the second time in the building of Capgemini (many thanks to the friendly staff) and organized by BSI Business Systems Integration, EclipseSource Munich and Angelika Wittek.

The official sessions started with a demo by Tom Schindl presenting his e(fx)clipse Compensator project. Compensator, a set of loosely coupled components, can be used to build light weight IDE. With its Java FX front end the developer may take advantage of the available CSS styling. In the impressive second part of the demo the participants watched Tom assembling a small Dart IDE in less than 10 minutes that included syntax highlighting, error marks and code completion.

In the following session, Jörg Hohwiller demonstrated OASP4J-IDE that helps to quickly share and update complete Eclipse IDE setups for Java projects. As individual project installations do not interfere with each other developers are free to work with as many concurrent project setups as they need.

Next was Jens Reimann and Jürgen Rose with the Package Drone project that was accepted very recently as an Eclipse Foundation Project. With a Package Drone repository Maven Tycho can now also be used to upload software artifacts to a Package Drone repository. Once in this repository Package Drone can provide the artifacts in different forms such as P2 update site or a OSGi R5 repository. For future versions of Package Drone support for additional formats like APT and YUM are planned.

With Profiles for Eclipse (based on Oomph) Frederic Ebelshäuser was addressing the pains of reliably setting up your Eclipse IDE. Profiles for Eclipse is currently available via a proprietary Eclipse HUB portal that also includes some social features. Using this portal it is possible to share profiles between participants, following profiles and getting notified when subscribed profiles are updated.

In the last session before the break, Matthias Zimmermann demonstrated how to build modularized enterprise applications with Eclipse Scout. For modularization, the Scout framework supports both technical layers and business slices. Matthias also announced that with the Neon release train, Scout is removing its dependency on the Eclipse runtime and become a pure Java framework. At the same time, Scout will also get a HTML5 new renderer.

After the break, Alexandra Schladebeck presented the new Jubula Client API in an entertaining talk. With the new Jubula client API that is shipped with the Mars release UI tests can now also be written in the form of JUnit test cases. After the audience had to promise to use these new possibilities only with great responsibility, Tom Zierer performed a hands-on COBOL programming session for mainframe development creating a “Legacy in Action“ feeling. After demonstrating the pain of working with too many character based screens, an Eclipse based IDE was presented that covered syntax highlighting, compiling on the back-end, collecting the result and displaying error markers in the source code.

In his talk about EMF Forms Jonas Helming presented the state of version 1.6 that is shipped with the Eclipse Mars release. The session demonstrated the available tooling to create the view model that maps elements of an entity model to UI controls. After demonstrating the tooling to create a form to manage persons, the created UI was shown in preview mode and in the form of a standalone RCP application. Jonas also mentioned current work on JSONForms a new web renderer that is based on AngularJS.

The democamp in Munich concluded with the Eclipse Smarthome session by Jochen Hiller. This talk concentrated on demonstrating the new features such as the auto-dicovery for attached devices. In the extensive demo, a variety of devices such as light bulbs, smart sockets, audio devices and even a hair dryer were included. For the demo itself Jochen showed the new slick Paper UI of openHAB 2, that is based on the Smarthome project.

The democamp concluded with prolonged networking, buffet and beer that was greatly enjoyed by the participants.

Democamp Zurich, June 24th

Taking place for the 4th time, the democamp Zurich was very well attended and attracted around 90 participants. As in previous years, the Swiss Federal Institute of Technology (ETHZ) was hosting the democamp in one of the centrally located lecture halls and the event was organized by itemis Schweiz and BSI Business Systems Integration and with the Java User Group Switzerland as a partner organisation.

The first session in Zurich by Martin Lippert was all about the Spring and Cloud Foundry Tooling for Eclipse. The demonstration covered various aspects of setting up Spring projects with Spring Boot and included Spring development with advanced code completion, for example when working with YAML configuration files. As an experimental feature Martin also demonstrated the capability to debug a Spring application that is running on a server node in the cloud.

In the following three sessions before the break the audience was listening to contributions that have been presented the day before in Munich. Tom Schindl introduced the e(fx)clipse Compensator, Jonas Helming talked about the latest features of EMF Forms and Matthias Zimmermann demonstrated how to build highly modular enterprise applications with Eclipse Scout.

After a short break, Dierk Koenig presented Grails in a live-coding session to the audience (no slides). In this way Dierk demonstrated how simple data-centric applications can be built with Grails by creating a simple application to manage participants.

In the next talk Axel Terfloth introduced the audience into the Yakindu Statechart Tools, an Eclipse based open source project to specify, validate and implement event-driven systems based on state charts. After creating a first simple state chart, the demo included running simulations, adding parallel execution paths to the example and generating Java sources from the model.

Following the agenda in Munich Jochen Hillers Eclipse Smarthome session also concluded the democamp in Zurich.

In the networking session with food and beer many stimulated discussions took place. As the university was closing down earlier than the more commercial location in Munich, individual groups were simply taking the ongoing discussions to nearby beer places.

Democamps are about the participating People

From repeatedly attending and organizing Eclipse demcoamps it becomes obvious that these events are not only about learning new things and staying up to date with the projects presenting the latest features. Having developers and project leads on-site in an informal setting also allows for interesting discussions about work, personal views and potential collaborations. In addition, the local character of the democamps helps to build and maintain relationships across organisations over many years. It seems that this last point lets attendants come back to these events and makes them look forward to meet their colleagues.

If you have attended one of the democamps and would like to share your thoughts please use this forum post.

Scout Links

Project Home, Forum, Wiki, Twitter

Eclipse DemoCamp Zurich: June 24

Tue, 16 Jun 2015 13:14:00 +0200

We are looking forward to next week’s DemoCamp Zurich hosted at the ETH. Next to Eclipse SmartHome (Jochen Hiller), EMF Forms (Jonas Helming), e(fx)clipse Compensator (Tom Schindl), Eclipse Scout (Matthias Zimmermann) and the Yakindu Statechart Tool (Axel Terfloth), we also have two guest sessions with Martin Lippert presenting the Spring and Cloud Foundry Tooling for Eclipse and Dierk Koening giving a Grails live-coding demo.

If you’d like to join us for this DemoCamp and haven’t already registered, please do so now (or soon).

And, as always: Good location, great talks, free food and beer and a friendly crowd :-) see the impressions of last year’s DemoCamp Zurich below.

We would be happy to get feedback the corresponding forum thread.

Scout Links

Project Home, Forum, Wiki, Twitter

Documentation Platform for Eclipse Scout

Fri, 08 May 2015 15:39:00 +0200

Developers often see the documentation as a non-urgent task. As a result, documentation always ends up at the end of the task list. For an open-source project this is a dangerous approach as having no documentation at all, and even bad/outdated documentation represents a serious obstacle for growing a community successfully.

Currently, the Eclipse Scout project has a historically grown documentation. In the past, several approaches have been tried (wiki with and without the version in the page name, a book, html files, conversion of the eclipse wiki to the eclipse help format…). Although this approach can be considered to be a valuable learning experience, the project is now faced with the challenge of having various documents with overlapping content and different formats. This also increases the necessary efforts to keep the documentation in sync with the current release.

For our tooling stack we have this vision:

Automation of everything that is possible
Single source: produce the different outputs reusing different modules (website, tutorials, books, eclipse-help…)
Extract the code listings from existing real applications in order to be sure that the development is up-to-date.
Use a git repository instead of a wiki to ease the maintenance on different branches.

Here is how our big picture looks like:

[A]: org.eclipse.scout.docs (Work in progress, see Bug 465943)
[B]: org.eclipse.scout.sdk repo
[C]: eclipse.org/scout repo
[D]: stands for other documentations artifact like our Scout books.

Bug 465960 is an umbrella bug, where we track our activity in this domain.

With RC1 we will deliver an initial version of an “Eclipse Scout User Guide” (Eclipse Help format). This allows us to experiment with our toolchain based on Asciidoctor and some additional post processing steps.

A first version of the same content is already live on our homepage.

The content of the “example pictured is realized in two adoc files, the HelloWorldFrontend.adoc and the HelloWorldBackend.adoc.

We would be happy to get feedback and questions in the corresponding forum thread.

Scout Links

Project Home, Forum, Wiki, Twitter

Font Icons for Eclipse Scout

Thu, 23 Apr 2015 16:00:00 +0200

Today, web pages and web applications start to rely more and more on font icons. As clean and modern icons can help an application to get a professional look and feel we went through the little exercise to demonstrate how to use font icons in Eclipse Scout applications.

One of the most prominently used icon font on many web pages is Font Awesome. As the font contains hundreds of icons that are free to use even in commercial applications, it is ideally suited for demonstration purposes as well as productive use.

The reminder of the article describes the usage of such fonts for icons with Eclipse Scout.

To demonstrate the usage we added an icons and font icons form to the Scout Widget Application.

In the text below we will first talk about the general usage of icons in Scout application, and discuss how icons are provided to the application through icon provider services. Then the font icon provider services is introduced that allows to create Scout icons for individual characters from any true type font files.

How To Use Icons in Scout

Icons can be used for a number of UI components in Scout applications. They may be used for buttons, image fields, for smart fields entries, tree nodes and for table rows. To identify individual icons, its icon name/id can be used. The simplest way to figure out how to use icons in Scout applications is to follow the code of the Scout widget application.

For a concrete example we will look at the implementation for the button with the white arrow pointing to the right that is implemented in the icons form of the Scout widget application.

To find the corresponding code in the widget application, open the IconsForm and drill down to the ExamplesBox group box and locate the IconButton class. In method getConfiguredIconId the desired icon is specified as shown below.

@Order(4000.0)
public class IconButton extends AbstractButton {
  ...
 
  @Override
  protected String getConfiguredIconId() {
    return AbstractIcons.WizardNextButton;
  }
 
  ....
}

From this example we can see that a few icons come out of the box with the Scout framework. As every application has its own special needs, additional application specific icons may be located in the client plugin of the application. In the default case the corresponding image files may be placed in folder resources/icons of the client plugin. In the example of the Scout widget application the icon “star_yellow” is backed by image file star_yellow.png in the icon resource folder. This represents the simplest way to add your own icons to your application. Just put your icon image files into the folder resources/icons of the client plugin as in the case of the yellow_star icon.

However, designing good looking icons is time consuming and to get started quickly having a large amount of icons out of the box would be helpful. To take advantage of the fact that with the Font Awesome toolkit such a collection of high quality icons is available in the public domain, we can also write a specific icon provider that consumes the available icons from the Fontawesome true type font file at runtime.

The Font Icon Provider Service

Before we discuss the font icon provider service let us look at the general concept of icon provider service of the Scout framework. In Scout, icons are provided to the application through icon provider services. When a UI component needs to display an icon specified by its name, the Scout framework checks with the registered icon provider services to access the necessary image content.

At runtime, the icon name is fed into method getIconSpec of the first available service that implements the IIconProviderService interface. If the method returns null, the framework consults the next icon provider. This mechanism allows for the implementation of application specific icon provider services. There is one additional thing. To avoid the repeated generation of the image content, generated Icons are cached by the Scout framework. Instead of asking the icon provider services to create the content every time an icon is used, the framework first checks its cache, if an icon is already available from the cache, it will directly use this cached icon.

By writing a specific FontIconProviderService that converts characters from a true type font to Scout icons on the fly, font icons can be used along the traditional icons. To use font icons in the demo application only a few things are needed:

The font’s true type file (e.g. fontawesome-webfont.ttf) is located in folder resources/fonts of the client plugin
The alias information for the needed icons is specified in the icons.properties file (in folder resources/fonts)
The FontIconProvierService itself and its registration in the client’s plugin.xml

At startup of the FontIconProviderService, method initializeFonts is called through method initializeService that then loads the available true type fonts and properties file mentioned above. Using this information the icon provider service then returns the created font icons in method getIconSpec. The icon alias (IconId in the screenshot above) defined in the icons.properties file can either be used on its own or amended with various additional attributes:

Color (icon color, or icon background color if a background type is selected)
Size (true type font characters may be scaled to arbitrary sizes)
Background (to create inverted icons with a square or round background image)

In the example shown in the screenshot above, the icon specification is encoded into the string font:plane!#FAA635!128;fontawesome-webfont. This results in the search of alias “plane;fontawesome-webfont” in the properties file leading to the font’s character f072 that is then scaled to 128 pixels and colored using #FAA635.

To play around with the available options click on button “Sample Content” in the icons form of the widget demo application. There, you can change the icon id, the color, size and the background shape. When you switch the font from “fontawesome-webfont” to “cour”, you can also try to create an icon from a single letter (e.g. with the icon name “font:X!128;cour”).

Conclusion

In this post we have provided a quick introduction to the usage of icons in Scout applications and demonstrated how to use font icons in your own Scout applications. Using the provided FontIconProviderService you can now either use the discussed Fontawesome or use your own true type font files to extract font icons for your applications.

Scout Links

Project Home, Forum, Wiki, Twitter

Scout Team at Javaland: meeting with the Asciidoctor Guys

Thu, 02 Apr 2015 16:08:00 +0200

I really enjoy conferences, because it is a great opportunity for me to meet new people. Before going to a conference, I usually have a look at who will be there (looking at the program or at twitter). And often, some of the participants are experts in domains that matter for a current project I am working on and I can prepare a set of questions that I would like to discuss.

At last week’s JavaLand Conference I was able to take advantage of this habit regarding our efforts to refactor the documentation setup of the Eclipse Scout framework with Asciidoctor. If you don’t know Asciidoctor, I recommend you to watch any of Dan Allen‘s talks available online (for example Discover The Zen Of Writing (Ascii)Docs at Devoxx 2013).

Attending Dan’s Talk Effective AsciiDoc: Best Practices for Writing Docs (slides) and being able to discuss with him the day after helped me to find solutions to most of my Asciidoctor issues. From this and past experience I can only say that discussing with experts is always a great experience and helpful. And in case you haven’t done this in the past, give it a try at your next conference.

In the reminder of this blog post I will talk about the motivation behind the refactoring of the Eclipse Scout documentation setup and write about the Asciidoctor Live Preview plugin that I got to know at JavaLand.

Maintaining Documentation over many Releases is expensive

In the Eclipse Scout framework team, we have the ongoing task of maintaining and enhancing the project documentation. Currently, the documentation is spread over example repositories, wiki tutorials, wiki concept pages and the Scout book. While having some documentation is helpful to newcomers, having the documentation spread over several channels makes it confusing at times and increases the time needed to maintain the documentation up to date with the yearly release train at Eclipse.

To reduce our maintenance efforts and to simplify contributions we are currently investigating a possible refactoring of our documentation setup using an Asciidoctor toolchain. The main idea is to have only one platform where we can create the content and the platform would then allow us to generate the various components for the different channels (single page tutorials, Eclipse help plugins, Scout book, …)

Asciidoctor seems to be a promising approach for our needs and having both Github support for this format and the possibility of Live Preview in the browser is a big plus over our current setup based on Wiki, Latex, and more.

Visualizing Asciidoctor Document

Asciidoc documents are just plain text files, like source code or MediaWiki content and Latex source files. When you want to edit/read your work in short cycles having fast and simple rendering for the verification of the docs is important. Today, the easiest way to visualize Asciidoctor documents is to use the asciidoctor-chrome-extension.

Installing the extension is straight forward; you can download the Asciidoctor.js Live Preview Extension from the Chrome web store.

To properly work with local files you currently need to adapt the default settings. For this, first open the “Manage Extension” menu item that is “hidden” behind the context menu on the Asciidoctor Button in the Chrome Toolbar.

In the settings page, check the “allow access to file URLs” checkbox and click on the option link.

To allow the navigation over serveral local documents, you also need to update the save mode. In the “Options” page, switch the “safe mode” to “safe”. Do not forget to save your changes.

With this setup I can now use the Chrome browser to check the result of our first experiments with the new tool chain and have a nice preview of my local adoc files.

A particularly useful feature is the live update. Saving updates in the adoc files is enough to trigger a reload in the browser. And as we progress with our new setup, we will also try to share our experience with Asciidoctor.

Scout Links

Project Home, Forum, Wiki, Twitter

Eclipse.exe and windows processes

Thu, 19 Mar 2015 16:27:00 +0100

One of our clients mentioned that his users sometimes wish to kill the process associated with its Scout client application in the Windows Task Manager. Scout applications use the Eclipse Launcher exe like any Eclipse RCP application or the Eclipse IDE itself. I will use "eclipse.exe" as application name in this blog post.

The problem was that in order to completely terminate the client application, they need to be aware of the fact that their application was actually running in two processes, the eclipse.exe and the javaw.exe process. By just using “End Process” (button or context menu) on the eclipse.exeprocess in the Task Manager, only the smaller process is killed and the much larger javaw.exe process continues to run. Only by selecting “End Process Tree” in the task manager the complete application is terminated. Only few users were aware of this setup that is not really user-friendly.

After some investigation we could propose a solution to address the client’s issue. The Scout client application now appears as a single process in the Task Manager and it no longer matters if users click on context menu “End Process” or “End Process Tree”.

In the reminder of this article we summarize our findings that should directly apply to any Eclipse RCP application or the Eclipse IDE itself.

To visualize the dependencies between the individual Windows process the Windows Process Explorer Tool can be used.
Using this tool we can now see how javaw.exe is a sub process of eclipse.exe:

In this case eclipse.exe is quite an empty process and killing it without killing the process tree does not free the memory allocated to the javaw.exe process.

In the past, we have noticed that eclipse applications containing a JRE subfolder (“Bundle JRE for this Environment with the product” in the product editor) were represented by a single process in the Task Manager. It also works if instead of a JRE subfolder, a shortcut pointing to the real JRE folder is used.

It is possible to create the same behavior by letting the -vm parameter point to the jvm.dll instead of the in the javaw.exe in the eclipse.ini file (see also the list of runtime options for the eclipse.ini file)

With the following setting in the eclipse.ini file the client has a single process that represents the Scout RCP client.

-vm C:\Java\JRE-1.8.0_40_win64\bin\server\jvm.dll

Using the Windows Process Explorer we can now verify, that the eclipse.exe process does no longer start any sub-process.

For our client, this solution is much better. It is more user-friendly and prevents unnecessary calls to the support hotline.

Scout Links

Project Home, Forum, Wiki, Twitter

Eclipse Scout Roadmap 2016

Tue, 24 Feb 2015 16:47:00 +0100

For the 2016 release of the Scout framework we will introduce two significant changes. These changes address major pain points we have suffered from in the past. As the scope of the two changes is substantially larger than in previous releases, we would like to start talking about them well ahead of time. So remember in the text below that this is a blog about the future of Eclipse Scout scheduled for 2016, not about the upcoming Mars release.

The first change is driven by our vision of the future of UI technologies for business applications. The second change addresses the need of our customers and BSI that Scout applications should be easy to integrate in a Java EE or Spring based environment. In the text below we will discuss these two changes individually.

A new HTML5 Renderer

The first change is based on our belief that the future of business applications mostly lies in the domain of web applications. In consequence, Eclipse Scout needs to provide the best possible web experience for the users of Scout applications. And to achieve this goal for the 2016 release, we already have started to write a new Scout web rendering engine, directly based on HTML5/CSS3 standards. Thanks to this substantial investment of BSI, Scout applications will comply with the new de-facto standard for web applications and will be able to take advantage of the latest web technologies in the future.

This decision also implies that future Scout web applications are no longer based on the Eclipse RAP project. At the same time, discussing this topic extensively with our customers, we found that their demand for the existing Swing and SWT rendering components no longer matches the necessary expenses to maintain these components. This is why we decided to discontinue the Scout SWT and Swing desktop rendering components after the Eclipse Mars release.

Eclipse Scout will become a Java framework

The second change affects the foundation of Eclipse Scout applications. Currently, Eclipse Scout applications are based on OSGi and the Eclipse runtime platform. In the past, we have addressed the challenge to integrate a plugin based application with Java EE technologies again and again. And according to some Scout customers, integrating the plugin based Scout server with Spring technology did cost them significantly more time than anticipated.

Observing the market and the need of our customers over the past years, we have come to the conclusion that Scout’s dependencies to OSGi/Eclipse platform did bring more harm than good to Scout projects. This is why we now started to implement replacements for familiar Eclipse concepts such as jobs, extension points and services.

As a result of this second change, Eclipse Scout applications will become standard Java applications that will seamlessly integrate with Java EE technologies and other Java frameworks, such as Spring. We also hope that this change will increase the adoption of Eclipse Scout in the Java domain.

What will stay the same?

Although the changes mentioned above may seem substantial, it is important to keep in mind that most aspects of the Eclipse Scout framework remain the same.

Scout will continue to be an Eclipse Open Source project.
The Scout SDK will continue to be based on the Eclipse IDE.
The existing Scout application model will (mostly) stay as it is.
Migration efforts for existing Scout applications will remain rather modest (with the exception of the rendering part for your custom controls, if any).
From the Scout developer perspective these changes will probably not feel exciting. But this is by design.
And to avoid confusion: The Scout Mars release will still be shipped with the known RAP, SWT, and Swing rendering components.

Your Feedback?

Whether you like these changes or are concerned regarding your plans for Eclipse Scout please let us know. Please contact us on the Scout forum. For discussions we have created separate topics. One for the new HTML renderer and another one for removing the Eclipse/OSGi dependencies.

If you prefer a less public channel for discussing these changes you can contact us by email to scout@bsiag.com. Your feedback is very valuable to us and we would like to find/discuss options if you have any concerns or questions.

Scout Links

Project Home, Forum, Wiki, Twitter

Scout Adopters we didn’t know about.

Fri, 20 Feb 2015 16:57:00 +0100

At BSI (the company behind the Scout Framework) we have recently discussed our knowledge about the community of Eclipse Scout users and found that it is too limited. This was one of the lessons we learned from our first Scout User Group Meeting. For this meeting we have invited our Scout customers and colleagues. By customer we mean individuals from companies that have paid for services in relation to Scout (consulting, trainings, change requests, project bootstrap, …). And by colleague we mean people we already met (at conferences or democamps) that where doing something with Scout. This get together was important, informative and supported the networking between customers/contacts. However, we found that the real challenge is to contact and learn from Scout adopters that we do not know (yet).

Eclipse Foundation Policy and Set-up.

Both the legal and the technical set-up at the Eclipse Foundation allows interested people to use any Eclipse project without any form of identification. This is great for adopters, but makes it hard for the project teams to learn more about their users. From the conversations I had with the Eclipse Foundation staff member, a registration form is something that we will never have at eclipse.org because this is against the Eclipse policy. So we had to find another path to contact our adopters.

In order to start learning more about our Scout community we decided to try to use the Scout Forum as a starting point. The reason for this decision was based on the observations that we have most of our existing interactions on this channel and that we enjoy a friendly and constructive atmosphere there. And since about 2 months, we ask our regular forum visitors (when we think that they must have built something serious with Scout) to tell us more about themselves and their project. We have made the experience that a good place to ask this question is at the end of a precise answer to a specific question. Then, they can write us an email scout@bsiag.com or fill a “Made with Scout Survey”. The proposition is of course visible and open for everybody at the forum, but asking specific individuals works much better.
We believe that this is a fair compromise to the community members, as they are free to answer or not and their answer does not affect the quality of the answer we continue to deliver.

What are we doing with the Survey Data?

Not much, really. Often we exchange some emails and then agree on a phone or skype call. In the call we are most interested in the background of the people, their experience with Scout so far and what they are currently working with Scout. This external feedback then helps us to improve the Scout experience and to focus our investment on those aspects that are considered valuable for these individuals. Of course, we are only at the beginning of this journey but so far this approach proved to be a valuable experience for both sides.

Some success so far?

In late January I got an email from József Agg. The Application he made with Eclipse Scout is a backend system for a Hungarian travel agency publishing content with JAX-RS to web CMS front end.
The attached screenshots are really impressive, that is why I would like to share them in this blog post.

If allowed, we will also add a screenshot of József’s application to the screenshot gallery on our Eclipse Scout Homepage.

If you are using the Eclipse Scout Framework!

Like József did, please tell us about. We will be happy to get in touch with you. You can:

Fill this survey: Made with Scout
Drop us an email: scout@bsiag.com

We really hope to meet more of you and would be happy to invite you to our second Scout User Group Meeting too. According to our planning so far, the event will take place in Ludwigsburg on the Monday of the EclipseCon Europe 2015.

Scout Links

Project Home, Forum, Wiki, Twitter