This makes you feel a little bit like for fifty+ years there have been many of us struggling with the same problems and several have succeeded in their quests and have documented their findings. Making a software bible out of the best titles doesn’t sound right. Just to propose choosing the “best titles” should unleash the Wrath of God. But we still need this one source where to concentrate knowledge and if there were someone to guide in the learning process… Dreamy.

These books you usually would read after you’re finished becoming an engineer. You know, after five years of preparing your brain to solve problems with Mathematics, Geometry and Physics, and, learning generalities on computing-related matters like networking, programming, IT auditing, etc, won’t get you too far on your first programming job when you discover you should not use JDBC but some JPA layer in the JEE architecture to make that query. Difficult.

Adding more years to school is not a solution. Actually everybody is trying to make it shorter and easier to become an engineer so more people want to be one, regardless of the sucky professionals they might spit out to the market. Plain irresponsible.

What if universities teach basics and generalities for three years and then you have to choose an specialization, let’s say on software development, so that you spend two years learning the many ways to point at and solve the right problem. This is not new, it’s what they do in Psychology. Mastering all about computers nowadays reaches far beyond the eyes can see and competitivity won’t forgive those who know a bit of everything. That’s knowing nothing.

Spending two years learning structural, object oriented, functional and more programming and how to test it will sure make a better programmer. Learn formal and agile methodologies to track your project growing will make you at least aware of the tools at your disposal. Learn TDD, BDD, specification by example and you will aim your effort to the right problem. Have a teacher assisting you in the learning process of something you chose to get good at and those two years will be a delightful journey.

What I mean is education on computing science at under degree level should rely on specialization during the last years.

To manage provided dependencies. The building of a project most of the time considers dependencies to libraries, toolkits, frameworks, etc., and for each of them you define a scope. You find some to be provided-scoped as your company’s login jar, the jee6-spec.jar library, etc. What’s to consider here is that these libraries are provided by the environment, so they don’t need to be in your deployment file. If you just drop them in your deploy or lib folders when you start the container, without your test file yet, you can make sure the can actually deploy by them selves. Then, if your test-deployment-file fails to deploy it’s less likely because of the provided dependencies.

To separate logs. Test-code logs too. So the least you should do is to drop a configuration file in your test resources to make sure the test log is separated from the production and server logs. A good place to relocate this file is to the target folder, maven speaking, or wherever you place your binaries. If you can make a log file per test class and save them into the test-reports folder, that’s heaven. This way, in the unlikely scenario your test fails, you won’t be searching the cause inside a 5 MB+ file which rolls every hour at best, but in a 1 KB ~ 1 MB test-only log file which is deleted next time you run your tests, build the project or just clean it up.

To isolate persistence. When data is involved you should always have a test-only schema or catalog, or whatever your DBMS calls it, where you can create and drop objects as you need. Once you grant this, you could tune up a little your test persistence.xml file to provide better data isolation. Ideally, a create-drop configuration for every test-case over a schema in the same DBMS where the development schema resides helps keeping a closer production-like isolated environment, but much time will be consumed to drop and create DB objects and purging might be needed. A quick fix is to move the test schema to a local light DBMS, like the JBoss AS embedded HSQLDB, which can be maintained as long as you don’t use DB-specific syntax. Another, is to configure the persistence to only update changes instead of dropping and recreating the schema every time; hibernate for this would be hibernate.hbm2ddl.auto = update. Using both fixes really cuts-off some time.

To package light. Adding a whole package to a testing deployment is not the best choice even when easier. Consider this integration tests as unit-integration tests; you want your component isolated but standing over the environment where it will perform in production. So, next time you are going to test the ClientSuscriber.java class use addClass(ClientSuscriber.class) instead of addPackages(ClientSuscriber.class.getPackage()) This will reduce the potential failure points to your test.

To default to off maven profiles When building with maven, it’s a good idea to turn off integration tests for regular building. An integration test besides testing components on the real environment also helps making sure you don’t break co-workers code and usually are developed and run after unit tests. So, setting them up in a non-active-by-default profile helps keeping them out of the way till they are needed because they cost time and running only a specific one reduces its efficiency. You may enforce the running of these tests by a CI system.

First approach was to define types together with class declaration.

public class Application <T extends Applicant> {}

This led to a very complex to design API because it kept extending the generic types as relationships appeared, which in time caused the API to be hard to understand because the attention on what it was trying to solve was caught by the types definition and declarations growing larger and larger as a second and a third type needed to be defined. Clear bad smell, so first refactoring took place. This first approach is depicted in package ec.pazmino.sandbox.generics.api.interfaces and its JPA entities implementation in ec.pazmino.sandbox.generics.api.jpa

To solve this I decided to declare generic types inline so interfaces would look cleaner.

