introduction the devon ide
"Devon IDE" is the general name for two distinct variants of a customized Eclipse IDE. The Open Source variant — called devonfw-ide — is publicly available for everyone. A more extended variant is included in the "Devon Dist", which is only available to Capgemini employees.
devonfw comes with a fully featured IDE in order to simplify the installation, configuration and maintenance of this instrumental part of the development environment. As it is being included in the distribution, the IDE is ready to be used and some specific configuration of certain plugins only takes a few minutes.
As with the remainder of the distribution, the advantage of this approach is that you can have as many instances of the -ide "installed" on your machine for different projects with different tools, tool versions and configurations. No physical installation and no tweaking of your operating system required. "Installations" of the Devon distribution do not interfere with each other nor with other installed software.
There is inbuilt support for working with different workspaces on different branches. Create and update new workspaces with a few clicks. You can see the workspace name in the title-bar of your IDE so you do not get confused and work on the right branch.
In the Devon distribution we have a code generator to create CRUD code, called CobiGen. This is a generic incremental generator for end to end code generation tasks, mostly used in Java projects. Due to a template-based approach, CobiGen generates any set of text-based documents and document fragments.
CobiGen is distributed in the Devon distribution as an Eclipse plugin, and is available to all Devon developers for Capgemini engagements. Due to the importance of this component and the scope of its functionality, it is fully described here.
Since an application’s code can greatly vary, and every program can be written in lots of ways without being semantically different, IDE comes with pre-installed and pre-configured plugins that use some kind of a probabilistic approach, usually based on pattern matching, to determine which pieces of code should be reviewed. These hints are a real time-saver, helping you to review incoming changes and prevent bugs from propagating into the released artifacts. Apart from CobiGen mentioned in the previous paragraph, the IDE provides CheckStyle, SonarQube, FindBugs and SOAP-UI. Details of each can be found in subsequent sections.
CheckStyle is a Open Source development tool to help you ensure that your Java code adheres to a set of coding standards. CheckStyle does this by inspecting your Java source code and pointing out items that deviate from a defined set of coding rules.
With the CheckStyle IDE Plugin, your code is constantly inspected for coding standard deviations. Within the Eclipse workbench, you are immediately notified with the problems via the Eclipse Problems View and source code annotations similar to compiler errors or warnings. This ensures an extremely short feedback loop right at the developers fingertips.
If your development team consists of more than one person, then obviously a common ground for coding standards (formatting rules, line lengths etc.) must be agreed upon - even if it is just for practical reasons to avoid superficial, format related merge conflicts. CheckStyle Plugin helps you define and easily apply those common rules.
The plugin uses a project builder to check your project files with CheckStyle. Assuming the IDE Auto-Build feature is enabled, each modification of a project file will immediately get checked by CheckStyle on file save - giving you immediate feedback about the changes you made. To use a simple analogy, the CheckStyle Plug-in works very much like a compiler but instead of producing .class files, it produces warnings where the code violates CheckStyle rules. The discovered deviations are accessible in the Eclipse Problems View, as code editor annotations and via additional CheckStyle violations views.
After IDE installation, IDE provides default CheckStyle configuration file which has certain check rules specified . The set of rules used to check the code is highly configurable. A CheckStyle configuration specifies which check rules are validated against the code and with which severity violations will be reported. Once defined a CheckStyle configuration can be used across multiple projects. The IDE comes with several pre-defined CheckStyle configurations. You can create custom configurations using the plugin’s CheckStyle configuration editor or even use an existing CheckStyle configuration file from an external location.
You can see violations in your workspace as shown in below figure.
So, once projects are created, follow steps mentioned below, to activate CheckStyle:
-
Open the properties of the project you want to get checked.
-
Select the CheckStyle section within the properties dialog.
-
Activate CheckStyle for your project by selecting the CheckStyle active for this project check box and press OK
Now CheckStyle should begin checking your code. This may take a while depending on how many source files your project contains. The CheckStyle Plug-in uses background jobs to do its work - so while CheckStyle audits your source files you should be able to continue your work. After CheckStyle has finished checking your code please look into your Eclipse Problems View. There should be some warnings from CheckStyle. This warnings point to the code locations where your code violates the pre-configured Checks configuration.
You can navigate to the problems in your code by double-clicking the problem in you problems view. On the left hand side of the editor an icon is shown for each line that contains a CheckStyle violation. Hovering with your mouse above this icon will show you the problem message. Also note the editor annotations - they are there to make it even easier to see where the problems are.
FindBugs is an open source project for a static analysis of the Java bytecode to identify potential software bugs. FindBugs provides early feedback about potential errors in the code.
It scans your code for bugs, breaking down the list of bugs in your code into a ranked list on a 20-point scale. The lower the number, the more hardcore the bug.This helps the developer to access these problems early in the development phase.
IDE comes preinstalled with FindBugs plugin.
You can configure that FindBugs should run automatically for a selected project. For this right-click on a project and select Properties from the popup menu. via the project properties. Select FindBugs → Run automatically as shown below.
To run the error analysis of FindBugs on a project, right-click on it and select the Find Bugs… → Find Bugs menu entry.
Plugin provides specialized views to see the reported error messages. Select Window → Show View → Other… to access the views. The FindBugs error messages are also displayed in the Problems view or as decorators in the Package Explorer view.
SonarLint is an open platform to manage code quality. It provides on-the-fly feedback to developers on new bugs and quality issues injected into their code..
It covers seven aspects of code quality like junits, coding rules,comments,complexity,duplications, architecture and design and potential bugs. SonarLint has got a very efficient way of navigating, a balance between high-level view, dashboard and defect hunting tools. This enables to quickly uncover projects and / or components that are in analysis to establish action plans.
IDE comes preinstalled with SonarLint. To configure it , please follow below steps:
First of all, you need to start sonar service. For that, go to software folder which is extracted from Devon-dist zip, choose sonarqube→bin→<choose appropriate folder according to your OS>-→and execute startSonar bat file.
If your project is not already under analysis, you’ll need to declare it through the SonarQube web interface as described here. Once your project exists in SonarQube, you’re ready to get started with SonarQube in Eclipse.
SonarLint in Eclipse is pre-configured to access a local SonarQube server listening on http://localhost:9000/. You can edit this server, delete it or add new ones.By default, user and password is "admin".If sonar service is started properly, test connection will give you successful result.
For getting a project analyzed on sonar, refer this http://docs.sonarqube.org/display/SONAR/Analyzing+Source+Code [link].
Linking a project to one analyzed on sonar server.
In the SonarQube project text field, start typing the name of the project and select it in the list box:
Click on Finish. Your project is now associated to one analyzed on your SonarQube server.
Changing Binding
At any time, it is possible to change the project association.
To do so, right-click on the project in the Project Explorer, and then SonarQube > Change Project Association.
Unbinding a Project
To do so, right-click on the project in the Project Explorer, and then SonarQube > Remove SonarQube Nature.
Advanced Configuration
Additional settings (such as markers for new issues) are available through Window > Preferences > SonarLint
To look for SonarQube analyzed issue, go to Window→Show View→ Others→SonarLint→SonarLint Issues. Now you can see issues in soanrqube issues tab as shown
Or you can go to link http://localhost:9000 and login with admin as id and admin as password and goto Dashboard.you can see all the statistics of analysis of the configured projects on sonar server.
This documentation is licensed under the Creative Commons License (Attribution-NoDerivatives 4.0 International).
