One pom.xml, multiple jar, different resources per jar

Today I had one of those problems born mainly from stubordness: how to make two jars with different resources with only one maven run?

I wanted to take advantage of Servlet 3.0 and serve static resources - namely, ExtJS - from a jar, thus avoiding the need to copy the distribution of Ext JS on every application I wanted to use it. That was easy enough, but today I had one of those strange desires: I wanted the whole distribution - sources, resources, html documentation... everything - to be in another jar, just in case I wanted to include it in another application.

At first I thought it was going to be simple enough, after all, I had done similar things to web applications just with maven-war-plugin, so first I tried maven-jar-plugin, since I wanted a second jar.
Add another execution, with its own configuration - in particular, the resources/resource section - and that should do, right?
Well, wrong.

Then I tried the assembly plugin but didn't like the whole "build your own descriptor" thing.
Then I tried the resources plugin, but it still created one jar (with everything I added in the resources additional execution)

Finally, pulling the thread, I understood that the copy-resources I was doing was putting the documentation files in the classes directory that would get into the jar, hence the jar containing everything.
Then I looked the jar plugin and found that you can select what folder he has to use as source for the jar's contents, and that was it.

The end is:
1. Configure another execution of the resources plugin to copy all the content into a different folder.
2. Configure another execution of the jar plugin to use that folder.

Here's the particular fragment of the pom.xml, just in case

<build>
    <plugins>
        <plugin>
            <artifactId>maven-resources-plugin</artifactId>
            <executions>
                <execution>
                    <id>documentation</id>
                    <goals>
                        <goal>copy-resources</goal>
                    </goals>
                    <phase>package</phase>
                    <configuration>
                        <classifier>docs</classifier>
                        <outputDirectory>${project.build.outputDirectory}/../docs</outputDirectory>
                        <resources>
                            <resource>
                                <directory>src/main/resources</directory>
                            </resource>
                            <resource>
                                <directory>src/docs/resources</directory>
                            </resource>
                        </resources>
                    </configuration>
                </execution>
            </executions>
        </plugin>

        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>jar</goal>
                    </goals>
                    <configuration>
                        <classifier>docs</classifier>
                        <classesDirectory>${project.build.outputDirectory}/../docs</classesDirectory>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Expanding Slogans

My father often says we're in a time of slogans, in which people tend to keep the quick and easy slogan, forgetting its context. Judging from some things I read, he's right. I'm talking about programming slogans, in special (is what I do, after all) Java slogans.
The origin of this entry are doubts. I read some particular book talking about some particular good practice, the author writes some particular thing I'm not so sure about, and justifies it quoting a bibliography item. My doubts are about the grounds the assertion is made on. This time, I located the source of the quote, checked the context and saw that despite the seemingly justification obtained by the slogan, there's a lot more to it. Inspired by that, this entry is to remind the context of a couple object-oriented slogans that seem to be overused, in particular from the book Design Patterns: Elements of Reusable Object-Oriented Software.

Program to an interface, not an implementation

I've seen this sentence used to justify the creation of one Java interface for each class in an application, including domain classes, JavaBeans by the book.
First things first, it pays to remember this is not a Java programming book, but an object-oriented programming book, so "interface" does not mean "Java interface" but "class contract".
The point of interface-oriented programming is, quoting the book, "to reduce implementation dependencies between subsystems". So, you don't need Java interfaces when they're not different subsystems. If you're implementing an algorithm A and you use a class that is not to be accessed from outside the implementation, you don't need to create a interface for that class because it's the same implementation and subsystem.
Besides, in that context, a Java abstract class is an interface (class contract). If you have typical domain classes then they're only JavaBeans, and a JavaBean is a perfect implementation and interface of everything you'll need.
By the way, after the slogan it talks some more and one of the things that should be empathized is there, when it talks about instantiating concrete classes: if they're different subsystems, there shouldn't be something like IEntityA a = new EntityA(); because that's not really isolating implementation dependencies. Instead of that "new" you are supposed to use - for instance - a Factory.
In conclusion: Program to a contract instead of an implementation, and remember when you're writing part of the implementation or client code.

Favor object composition over class inheritance

Again I have seen this sentence used to justify "don't use inheritance", but what are the reasons between favoring composition?

Use composition when	Use inheritance when
	You need "instance of" and the reused element doesn't implement a Java interface
	You need to override part of the reused implementation
	You need access to protected elements
You need to change reused implementation at runtime
You add functionality (see delegation in that book)	You rewrite functionality

In any case, the main point in understanding this slogan is in the same book: "Inheritance and object composition [thus] work together"