The document is a presentation on improving developer experience with the OpenDaylight SDK, covering topics such as Eclipse setup, code quality, local build and deployment, and testing methodologies. It emphasizes the importance of in-IDE tools for maintaining code quality and encourages community contributions for ongoing improvements. The presenter shares insights on using dependency injection, coding standards, and best practices in software development within the OpenDaylight environment.

1. Developer Experience 2.0
September 27, 2006 @ ODL Summit Seattle
Michael Vorburger.ch, Red Hat

2. This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
$ history
The first half of this presentation is a summary of the
“OpenDaylight has Oomph!” presentation from the Mini European
Summit on June 21st 2016 in Berlin (talk video, slides, demo, src),
repeated on a TWS WebEx on July 18th.
The second half is new content based on work since then.
#helpwanted = YOUR contributions most welcome!

3. Not quite a 5’ Ignite talk (20 @ 15s)
… but close - cram in double slides in ½ the time! ;)

4. 1.Eclipse Setup (10’) Why? What?
How?
2.Code Quality (5’) Checkstyle etc.
3.Dev Build/Deploy (5’) HOT?
4.End2End Tests (5’) Incl. @Inject DI
Join my 3-4pm tomorrow!
This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

5. 1. Eclipse Setup
based on the Oomph Eclipse Installer

7. And you just wanted to contribute
your very first open source bug fix
today, not get a black belt in IDE-
ology!

8. 2.What?
2,278,082 Downloads

11. +10’
1000+
views!

14. What’s in it for you?
• git clone, import
• Working Set (dyn)
• MAGIC (m2e)
• 20+ Plugins
• 20+ Preferences
• YANG Editor
• Goodies

16. Eclipse Tips
• Don’t disable Auto Build
• No separate workspaces
• Red? Alt-F5 (mvn), not clean
• Close Projects / Working Sets
Raise questions on dev list
with prefix "[eclipse]", or ping
me IRC/email me, if needed.

17. Goodies
• EGit
• EGerrit
• Docker & Vagrant; Terminal
• FindBugs, PMD, EclEmma, YEdit, InfiniTest, AnyEdit, ...

18. EGit

19. Gerrit
by EGit
• Push to Gerrit
• Fetch from Gerrit

20. EGerrit

23. 3.How?

26. 2. Code Quality, in IDE
Bug prevention (incl. security);
uniformity lowers friction

27. What do these have in common?
“Please change import statements to be alphabetically ordered”
“Move comment to previous line, as this will trigger a Sonar warning”
“java.util.Optional preferred over com.google.common.base.Optional”
“Field logger should be called LOG”
...

28. What do these have in common?
“Please change import statements to be alphabetically ordered”
“Move comment to previous line, as this will trigger a Sonar warning”
“java.util.Optional preferred over com.google.common.base.Optional”
“Field logger should be called LOG”
...
These kind of code review comments on changes
proposed via Gerrit are all a waste of not just 1 but of
2 people’s productive time!
Developer should have already been informed about
anything like this right there while typing it! (Same
principle for post merge Sonar.)

29. Why Checkstyle/FindBugs/Sonar?
A.Formatting Conventions
1.Shared Code
needs
2. Common Style
B. Find real bugs!
FindBugs’
UC_USELESS_OBJECT
e.g. ovsdb c/42345.
Checkstyle’s System.out (e.g.
netvirt c/43973), and
Exception handling.

30. Code Quality must be in-IDE
• Eclipse Plugins for Checkstyle autom. installed!
• Even more importantly, autom. m2e pre-configured!!
• Sonar same (Eclipse plugin, config; manually activate)
• My efforts to drive reasonable sensible common
shared set of rules in odl-parent for all of ODL.

32. Format & Import (Ctrl-Shift-F & O)
Wrong lexicographical order for '...' import. Should be before '...' ?
Just Source > Organize Imports, it works “as expected”, because it’s
correctly configured to “do the right thing” for ODL Checkstyle.
Source > Format is aligned as well.

