OpenDaylight Developer Experience 2.0

Post on 16-Apr-2017

243 views 2 download

Transcript of OpenDaylight Developer Experience 2.0

Developer Experience 2.0September 27, 2006 @ ODL Summit SeattleMichael Vorburger.ch, Red Hat

This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

$ historyThe 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!

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

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 DIJoin my 3-4pm tomorrow!

This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

1. Eclipse Setupbased on the Oomph Eclipse Installer

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

2. What?

2,278,082 Downloads

What’s in it for you?

• git clone, import

• Working Set (dyn)

• MAGIC (m2e)

• 20+ Plugins

• 20+ Preferences

• YANG Editor

• Goodies

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.

Goodies

• EGit

• EGerrit

• Docker & Vagrant; Terminal

• FindBugs, PMD, EclEmma, YEdit, InfiniTest, AnyEdit, ...

EGit

Gerritby EGit

• Push to Gerrit

• Fetch from Gerrit

EGerrit

3. How?

2. Code Quality, in IDEBug prevention (incl. security); uniformity lowers friction

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”...

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.)

Why Checkstyle/FindBugs/Sonar?A.Formatting Conventions

1.Shared Code

needs

2. Common Style

B. Find real bugs!

FindBugs’ UC_USELESS_OBJECTe.g. ovsdb c/42345.

Checkstyle’s System.out (e.g. netvirt c/43973), and Exception handling.

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.

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.

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

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)

3. Local Build, DeployBug prevention (incl. security); uniformity lowers friction

-Pq Quick Build

1. mvn [-o] clean install

7:41 min

2. mvn [-o] -Pq install

1:16 minTimings from ovsdb, as an example.

-Pqmvn -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/

Deploy changed bundles to Karafmvn -o -Pq \ -DaddInstallRepositoryPath=$KARAF/system install [Eclipse: Shift-Alt-X-M]

dev:restarthttps://git.opendaylight.org/gerrit/#/c/40520/

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

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??

4. Testingand Dependency Injection (DI)

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

Highly readable! Very Important for tests as literal API documentation.

Runs FAST & easy to debug!

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

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)

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.

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/

Dependency Injection (DI) in ODLODL CSS Config => OSGi Blueprint XML (BP) => BP @Inject AnnotationsLess 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...

class AclServiceModule extends GuiceModule {

@Override protected void configureBindings() {

① bind(AclServiceManager.class) .to(AclServiceManagerImpl.class);

② bind(AclInterfaceStateListener.class);

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);

BACKUP SLIDESNot used in the 30’ presentation (too much)

This OpenDaylight SDK presentation is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

$ whoamiMichael Vorburger.ch@vorburger

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?

1.Why?

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 (...)”

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

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:

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