public class Application {
(<T extends Applicant>) T applicant;
}

They did look cleaner. But the API got even harder to use and made me realize how much left I had to learn on generics. It’s a lot. These are packages ec.pazmino.sandbox.generics.api.interfaces.inline and ec.pazmino.sandbox.generics.api.interfaces.jpa.inline. So I started reading some more on generics and was about to start a new approach, which should lay an easier way to sub-classing by declaring types as self-referenced >.

But then I re-read the problem: a “covariant return which would allow the persistence layer implement the API and still be manageable and targeted by the entity manager.” All the magic remained calm in one word: “targeted”. This truth was revealed to me at 3:30 am. All I needed was telling the entity’s relationship what the specific target was implementing the defined contract. That’s it. The covariant return is given by the definition of the interface itself; anyway typing is going to be deleted after compilation. These are packages ec.pazmino.sandbox.generics.api.interfaces.clean and ec.pazmino.sandbox.generics.api.interfaces.jpa.clean

Such an easy thing became a mess because I was trying to solve it with the wrong tool. Covariant return is not necessarily solved with generics because a

covariant return type, means that the return type is allowed to vary in the same direction as the subclass.

Code repo https://github.com/iapazmino/generics-api

So, the build process is going to execute a PMD check and a Findbugs check. In order for these reports to be able to navigate through the code it’s necesary to enable this cross-reference with JXR. Later I will add CheckStyle when I can import the code conventions and formatting I’m already using with Eclipse IDE.

JXR is not executed during the build because browsing the code is something you would do from a report and not from a text file or the errors in the console, but you can enable this by executing it before the PMD and Findbugs goals are executed, maybe in the process-classes and process-test-classes phases when you know the code compiles and before it’s verified by the other plugins.

PMD will run a check in the verify phase of the build and make a report in the site phase of the reporting. The difference between these two is that check will fail the build if violations occur, and the report won’t. Checking in the verify phase gives you the chance to compile, test and package without worrying yet about your pending tasks on code quality. Findbugs will run in the verify phase as well. If you have your own rules-file for PMD you can add it inside a ruleset tag.

Finally, all three plugins are included in the reporting tag so the appear in the project’s site.

<profile>
<id>auditoria-codigo</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<!-- Referencia cruzada al codigo fuente -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>${plugin.jxr.version}</version>
<executions>
<execution>
<id>cross-reference-source</id>
<phase>pre-site</phase>
<goals>
<goal>jxr</goal>
<goal>test-jxr</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- PMD -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>${plugin.pmd.version}</version>
<configuration>
<targetJdk>${java.jdk.version}</targetJdk>
<rulesets>
<ruleset>
rules/path/file.xml
</ruleset>
</rulesets>
<includeTests>true</includeTests>
<verbose>true</verbose>
</configuration>
<executions>
<execution>
<id>check-pmd</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
<goal>cpd-check</goal>
</goals>
</execution>
<execution>
<id>report-pmd</id>
<phase>site</phase>
<goals>
<goal>pmd</goal>
<goal>cpd</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Findbugs -->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>${plugin.findbugs.version}</version>
<configuration>
<includeTests>true</includeTests>
<relaxed>true</relaxed>
</configuration>
<executions>
<execution>
<id>check-4bugs</id>
<phase>verify</phase>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jxr-plugin</artifactId>
<version>${plugin.jxr.version}</version>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-pmd-plugin</artifactId>
<version>${plugin.pmd.version}</version>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>${plugin.findbugs.version}</version>
</plugin>
</plugins>
</reporting>
</profile>

This configuration has a few lines so it’s probably a good idea to group them inside a profile which executes by default so we check coverage all the time. In order to check code coverage and report it, cobertura needs to instrument the code, test and generate reports. All this can be done with cobertura:cobertura goal. You might want to clean up everything before starting, so you get cobertura:clean goal too. The point is when to execute what, so you should checking at maven’s lifecycle reference for the site phase pre-site looked like a good place for clean up and site for checking coverage and reporting.

<profile>
<id>auditoria-codigo</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>${plugin.cobertura.version}</version>
<configuration>
<check>
<haltOnFailure>false</haltOnFailure>
</check>
</configuration>
<executions>
<execution>
<id>clean</id>
<phase>pre-site</phase>
<goals>
<goal>clean</goal>
</goals>
</execution>
<execution>
<id>check-coverage</id>
<phase>site</phase>
<goals>
<goal>cobertura</goal>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>${plugin.cobertura.version}</version>
</plugin>
</plugins>
</reporting>
</profile>

By default cobertura checks for a minimum coverage of 50% or fires an error. So, in order for this error to do not stop the site generation you need to set haltOnFailure to false.