Development Environment Tips and Tricks
- Eclipse launch configurations
- Installing additional IDE plugins
- Project builds fail in IDE
- Running unit tests
- Running tests with code coverage
- Running integration tests in Eclipse IDE
- Disappearing test sources directories
- Git hints
Shared launch configurations tend to multiply with each project that uses them.
To get rid of the duplicates, set the Common->Save as value to Local file instead of Shared file.
So, replace
with
Several plugins don't come pre-installed in the standard Eclipse J2EE distribution and are helpful during various stages in the project lifecycle. They are enumerated below along with their project purpose and installation procedure.
This one is already installed in the newer distributions, but since Maven integration is rather important, it deserves its place here.
m2e Tycho Project Configurator is a plugin in this family that may simplify the work with OSGi dependencies.
The plugin simplifies the connection to the target OSGi framework running on a Kura device. Its most useful features are review of the deployed bundles and ability to deploy new bundles containing Kura plugins.
The instructions for setup are well-described here: http://eclipse.github.io/kura/doc/kura-setup.html.
How to use it? Open Frameworks view, open context menu and select Connect Framework, fill in the details and that's it. Now you can deploy your own bundles and deployment packages using the View's toolbar.
The Plug-in Development Environment (PDE) provides tools to create, develop, test, debug, build and deploy Eclipse plug-ins, fragments, features, update sites and RCP products. PDE also provides comprehensive OSGi tooling, which makes it an ideal environment for component programming, not just Eclipse plug-in development.
To install, simply search for it in the "Eclipse Marketplace" under the "Help" menu in the IDE.
Kura's Maven build uses SonarLint to perform static code analysis. It is also available as an Eclipse IDE plugin. Once installed it will perform analysis on all non-test classes in the workspace and show the results in overview and/or SonarLint Issues view. To analyse test classes, the plugin configuration must be updated not to exclude Test. files.
Installation is available on Eclipse marketplace: https://marketplace.eclipse.org/content/sonarlint.
JaCoCo is used to provide code coverage of tests. Eclipse plugin that uses JaCoCo is EclEmma. The plugin offers some configuration, but default settings are usually good enough.
It, too, is available on Eclipse marketplace: https://marketplace.eclipse.org/content/eclemma-java-code-coverage.
There are many reasons why a build should fail. A few possibilities (assuming code compiles) are:
- Target platform doesn't contain all the necessary dependencies
- Project configuration is out of sync with Maven configuration
If project's Plug-in Dependencies library is empty or doesn't contain the necessary dependencies, one of the first checks to do is to verify that the target platform contains all the needed dependencies. It is usually necessary to set target platform at Eclipse IDE start. Go to target-definition project, open the kura*.target file and click on the Set as Target Platform link.
Having done that and build still fails, verify that META-INF/MANIFEST.MF's Import-Package directive contains all necessary packages.
If project configuration is out of sync with Maven's configuration, this will be indicated in the Problems view. Maven->Update Project is the usual solution with a side effect - src/test/* will be removed as source paths. Just add them back and that's it. A partially-working solution for this side effect is to add src/test/* to source.. key in build.properties file, but that complicates matters with console builds (tests), so it's not that useful. See Disappearing test sources directories for details.
- Make sure that src/test/java is added as a source folder
- Make src/test/java's output directory target/test-classes instead of the default target/classes
- Run the test class (or package with multiple test classes) as a JUnit test
- Make sure that the tests in src/test/java will compile - add maven-compiler-plugin:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<executions>
<execution>
<id>compiletests</id>
<phase>test-compile</phase>
<goals>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>
- Make sure that maven will run the tests - add maven-surefire-plugin:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7.2</version>
<executions>
<execution>
<id>default-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<argLine>${jacocoArgs}</argLine>
</configuration>
</execution>
</executions>
<configuration></configuration>
</plugin>
If you installed EclEmma, you are halfway there already. Default configuration is quite good enough, so leave it as is.
How do you run the coverage? Take your existing launcher and run Coverage as... instead of Run or Debug. You have the possibility to add or remove certain source directories from scope, otherwise just run it.
The tests will execute and after a few seconds the sources will be colored based on whether the line has been visited or not. Coverage view will supply some more details.
Having trouble getting rid of the coverage colors in editors? Just remove the coverage session(s) in Coverage view.
Running code coverage tests in console (with Maven) is just a bit more tricky. There are a few settings you must be careful to set:
- in your main pom.xml you will want to set the name of the variable with jacoco's run arguments (in this case, jacocoArgs):
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco.version}</version>
<executions>
<execution>
<phase>process-test-classes</phase>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<propertyName>jacocoArgs</propertyName>
</configuration>
</execution>
</executions>
</plugin>
- in your surefire plugin you will want to use this variable:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>${version...}</version>
<executions>
<execution>
<id>default-test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<argLine>${jacocoArgs}</argLine>
</configuration>
</execution>
</executions>
<configuration></configuration>
</plugin>
or, using tycho-surefire plugin
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${version...}</version>
<configuration>
<argLine>${jacocoArgs}
...
If multiple separate tests are run (even mixed surefire and tycho-surefire runs), the results are concatenated and all of them will be taken into account.
Run the test as a JUnit Plug-in test.
Test tab settings: You will probably want to run a single test case/class in this way. Make sure to select the right one and that the test runner is JUnit 4.
Main tab settings: Just make sure to Run an application in Headless Mode.
The arguments are where it becomes interesting. Kura services won't run properly unless configured at least a bit. Therefore the following line can be used:
-Dorg.osgi.service.http.port=8080 -Dkura.configuration=file:///${workspace_loc:org.eclipse.kura.emulator}/src/main/resources/kura.properties -Ddpa.configuration=/tmp/kura/dpa.properties
The variable that is originally used for pointing to configuration file, ${git_work_tree}, is not really safe as EGit plugin on e.g. Windows refuses to work with this variable and tests cannot be run. The safer option is to point straight to the project in the workspace.
The next thing to set are the plugins that will be deployed and started. For tests where services will be mocked not all should be selected. What to select, then? Your test bundle fragment, definitely, and some you are sure to need. Then press Add Required Plug-ins to add the dependencies. Add additional plugins in this manner until you end up with about 50-90 selected. Set Default Auto-Start to true.
In the Common tab leave Save as set to Local file.
Run and if you see lots of output without exceptions, you likely made it work.
Maven->Update Project causes src/test/* directories to be removed as source paths. Just add them back and that's it.
If you don't mind these tests only be run in integration phase (actually, integration-test) by tycho-surefire-plugin - instead of surefire-plugin - and deployed in OSGi environment, you can add src/test/java (and src/test/resources) to source.<library> (e.g. source..) key in build.properties file. Besides these 2 side effects, there is also duplicated configuration of project classpath and test sources are no longer really considered test sources, but regular sources. Output path cannot be specified here and still be used by Tycho.
-
Checkout creating a new branch from another:
git checkout -b <new branch> <existing branch> -
Sync branch with upstream/develop branch:
Only run the first time: git remote add upstream https://github.com/eclipse/kura.git
Every time:
git fetch upstream
git rebase upstream/develop
git push [-f]
- Squash your commits, whether committed or not:
Make sure that branch is not rebased with others' commits and run
git rebase -i HEAD~<number of commits>
pick the first commit and squash all the rest. Aggregate the commit message. Push.
git push -f
- Delete merged branches
Local:
git branch -d <branch name>
You may delete remote branches on GitHub or using
git push origin --delete <branch>