CheckStyle Eclipse plugin. Installation

Content:

CheckStyle Eclipse plugin. Installation

Tunning your CheckStyle and Formatter

Every programmer working as only one

What if... I get a "Fileset from project [projectname] has no valid check configuration" Error?

CheckStyle configuration distribution

In the lollipop world, your code and my code are completely equal, it is also well formatted, well documented and optimized for every executer machine. In that world, bugs does not exist, clients only do what they are supposed to do and the big boss never downplays your suggestions.

In a perfect world, your code and mine differs but not so much, your cat never walk over your keyboard and your pretty workmate is in love for you.

In this very real world, the stupid mate will not format a line correctly unless Damocles insert his sword in his back-door, clients bring up over your user manual and, probably, over the inexistent specification. Ups, I almost forget it, your ugly workmate is sexually harassing you.


In order to pacify this war field, the first tool I bring to you is CheckStyle Eclipse Plugin.


Description from its webpage: Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

The installation is quite easy, as said here, in your Eclipse/SpringSource just

1. In Eclipse go to Help->Software Updates...

2. Add a new installation site and providehttp://eclipse-cs.sf.net/update/ as location URL.

3. Mark the plugin version you would like to install, as well as future optional features, then press Install...

4. Review and confirm the plugins to install

5. Restart Eclipse



Afterwards, right click over your project -> CheckStyle -> Activate CheckStyle. Then you might find something like this:




You are able to see my best code ;) (I am sorry for Spanish description).

A bit summary of warnings in the code window:

-Javadoc is missing
-Missing package-info java file
-Comment is like to-do comment
- { should be in previous line
...
among others.


Firstly, with a Source -> Format (Ctrl + Shift + F) we will keep aesthetic warnings low.

I pass from 34 to 26 warnings, check how "{" have been moved and now they pass CheckStyle filter.

The Formatter and the Checkstyle Plugin must be synchronized, otherwise every formatting you do, and you should delegate format in tools like this, you will gain CheckStyle warnings in an endless war.

Benefits for a single programmers are limited, but benefits for a entire team that must work together are incalculable. If not this, tools like CheckStyle (and an automatic code formatter) are obligatory in every development department.


An article about Tunning CheckStyle in the oven...

Managing dependencies with Maven

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

How does Maven work?

Maven uses repositories for searching any dependency you declare in POM.xml, there are strictly only two types of repositories: local and remote.

The local repository (today's theme) refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released. (As said in Maven website).

When working with Eclipse, there are two levels for local repositories. Maven builds one repository over your workspace, therefore, if you have any dependency loaded as project in your workspace, it will be taken previous to any other equally-versioned jar.

The second level for local repositories is your personal space in disk. Maven automatically configures a repository inside your user directory (.m2 for Maven 2), and it is used for synchronizing all your projects, Eclipsoid or not.

In the higher step of this ladder, remote repositories. They could be a server in our own intranet, or one of the mirrors proposed by Maven for downloading its huge library.


Let's do a practice example:

Step one: Creation of secundary project.

Open an instance of SpringSource, configure it for working in the brand-new workspace "workspace_a". It doesn't matter the real path, it only matters that it is new and clean.

Create a "Maven Project",

We have reached the next window using only the "Windows Brain" (next.. next.. next..), until we are prompted for a "Group Id", "Artifact Id" and "Version".

Group Id: Sort of organizational name or hierarchy. It is a good idea that use your domain for all your packets, it could be at the same time your namespace and a good clue for where to locate more of your business.

Artifact Id: Name for this package.

Version: Initial version. SNAPSHOT tells Maven to look for more recent versions in their configured repositories. 

If an App.java was created, we wont need anymore for this part of the example.

Try to Run as.. Maven Install.

With this command, you are telling Maven to compile, run tests, and, if succeeded, deploy in local Maven repository to share with other projects.

Now close your SpringSource IDE if you can't afford having two IDEs opened.


Step two: Creation of main project.

Let's do it quickly and painless. As we did in other article, New Project -> Spring Template -> MVC Spring Project (or something similar, I'm not reading it right now :P). I call it "war", why not.

We won't run this new project, because we don't need to. What we only want is being able to compile the code.

Write an import sentence with wildcard like the example, and use one inexistent class like me. God kills kittens for less than this.

Run As -> Maven Install

10/12/10 23:07:14 CET: [ERROR] The import es cannot be resolved
10/12/10 23:07:14 CET: [ERROR] UtilsA cannot be resolved to a type
10/12/10 23:07:14 CET: Build errors for war; org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.2:compile (default) on project a: Compiler errors :
error at import es.anavarro.util.*;
       ^
/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:10:0::0 The import es cannot be resolved
error at UtilsA a;
^^^^
/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:20:0::0 UtilsA cannot be resolved to a type

Now type this in your pom.xml (inside <dependencies> tag, create it if it doesn't exist yet).

<dependency>
    <groupId>es.anavarro</groupId>
    <artifactId>util</artifactId>
    <version>0.0.1-SNAPSHOT</version>

</dependency>

Of course, adapt it to your step-one project. Rebuild the project, if everything went ok, Maven found the dependency and resolved the "import" error.

10/12/10 23:10:30 CET: Refreshing [/war/pom.xml]
10/12/10 23:10:30 CET: [INFO] snapshot es.anavarro:util:0.0.1-SNAPSHOT: checking for updates from org.springframework.maven.snapshot
10/12/10 23:10:44 CET: Maven Builder: AUTO_BUILD 

The other error is damn logical, that class doesn't exist in util project. Let's create it, one blank "UtilsA" class, in its workspace and project, then Run as -> Maven Install. A new version will be deployed in our local repository, with the same name and version, but (invisible to the user) with a newer timestamp.

Once your "util" project is done, return to the main project, rebuild it, Maven should download your last version, find your "UtilsA" and be able to compile it all. If it doesn't compile by Eclipse build, try Maven Install, it's the important one, and forces checking and download of dependences.

That is the base of Maven approach, easy to version projects and libraries, easy to collaborate, easy to use.


See you on @anavarro_prof