33. How-to move existing code to Checkstyle enforcement? Gradually:
1.Bundle by bundle, never entire ODL project (git repo) in one go!
2.Clean all violations and violationSeverity=error (in same change)
3.If a lot of violations, then several Gerrits: split pure cosmetic
(formatting) from impactful (e.g. exception handling changes)
#helpwanted - your projects?
Above based on Gerrit change review experiences in mdsal with Dimension Data’s Brinda Jana, and some work in netvirt by me.
#helpwanted from more projects
Checkstyle - YOUR Plan

35. ODL Checkstyle++
#helpwanted
@see https://wiki.opendaylight.org/view/EvolvingCheckstyle, and:
1. Contribute controller slf4j logger checks to sevntu-checkstyle! (Contact me)
2. AvoidHidingCauseExceptionCheck & EitherLogOrThrowCheck (c/43331)
3. Upgrade Checkstyle version (incl. Eclipse plugin in eclipse-setup)
4. HiddenField, HideUtilityClassConstructor, InnerAssignment (c/41305)
5. FinalClass, HideUtilityClassConstructor (c/43324)
6. ThrowsCount (c/43329), TrailingComment (c/41084),
7. VisibilityModifier (c/43330)

36. 3. Local Build, Deploy
Bug prevention (incl. security);
uniformity lowers friction

38. -Pq Quick Build
1. mvn [-o] clean install
7:41 min
2. mvn [-o] -Pq install
1:16 min
Timings from ovsdb, as an example.

39. -Pq
mvn -Pq install skips:
• Tests compilation
• Unit tests running
• Karaf features testing
• Integration tests running
• Coverage instrumentation
(Jacoco)
• FindBugs analysis
• Checkstyle analysis
• JavaDoc generation
• Source JAR building
• Maven site building
• Invoker, Enforcer
https://git.opendaylight.org/gerrit/#/c/40245/

40. Deploy changed bundles to Karaf
mvn -o -Pq
-DaddInstallRepositoryPath=$KARAF/system
install [Eclipse: Shift-Alt-X-M]
dev:restart
https://git.opendaylight.org/gerrit/#/c/40520/

