Explicitly Managing Maven Dependencies

If we add a library in pom.xml, Maven would automatically include its dependencies. This is cool. But if two libraries depend on a same library, except use different version, problems may happen.

The best way is to declare the library version explicitly.

Here is an example:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
      xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">  
      <modelVersion>4.0.0</modelVersion>  
      <groupId>com.codeexample</groupId>  
      <artifactId>mvn-example-exclusion</artifactId>  
      <version>1.0-SNAPSHOT</version>  
      <packaging>jar</packaging>  
      <name>mvn-example-exclusion</name>  
      <properties>  
           <slf4j.version>1.6.1</slf4j.version>  
      </properties>  
      <dependencies>  
           <dependency>  
                <groupId>log4j</groupId>  
                <artifactId>log4j</artifactId>  
                <version>1.2.16</version>  
           </dependency>  
           <dependency>  
                <groupId>org.slf4j</groupId>  
                <artifactId>slf4j-log4j12</artifactId>  
                <version>${slf4j.version}</version>  
           </dependency>  
           <dependency>  
                <groupId>net.sf.dozer</groupId>  
                <artifactId>dozer</artifactId>  
                <version>5.3.2</version>  
           </dependency>  
      </dependencies>  
 </project>  

public class App {

    public static void main(String[] args) {

       org.slf4j.LoggerFactory.getLogger(App.class).debug("Hello slf4j");

    }

}

When run the previous code which just use slf4j logger to print a debug message, it would report the following error:

SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10]

This means we use incorrect version of slf4j-api library. But why and who imports the incorrect slf4j-api jar?

To find the culprit, I run “mvn eclipse:eclipse –X”.

[DEBUG] com.codeexample:mvn-example-exclusion:jar:1.0-SNAPSHOT (selected for null)

[DEBUG]   log4j:log4j:jar:1.2.16:compile (selected for compile)

[DEBUG]   net.sf.dozer:dozer:jar:5.3.2:compile (selected for compile)

[DEBUG]     commons-beanutils:commons-beanutils:jar:1.8.3:compile (selected for compile)

[DEBUG]       commons-logging:commons-logging:jar:1.1.1:compile (selected for compile)

[DEBUG]     commons-lang:commons-lang:jar:2.5:compile (selected for compile)

[DEBUG]     org.slf4j:slf4j-api:jar:1.5.10:compile (selected for compile)

[DEBUG]   org.slf4j:slf4j-log4j12:jar:1.6.1:compile (selected for compile)

[DEBUG]     org.slf4j:slf4j-api:jar:1.6.1:compile (removed - nearer found: 1.5.10)

From the output, we can see slf4j-log4j12-1.6.1 and net.sf.dozer-5.3.2 both depend on slf4j-api, but slf4j-log4j12-1.6.1 needs slf4j-api-1.6.1, net.sf.dozer-5.3.2 depends on slf4j-api-1.5.10.

For somewhat reason, - maybe net.sf.dozer-5.3.2 declares slf4j-api version explicitly-, maven uses slf4j-api-1.5.10.

To fix, we can explicitly declare the version of slf4j-api.

 <dependency>  
      <groupId>org.slf4j</groupId>  
      <artifactId>slf4j-api</artifactId>  
      <version>${slf4j.version}</version>  
 </dependency>  

Or we can exclude slf4j-api dependency from net.sf.dozer.

 <dependency>  
      <groupId>net.sf.dozer</groupId>  
      <artifactId>dozer</artifactId>  
      <version>5.3.2</version>  
      <exclusions>  
           <exclusion>  
                <groupId>org.slf4j</groupId>  
                <artifactId>slf4j-api</artifactId>  
           </exclusion>  
      </exclusions>  
 </dependency>  

I prefer the former solution, as it is clearer and simpler to understand.

How to Conduct Effective Code Reviews

Good Programming Practices –

How to Conduct Effective Code Reviews

Why Code reviews
For Code quality

l          Tend to improve the overall code structure and there by aid maintainability.

l          Promote refactoring which improves code re-use.

l          Improve the code to handle the corner cases.

l          Improve the test cases and there by improve test coverage.

l          Fix critical and rare defects - most of the multi-threading and concurrent access bugs tend to fall into this category.

For Team, Developers

l          Developers know their code will be evaluated, so they work harder.

l          It creates consistency and a culture of quality across the project.

l          Spread knowledge in team.

l          Improve team members’ skills.

l          Improve team morale.

