Implementing Quality on Java projects

Implementing Quality
on Java projects

Vincent Massol
Committer XWiki
XWiki SAS

@vmassol
27 au 29 mars 2013
Sunday, March 31, 13

Vincent Massol

• Speaker Bio
• CTO XWiki SAS
• Your Projects
• XWiki (community-driven open source project)
• Past: Maven, Apache Cargo, Apache Cactus, Pattern Testing
• Other Credentials:
• LesCastCodeurs podcast
• Creator of OSSGTP open source group in Paris
• 3 books: JUnit in Action, Maven: A Developer’s Notebook, BBWM


What is Quality?


The XWiki project in summary
• 9 years old
• 28 active
committers
• 7 committers
do 80% of
work
• 700K NCLOC
• 11 commits/
day
• 16 mails/day


Examples of Quality actions
• Coding rules (Checkstyle, ...) • Ensure API stability
• Test coverage • Code reviews
• Track bugs • License header checks
• Don’t use Commons Lang 2.x • Release with Java 6
• Use SLF4J and don’t draw Log4J/ • Ensure javadoc exist
JCL in dependencies
• Prevent JAR hell
• Automated build
• Release often (every 2 weeks)
• Automated unit tests
• Collaborative design
• Stable automated
• Test on supported
functional tests environments (DB & Browsers)

Quality Tip #1

API Stability

27 au 29 mars 2013

The Problem

Class Not Found or Method Not
Found


API Stability - Deprecations

/**
* ...
* @deprecated since 2.4M1 use {@link #transform(
* Block, TransformationContext)}
*/
@Deprecated
void transform(XDOM dom, Syntax syntax)
throws TransformationException;


API Stability - CLIRR (1/2)
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>clirr-maven-plugin</artifactId>
<configuration>
<ignored>
<difference>
<differenceType>7006</differenceType>
<className>org/xwiki/.../MetaDataBlock</className>
<method>org.xwiki....block.Block clone()</method>
<to>org.xwiki.rendering.block.MetaDataBlock</to>
<justification>XDOM#clone() doesn't clone the meta
data</justification>
</difference>
...


API Stability - CLIRR (2/2)

Example from XWiki 5.0M1 Release notes


API Stability - Internal Package
Javadoc
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-javadoc-plugin
<configuration>
<excludePackageNames>*.internal.*
</excludePackageNames>

CLIRR
<plugin>
<artifactId>clirr-maven-plugin</artifactId>
<excludes>
<exclude>**/internal/**</exclude>
<exclude>**/test/**</exclude>


API Stability - Legacy Module
Aspect Weaving

<plugin>
<artifactId>aspectj-maven-plugin</...>
...
<configuration>
<weaveDependencies>
<weaveDependency>
<groupId>org.xwiki.rendering</...>
<artifactId>xwiki-rendering-api</...>
...

+ “Legacy” Proﬁle


API Stability - Young APIs

/**
* ...
* @since 5.0M1
*/
@Unstable(<optional explanation>)
public EntityReference createEntityReference(String name,...)
{
...
}

+ max duration for keeping the annotation!


API Stability - Next steps

• Annotation or package for SPI?
• Better deﬁne when to use the @Unstable annotation
• Not possible to add a new method to an existing Interface
• Java 8 and Virtual Extension/Defender methods
interface TestInterface {
  public void testMe();
  public void newMethod() default {
    System.out.println("Default from interface");
  }
}


Quality Tip #2

JAR Hell

27 au 29 mars 2013

The Problem

Class Not Found or Method Not
Found or not working feature


No duplicate classes @ runtime
<plugin>
<groupId>com.ning.maven.plugins</groupId>
<artifactId>maven-duplicate-finder-plugin</artifactId>
<executions>
<execution>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
<configuration>
<failBuildInCaseOfConflict>true</...>
<exceptions>
...