41. HOT Deploy changed bundles to Karaf
bundle:watch *
Fixed ODL CSS Config handleChangedClass() Code Gen.[Bug 2855, c/40514/, c/40950] …
... but in bundles migrated to OSGi Blueprint this is broken again :-(
#helpwanted, e.g. Aries BP upgrade and/or debug ClassCastException

42. BUT...
How often do you need to (hot) re-deploy the ODL code
you’re working on, into a full networking environment?
Q: Are you live debugging a sneaky corner case, or
developing? (New feature or functional extensions or
technical refactoring of existing features.)
Are you practicing Test Driven Development (TDD) ?
Test-first, really??

43. 4. Testing
and Dependency Injection (DI)

44. Kinds of Tests in ODL
#helpwanted
• J/Unit: Internal classes,
Mockito’ing dependencies
(standalone Java)
• Integration: ODL Features,
(Java OSGi Pax Exam)
• CSIT: ODL User Features,
black box, networking
system test (Robot suites)
• End-to-end (e2e) “API” Test
• Cover functionality of 1 bundle
• API, not int. implementation
• Stub required ext. Services
• Assert outcome on system
• Wire BP @Inject w. Guice
• netvirt.aclservice

45. Highly readable!
Very Important for
tests as literal API
documentation.
Runs FAST & easy to debug!

47. This JUnit ComparisonFailure
diff view is NOT Eclipse specific;
works in IntelliJ (et al) too. (But
not -currently- in CLI.)
https://github.com/vorburger/xtendbeans

48. Xtend IDE plugin also
available for IntelliJ

49. Anti Patterns for well testable code
• Don’t write static method in
anything but the most trivial
helper classes.
• Don’t use the public static
YourThing getInstance()
singleton pattern either.
• Do write small focused utility
classes (without any static)
• Do use Inversion of Control
(IoC) [Fowler]: wire objects
by injecting implementation
by DI (BP/Guice)

50. Anti Patterns for well written tests
• Use Mockito... sparingly.
(mock Optional?! c/45815)
• Tests that have more Mockito
set up lines than other code:
• Testing too many internals?
• Testing a class that’s too big?
• PowerMock? No… (At least
not for typical functional code.)
PowerMock’s “power”: Test
internals of badly designed
code. In ODL, better to just
refactor what you’re testing.

51. BTW: Google Truth
Use Google Truth assertThat() instead of JUnit assert* or Hamcrest’s
assertThat => more readable source, better IDE auto completion, and
clearer failure message:
assertThat(some.isInit).named("isInit").isTrue();
http://google.github.io/truth/

53. Dependency Injection (DI) in ODL
ODL CSS Config
=> OSGi Blueprint XML (BP)
=> BP @Inject Annotations
Less error prone than XML, AND
enables us to re-use std. @Inject
wiring metadata in e2e tests w.o.
BP but e.g. with Google Guice.
Manually wire few OSGi services.
Wiring duplication?
Possible to use e.g. Guice at
RT and not just Test, instead
of BP? And use opportunity
for on-demand instead Proxy
services?
https://github.com/vorburger/
osgi-services-di POC TBD...

54. class AclServiceModule extends GuiceModule {
@Override protected void configureBindings() {
① bind(AclServiceManager.class)
.to(AclServiceManagerImpl.class);
② bind(AclInterfaceStateListener.class);

55. class AclServiceTestModule …
…
① bind(DataBroker.class)
.toInstance(DataBrokerTestModule.dataBroker());
② bind(AclClusterUtil.class).toInstance(() -> true);
③ private AclserviceConfig aclServiceConfig() {
aclServiceConfig = mock(AclserviceConfig.class);
Mockito.when(
aclServiceConfig.getSecurityGroupMode())
.thenReturn(SecurityGroupMode.Stateful);

57. BACKUP SLIDES
Not used in the 30’ presentation (too much)

58. This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
$ whoami
Michael Vorburger.ch
@vorburger

59. What NeXT ?
• Bndtools? The OSGi IDE:
• Instant bundle JAR builder
• Semantic Versioning, in IDE...
• Launchers for lightweight in-
container FAST OSGi integration
testing (Karaf?)
• bnd.bnd ⇐ pom.xml (mvn?)
bnd-based; ODL already uses,
via maven-bundle-plugin.
• Writing e2e “API” Tests
• DI in OSGi with Guice?
• Join my 3-4pm tomorrow!
• #helpwanted
• Code Quality (post CS):
• FindBugs! #helpwanted
• Null analysis?

60. 1.Why?

61. 1.Why?Help - I still have Red X's! (i.e. Eclipse compile errors)
“Eclipse is no longer able to compile OpenDayLight. The reason is three
maven plugins which are used by OpenDayLight but are not integrated
into Eclipse: maven-plugin-plugin, karaf-maven-plugin and maven-
antrun-plugin. This means you will always have Eclipse compile errors in
the project (this could go to up to 100000 errors).
You can use Eclipse for editing easily but to compile the project you
need to open a terminal window and do the compilation (...)”

63. YANG IDE
• Builder
• Folding
• Validation
• Doc Hover
• Formatting
• Highlighting
https://github.com/xored/yang-ide/wiki/Features
• Code Completion
• Comment Toggle
• Navigation (F3)
• Templates
• Outline

69. Sonar
• Checkstyle VS Sonar? Checks have some overlap (inconsistencies)
• Sonar does not run for Gerrit check builds (could & should it?)
• Sonar in-IDE, same config as on sonar.opendaylight.com:

74. Contribute!
Eclipse Setup Models project is FLOSS.
Like everything else in OpenDaylight.
Now more easily than ever before:
You can contribute too!