When running in a console window, pressing CTRL+Break signals the JVM to print out all stack traces of currently running threads.

If your application runs as a service (or linux/unix dæmon) you can’t press CTRL+Break, so you have to signal the JVM yourself to produce the stack trace. You can do that on linux by signaling a QUIT to the process, or by using jstack and the PID.
Good news, Java SE 6 on Windows comes with jstack. Yupee! .

So next time you need a thread dump from a java application running as a service just get the pid, fire up a cmd and run jstack <pid>.

If your project requires quite a large data model and it so happens that you have a xml schema definition on hand, you can easily transform that XSD into Java classes using Maven 2, JAXB and some manual labor.

Things you might want to know:
* doesn’t work out of the box on JSE6. It actually needs a lot of work, so avoid using for now;
* you need a maven project
* you actually need a valid XSD

The classes are generated by JAXB xjc. You can do this by hand, but using maven and maven-jaxb2-plugin makes it a breeze.

So, this is what you must do:
* Place your schema definition in your src/main/resources directory
* Open you pom.xml and add the following(no worries, you will remove them later):


<repositories>
<repository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Maven 2 Repository</name>
<url>http://download.java.net/maven/2</url>
</repository>
<repository>
<id>maven-repository.dev.java.net</id>
<name>Java.net Maven 1 Repository (legacy)</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>maven2-repository.dev.java.net</id>
<name>Java.net Maven 2 Repository</name>
<url>http://download.java.net/maven/2</url>
</pluginRepository>
<pluginRepository>
<id>maven-repository.dev.java.net</id>
<name>Java.net Maven 1 Repository (legacy)</name>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</pluginRepository>
</pluginRepositories>
<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.0</version>
</dependency>
</dependencies>
* In your build section configure the jaxb2 plugin:

<plugin>
<groupid>org.jvnet.jaxb2.maven2</groupid>
<artifactid>maven-jaxb2-plugin</artifactid>
<executions>
<execution>
<goals>
<goal>generate</goal>
</goals>
</execution>
</executions>
<configuration>
<includeschema>**/*.xsd</includeschema>
<generatepackage>com.gridpulse.project.model</generatepackage>
</configuration>
</plugin>

As you can see, you have 2 configuration settings:
* includeSchema - schema file mask to include
* generatePackage - the package that you would like to hold the classes

After setting this up, just fire up a mvn install. This will produce the model classes in the target/generated-sources/xjc/ directory.
You can now copy them to your src directory and clean them up.
Remember to remove the JAXB2 settings from your pom.

Before JiBX 1.1.5, names on collections were optional. That changed

Now, although the docs say that the name attribute is optional on collections, it’s actually required in the real world.

Some flexible setups, like mine, get really confused if the name attribute is specified, and, because it is required I can’t even bind it without setting validate to false, and if I set validate to false, the JiBX_MungeAdapter appears in my module root (${basedir}) instead of the required package.

The only solution I found for this problem is to downgrade to JiBX 1.1.3 and maven-jibx-plugin 1.1.3. I know it isn’t a real solution but what can I say, half a day is too long to loose working on something that can be fixed by a minor-version downgrade.

Sometimes, when one of your modules is used by different applications, but requires slight changes, you want to create different artifacts, that can be direct dependencies of those applications.

You can do this by using profiles and classifiers.

You can create your pom, the usual way, with profiles…more here, then apply classifiers to the package plugin inside your profile, like this:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>war</goal>
</goals>
<configuration>
<classifier>standalone</classifier>
</configuration>
</execution>
</executions>
</plugin>

This will produce an artifact with finalName

${artifactId}-${version}-${clasifier}

that will be accessible by specifying the classifier in your dependency.

Just remember to use executions because it will not work otherwise. It will build the artifacts, but will not deploy them.

Really!

I’ve been a Maven user since 2005, but only as a “user”, never creating build files, never really understanding the full picture.

I used to be a skeptic, but now I am fully converted. For the past 3 days I’ve been migrating the build process for a 15 module project from ant to Maven 2 and I have to admin that once you get past the dependency configuration, everything else is a breeze.

The build file size, maintaining every functionality, has decreased by two thirds, and is now more readable.

Everything from JiBX binding to build versioning is almost out of the box by using the plugin system. Plus, the Surefire plugin just works, no hassle there, running all tests with testng, although it’s slower than the direct testing I used to do with ant.

Anyway, it’s worth loosing two or three days, the benefits are huge.