Maven Essentials: standard folders.

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

Directly from Maven documentation entry, short and concise.

Introduction to the Standard Directory Layout

Having a common directory layout would allow for users familiar with one Maven project to immediately feel at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.

The next section documents the directory layout expected by Maven and the directory layout created by Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can be overridden via the project descriptor.

src/main/java Application/Library sources

src/main/resources Application/Library resources

src/main/filters Resource filter files

src/main/assembly Assembly descriptors

src/main/config Configuration files

src/main/webapp Web application sources

src/test/java Test sources

src/test/resources Test resources

src/test/filters Test resource filter files

src/site Site

LICENSE.txt Project's license

NOTICE.txt Notices and attributions required by libraries that the project depends on

README.txt Project's readme

At the top level files descriptive of the project: a pom.xml file (and any properties, maven.xml or build.xml if using Ant). In addition, there are textual documents meant for the user to be able to read immediately on receiving the source: README.txt, LICENSE.txt, etc.

There are just two subdirectories of this structure: src and target. The only other directories that would be expected here are metadata like CVS or .svn, and any subprojects in a multiproject build (each of which would be laid out as above).

The target directory is used to house all output of the build.

The src directory contains all of the source material for building the project, its site and so on. It contains a subdirectory for each type: main for the main build artifact, test for the unit test code and resources, site and so on.

Within artifact producing source directories (ie. main and test), there is one directory for the language java (under which the normal package hierarchy exists), and one for resources (the structure which is copied to the target classpath given the default resource definition).

If there are other contributing sources to the artifact build, they would be under other subdirectories: for example src/main/antlr would contain Antlr grammar definition files.

Essential readings: Pragmatic Programmer

Pragmatic Programmer
by Andrew Hunt and David Thoma. 1999.


(33$ kindle edition, 29$ paperback edition in Amazon.
Incredible, <españolada>we are all crazy</españolada>).

When I came to Barcelona in 1997, this was the first task in my first serious job. I was asked to read this book in order to understand the basis of their job, and I found it quite illuminating. I want to spread this good practice :)

In my humble point of view, this is a great compilation of good practices about programming, and simply being, as you may read below:

[From the book]
While software development is immune from almost all physical laws, entropy hits us hard. Entropy is a term from physics that refers to the amount of ``disorder’’ in a system. Unfortunately, the laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum. When disorder increases in software, programmers call it ``software rot.’‘
There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing. Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well.
What makes the difference?
In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .
A broken window.
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
The ``Broken Window Theory’’ has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.

Don’t Live with Broken Windows

Don’t leave ``broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.
We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood. Don’t let entropy win.

From: http://pragprog.com

Essential tools: SpringSource

What is SpringSource?

As far as I know, that is the most comfortable open-source tool for developing Spring. It is Eclipse based, so you will be able to complete your favourite IDE with other plugins like Subclipse (SVN), CheckStyle or Covertura.

SpringSource comes with Spring project templates, Maven and JUnit, so, if you want Q, it does their best for you to get it ;)

Its goals:

• J2EE should be easier to use
• It is best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.
• JavaBeans offer a great way of configuring applications.
• OO design is more important than any implementation technology, such as J2EE.
• Checked exceptions are overused in Java. A platform shouldn't force you to catch exceptions you're unlikely to be able to recover from.
• Testability is essential, and a platform such as Spring should help make your code easier to test.

Yes, they accomplish their goals, so it will be my dev tool for coming reviews, examples and articles.

Download it!
springsource.org