Surprising results...
• Commons Beanutils bundles some classes from Commons
Collections, apparently to avoid drawing a dependency to it...
• Xalan bundles a lot of other projects (org/apache/xml/**, org/apache/
bcel/**, JLex/**, java_cup/**, org/apache/regexp/**). In addition, it even
has these jars in its source tree without any indication about their
versions...
• stax-api, geronimo-stax-api_1.0_spec and xml-apis all draw
javax.xml.stream.* classes
• xmlbeans and xml-apis draw incompatible versions of org.w3c.dom.*
classes
14 exceptions in total!

Maven: dependency version issue
<dependencies>
<dependency> Will run logback 0.9.9
<groupId>org.slf4j</groupId> with slf4J-api 1.4.0
<artifactId>slf4j-api</artifactId> instead of 1.5.0!
<version>1.4.0</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.9</version>

</dependency>
</dependencies>

Maven: ensure correct version
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-version-compatibility</id>
<phase>verify</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireUpperBoundDeps/>
</rules>


Quality Tip #3

Test Coverage

27 au 29 mars 2013

The Problem

More bugs reported, overall quality
goes down and harder to debug
software


Use Jacoco to fail the build
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<executions>
<execution><id>jacoco-prepare</id>
<goals><goal>prepare-agent</goal></goals>
</execution>
<execution><id>jacoco-check</id>
<goals><goal>check</goal></goals>
</execution>
</executions>
<configuration>
<check>
<instructionRatio>${xwiki.jacoco.instructionRatio}</...>
</check>}


Strategy

• When devs add code (and thus tests),
increase the TPC percentage
• Put the Jacoco check in “Quality” Maven
Proﬁle
• Have a CI job to execute that proﬁle
regularly
• About 15% overhead compared to build
without checks
• “Cheat mode”: Add easier-to-write test

Quizz Time!
Step 1: Building on my local machine gives the following:

[INFO] --- jacoco-maven-plugin:0.6.2.201302030002:check (jacoco-check)
[INFO] All coverage checks have been met.

Step 2: Building on the CI machine gave:

[INFO] --- jacoco-maven-plugin:0.6.2.201302030002:check (jacoco-check)
[WARNING] Insufficient code coverage for INSTRUCTION: 75.52% < 75.53%

Non determinism! Why?

Quizz Answer
... because the JVM is non deterministic!
private Map componentEntries = new ConcurrentHashMap();
...
for (Map.Entry entry : componentEntries.entrySet())
{
if (entry.getValue().instance == component) {
key = entry.getKey();
oldDescriptor = entry.getValue().descriptor;
break;
}
}


Quality Tip #4

Functional Testing Stability
(with Jenkins)

27 au 29 mars 2013

The Problem

Too many false positives leading to
developers not paying attention to CI
emails anymore... leading to failing
software


False positives examples

• The JVM has crashed
• VNC is down (we run Selenium tests)
• Browser crash (we run Selenium tests)
• Git connection issue
• Machine slowness (if XWiki cannot start under 2 minutes then it
means the machine has some problems)
• Nexus is down (we deploy our artifacts to a Nexus repository)
• Connection issue (Read time out)


Step 1: Groovy PostBuild Plugin (1/2)
def messages = [
[".*A fatal error has been detected by the Java Runtime Environment.*",
"JVM Crash", "A JVM crash happened!"],
[".*Error: cannot open display: :1.0.*",
"VNC not running", "VNC connection issue!"],
...
]
def shouldSendEmail = true
messages.each { message ->
if (manager.logContains(message.get(0))) {
manager.addWarningBadge(message.get(1))
manager.createSummary("warning.gif").appendText(...)
manager.buildUnstable()
shouldSendEmail = false
}
}


Step 1: Groovy PostBuild Plugin (2/2)

... continued from previous slide...

if (!shouldSendEmail) {
def pa = new ParametersAction([
new BooleanParameterValue("noEmail", true)
])
manager.build.addAction(pa)
}


Step 2: Mail Ext Plugin

Pre-send Script
import hudson.model.*

build.actions.each { action ->
if (action instanceof ParametersAction) {
if (action.getParameter("noEmail")) {
cancel = true
}
}
}


Results

+ use the Scriptler plugin to automate conﬁguration for all jobs

Quality Tip #5

Bug Fixing Day

27 au 29 mars 2013

The Problem

Bugs increasing, even simple to ﬁx
ones, devs focusing too much on new
features (i.e. scope creep) vs ﬁxing Bugs created vs closed
what exists


Bug Fixing Day

• Every Thursday
• Goal is to close the max number of bugs
• Triaging: Can be closed with Won’t ﬁx, Duplicate,
Cannot Reproduce, etc
• Close low hanging fruits in priority
• Started with last 365 days then with last 547 days
and currently with last 730 days (we need to catch
up with 40 bugs!)


Results


Conclusion

27 au 29 mars 2013

Parting words

• Slowly add new quality check over time
• Everyone must be on board
• Favor Active Quality (i.e. make the build fail) over Passive checks
• Be ready to adapt/remove checks if found not useful enough
• Quality brings some risks:
• Potentially less committers for your project (especially open source)
• Project seen as “less fun”


Be proud of your Quality!

“I have offended God and
mankind because my work didn't
reach the quality it should have.”

Leonardo da Vinci, on his death bed


Implementing Quality on Java projects

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Implementing Quality on Java projects (20)

More from Vincent Massol (20)

Recently uploaded (20)

Implementing Quality on Java projects