Code Review Process
Preparation
Take advantage of static code analysis tools - such as Find Bugs, PMD, Google CodePro AnalytiX. It's responsibility of the developer who write the code or fix to take advantage of static code analysis tools to audit his/her code first to check and avoid common mistakes.
These tools will effectively save a lot of time/tedium for the team, so the team can focus on more interesting and challenging tasks.
Agenda & Scope
Before code review, one mediator should be response for collecting meeting agenda and scope and notifying other team members, including the code to be reviewed etc.
The mediator is not necessary to be the team leader; all team members can take turns to host the review meeting.

The scope should include the code being reviewed and it should address if there is any special emphasis - like performance, security etc.
Taking notes to team knowledge database- Lesson Learned and Action items
Code review is an intense activity. Lot of ideas are generated and discussed, new subtle/complicated bug may be discovered.
Code review is also a learning opportunity to improve team skills, to learn from the outcome, to learn from the mistakes we have made. These are valued asset for the team.

So the mediator should be response for taking notes to team knowledge database such team wiki, team blog etc. Anything that is useful and important to the team can be recorded, such as mistakes we made, ways we diagnoses the defect, alternative solution to the problem etc.
He should also be response for capturing important ones as action items and follow up.
Follow up

To gain adequate benefit of the code reviews, the team has to allocate sufficient time or resources to follow up the issues raised by the code review.
How to Conduct Effective Code Reviews
Make code reviews a learning opportunity.
Build the culture of knowledge sharing in your team
Spread knowledge and love.

l          The most important thing to conduct effective code review is to motivate team members to be engaged in code review actively.

l          Good team atmosphere, good relationship between colleagues is the key.

l          Let team members know the benefits of code review, for the team, for improving code quality, and especially for themselves.

Actually read the code.
A good code review always goes beyond the obvious
The coder should create a checklist of the things that the code reviews tend to focus on.
Check the document and comment.

l          If the code is complicated and doesn't explain itself, ensure it is well commented.

Make sure you have good coding standards to reference.
Matters needing attention
Remember to praise.
Ask questions rather than make statements.  
Make sure the discussion stays focused on the code and not the coder.
Remember that there is often more than one way to approach a solution.

What to talk about the code?
To let others know the code easily, we should not only explain the code itself, but also explain why we implement the code this way.

For bug fix, we should explain the root cause of the bug, and convince others the RCA.
If the bug is really hard and subtle, and we made great efforts to find it out, we may also cover how we diagnose it, and how we find out the RCA.

This is not related with code review, but is the way to spread and share knowledge in the team.
This is also a way to show you how hard you work on this defect.

But of course, how much we can talk about the code depends on review meeting schedule.

Resources:
Effective Code Reviews
Effective Code Reviews Without the Pain
Running an Effective Code Review
Tips for Doing Effective Code Reviews
How to Conduct Effective Code Reviews

Add 3rd Jars to Maven2 Build Path without Installing Them

Add 3rd Jars to Maven2 Build Path without Installing Them

Sometimes, we want to add a 3rd jar to our project, but it is not included in public maven repository, and we don't want to bother to create a local or intranet repository, and install the jar into it.

 

For example, we want to add javaparser to our application, it is a library to parse java source, and extract methods, fields, javadoc, and comments.

We can define its scope as system, and specify its path.

<dependency>

    <groupId>japa.parser</groupId>

    <artifactId>javaparser</artifactId>

    <version>1.0.8</version>

    <scope>system</scope>

    <systemPath>${basedir}/lib/javaparser-1.08.jar</systemPath>

</dependency>

Where ${basedir} is pointing to your project's root.

 

But this has some limitations, for example, when use maven assembly plugin to generate assemblies, jars under scope "system" are not included.

 

The solution is to put the dependency in a "file system repository" local to the project, then use install-file to install the jar to local default repository first (~/.m2/repository), then move the directory tree to ${basedir}/my-repo.

mvn install:install-file  -Dfile=%LIBPATH%\javaparser1.0.8.jar -DgroupId=japa.parser  -DartifactId=javaparser -Dversion=1.0.8 -Dpackaging=jar  -DgeneratePom=true 

I would declare that repository in my pom.xml like this:

<repositories>

  <repository>

    <id>my</id>

    <url>file://${basedir}/my-repo</url>

  </repository>

</repositories>

<dependency>

    <groupId>japa.parser</groupId>

    <artifactId>javaparser</artifactId>

    <version>1.0.8</version>

    <scope>compile</scope>

</dependency>

 

Resources:

Maven 2 assembly with dependencies: jar under scope “system” not included.

Can I add jars to maven 2 build classpath without installing them?

http://code.google.com/p/javaparser/

http://retrotranslator.sourceforge.net/