Tunning your Checkstyle and Formatter

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 previous post, we installed Checkstyle and tested it a bit, a little proof-of-concept, useful for your little project at home, it doesn't cares anybody, and the world could survive without it perfectly.

Now focus on your company, it is unforgivable that every mate format their code as Sant Peter tells them. You implanted CheckStyle code in your I.T. dept. and it looks like better, but Sun style (default one for Formatter and CheckStyle) doesn't fit your interests.

One example. Your monitor is 1280 pixels wide, but Formatter defaults to 80 columns of text, and you find it miserable for your hardware, that supports much more, at least 120 columns.

Let's build this example, a comment of 143 columns length.

As soon as you invoke Formatter (Ctrl+Shift+F or Menu Source->Format), the result is next:

The comment line was broken at column 79, but I spent a large amount of money in a extreme-wide monitor and I find that length ridiculous. I better change this parameter.

Check your configuration in  Window menu -> Preferences -> Java -> Code Style -> Formatter. The best you can do in this point is create your own profile, based on an existent one. 

I chose New ... and type anavarro_prof, based on "Java Convention [built-in]"

Then, edit your new profile, as a sample, we will change line width...

 and comment width...

Once both parameters are changed, let's suppose your project is using the IDE default formatter, so, your formatter, that have been chosen as default one after its creation.

Return to your code, re-format it! it works! it has been formatted to 120 lines width.

Did it work? not completely... see that magnifying glass that appeared at the left side of your comment...

Line is longer than 80 characters?. What's up?
This is happening because your Formatter is not directly connected with your CheckStyle plugin, so you will have to transmit your Formatter changes into your CheckStyle configuration.


Open Window Menu -> Preferences -> CheckStyle. 

You should find the two built-in configurations, but you want to configure your own. 

So firstly select one of them, click "Copy" to create a configuration based on an already created one.

And change some parameters, as the type, make it external, change that ugly name and select a location where the new configuration will be created. I lend you an example:

Then, clicking "OK", your new configuration will be created and you can both "Set as Default" and "Configure". Yes, please, "Configure" it.


Search for "Maximum Line Length", and EDIT existent "Maximum Line Length" in the window on the right. Beware don't add an additional property already existent, because you won't get the desired goal.

Then change its maximum length doubleclicking it:

Save, Ok, Rebuild, do whatever neccesary to get your code window again, magnifying glass should dessapear after recompiling. Mine does! You have also got an external CheckStyle configurer as a xml file where you asked to. This file will be transferred to your mates in next chapter.


Quite a long article, you should have learned to customize your Formatter and make your CheckStyle configuration being Formatter-compliant. You can now impose both configurations to your entire team, in the next article, promise.


Have a happy New Year's Eve!!!

Tunning your Maven project

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

Now let's suppose you want to build a new Maven project in SpringSource,

New Project -> Other -> Maven project.

You already know about the benefits of a Maven project and you want to roll your own like a library, without Spring dependencies.

As soon as you have created your project, you notice that your project doesn't have any resource folder as source folder. They doesn't exist in the folder hierarchy either. But you need those folder for Unit Testing (that is something that will be explained afterwards).


Round one, fight!

As a Eclipse user, the first you think is you may create those folders manually- Create a "resources" folder inside "main", and another "resources" inside "test", then register them as "source folders" in Properties -> Java Build Path -> Source -> Add Folder. By selecting the new folders you may access resource files throw classpath.

It's important to sort the order of folders in Order and Export tab, put your main/resources above your test/resources entry.

Now create three files, "a.xml" in "main/resources", a different copy of "a.xml" in "test/resources" and finally one "b.xml" in "test/resources".

Try it please. Then Run As -> Maven Install and you will get a jar file in your target project directory. Unzip your jar, you should find an "a.xml" with the content of "main/resources" and "b.xml".

What did it happened?

Maven will export every file in "source folders", compiled or not, that's the reason of the undesired existence of "b.xml". We shouldn't export our testing data!
If Maven finds two or more files with the same name, it is chosen by classpath priority, so it is important to tune it well in "Order and Export" tab.

Nevertheless, we don't find the result appropriate, because we don't want to export our testing data.

Take a look to your "Order and Export" tab, you can't uncheck your "Source folders" for exporting (the box at the right of the entry), so, this isn't a good solution.


Round two, fight!

Please delete both entries from "Source folders" in Properties -> Java Build Path.

Now go to "Libraries" tab in the same dialog. "Add class folder" and check your main and test "resource" folders.

Is it the same than before? no. Because now you can drift to your "Order and Export" tab and check your "main/resources" folder for exporting, and not the same for "test/resources" one.

Run As -> Maven Install. Unzip your Jar and see how magically you haven't exported your testing resources. :) Terrific.

DELETE your project, without deleting sources or resources. Only the project from your workspace. Reimport it like a "Existing Maven Project" and... Ops, you have lost all your classpath configuration. Yes, you can reimport like a Simple Project as well, but have now experienced what will happen when any of your workmates download your project from any cvs/svn/other repository.

Take a look to your ".classpath" file, there you have all your configuration. But this file won't be uploaded to the repository, and therefore, no mate will be able to export this library correctly.

You have draft this round too ;)


Round 3, fight!

By losing your second round, you must have noticed that you can't win this battle by using local classpath files. Indeed, you won't never export it to the repository, so the solution must be as exportable as functional.

Take a look to your "Java Build Path" again, 

Let's take a look to your pom.xml file. It's quite clean, isn't it? Let's take a look to the "Super POM.xml" from Maven.

See the build entry:

<build>
    <directory>target</directory>
    <outputDirectory>target/classes</outputDirectory>
    <finalName>${artifactId}-${version}</finalName>
    <testOutputDirectory>target/test-classes</testOutputDirectory>
    <sourceDirectory>src/main/java</sourceDirectory>
    <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
    <testSourceDirectory>src/test/java</testSourceDirectory>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
      </resource>
    </resources>
    <testResources>
      <testResource>
        <directory>src/test/resources</directory>
      </testResource>
    </testResources>
  </build>

Quite appealing, I will take it as is and drop it in my "pom.xml". Delete and reimport as Maven project.

That is what you will find:
.classpath independent, the information is in your "pom.xml" file.
Files under "testResource" member of "pom.xml" file won't be exported
Appropiate for sharing throw control version repositories, every mate will build the project correctly.


Epilogue

Now clean every fingerprint from this project, create a new one, create the same folders, the same files inside:

src/main/resources
a.xml

src/test/resources
a.xml (different)
b.xml

Delete the project, reimport it like a Maven one again... yes, Maven did it for you.

Those are the standard folders for a Maven project, and, by being standard, as far as you name your folder so, you won't have to configure they as testResource folders, and their content won't be ever exported.

You are 20% smarter than your mates, you woooon! :)


I will check my horrible English tomorrow. Enjoy this article as much as I enjoyed writing it.