Visualizing code changes

Visualizing data can be an effective way to spot things that are usually hidden behind the scenes.

In that respect I like to visualize code in different ways and with Gource we have one way to visualize code changes. So using 'Animating JBoss projects with Gource' as a guide I made the following video:



Although it's a beautiful video, I fail to find any data points in it that might be useful.

But maybe after you've seen the video you can spot some?

My shell keeps quiting

So I was writing a little shell script to setup some environment variables and out of habit it became:

#!/bin/bash
set -e
export X=Y

First mistake: to take in environment variables from a script I need to include it, not execute it. But whatever and moved on. And did the inclusion.

All of a sudden whenever a command return an error my shell would terminate.

Yep, second mistake (very silly) by including I had set my shell options to exit on error.

Ah well, it brought a smile to face. ;-)

Maven parent snapshot

Another case where Maven just won't listen to me. This time I want to release an artifact which has a snapshot parent dependency.

  <parent>
    <groupId>org.jboss.jpa</groupId>
    <artifactId>jboss-jpa-build</artifactId>
    <relativePath>../build/pom.xml</relativePath>
    <version>1.0.1-SNAPSHOT</version>
  </parent>

So first of all, why have the snapshot?
Because I want to have continuous integration runs on my Hudson instance.

Now I want to change the snapshot during release to 1.0.1. This is slightly bending the previous requirement where I want CI to happen. The reason is that during the lifetime of this component jboss-jpa-build will continue to evolve, while this component might remain static. So after some time this component will have a dependency on a stale snapshot. (I really want to have [0,) or latest.integration, but that's another story.)

$ mvn -DdryRun=true release:prepare
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'release'.
WAGON_VERSION: 1.0-beta-2
[INFO] ------------------------------------------------------------------------
[INFO] Building JBoss Container Managed JPA Deployers
[INFO]    task-segment: [release:prepare] (aggregator-style)
[INFO] ------------------------------------------------------------------------
[INFO] [release:prepare]
[INFO] Verifying that there are no local modifications...
[INFO] Executing: svn --non-interactive status
[INFO] Working directory: /tmp/deployers
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : enter
Resolve Project Dependency Snapshots.: 'org.jboss.jpa:jboss-jpa-build' set to release? (yes/no) yes: : enter
What is the next development version? (1.0.2-SNAPSHOT) 1.0.2-SNAPSHOT: : 1.0.1

What is the next development version? (1.0.2-SNAPSHOT) 1.0.2-SNAPSHOT: : 

Snif...
Okay, let it ride until the end by specifying the default versions. Now we can change release.properties to match what we want:

dependency.dependency.org.jboss.jpa\:jboss-jpa-build.development=1.0.1

And tell the release plugin to restart:

completedPhase=map-development-versions

Then execute

mvn -DdryRun=true release:prepare

again.

And come to the conclusion that we encounter a bug http://jira.codehaus.org/browse/MRELEASE-449.

Error writing workspace state file

Todays maven problem is a m2eclipse problem. Somehow I get 'Error writing workspace state file' which leaves me in a workspace which doesn't properly update anymore.

org.eclipse.core.runtime.CoreException: Could not read maven project
 at org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:190)
 at org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Contains: Cannot resolve pre-scanned extension artifact: org.apache.maven.wagon:wagon-scm: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6
org.apache.maven.extension.ExtensionScanningException: Cannot resolve pre-scanned extension artifact: org.apache.maven.wagon:wagon-scm: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6
 at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModelBuildForExtensions(DefaultBuildExtensionScanner.java:369)
 at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:187)
 at org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:120)
 at org.apache.maven.embedder.MavenEmbedder.readProject(MavenEmbedder.java:377)
 at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody0(MavenEmbedder.java:416)
 at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies_aroundBody1$advice(MavenEmbedder.java:304)
 at org.apache.maven.embedder.MavenEmbedder.readProjectWithDependencies(MavenEmbedder.java:1)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl$MavenProjectReader.execute(MavenProjectManagerImpl.java:1117)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.readProjectWithDependencies(MavenProjectManagerImpl.java:967)
 at org.maven.ide.eclipse.internal.project.MavenProjectFacade.getMavenProject(MavenProjectFacade.java:180)
 at org.maven.ide.eclipse.internal.project.WorkspaceStateWriter.mavenProjectChanged(WorkspaceStateWriter.java:52)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.notifyProjectChangeListeners(MavenProjectManagerImpl.java:698)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.refresh(MavenProjectManagerImpl.java:366)
 at org.maven.ide.eclipse.internal.project.MavenProjectManagerRefreshJob.run(MavenProjectManagerRefreshJob.java:95)
 at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.apache.maven.extension.ExtensionManagerException: Failed to resolve extension: org.apache.maven.wagon:wagon-scm:jar:1.0-beta-6
 at org.apache.maven.extension.DefaultExtensionManager.init$_aroundBody2(DefaultExtensionManager.java:352)
 at org.apache.maven.extension.DefaultExtensionManager.init$_aroundBody3$advice(DefaultExtensionManager.java:384)
 at org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:352)
 at org.apache.maven.extension.DefaultExtensionManager.addExtension(DefaultExtensionManager.java:148)
 at org.apache.maven.extension.DefaultBuildExtensionScanner.checkModelBuildForExtensions(DefaultBuildExtensionScanner.java:365)
 ... 15 more

Constraint violated, transaction rolled back

When using bean validation on JPA entities within an EJB 3 bean you would actually get an EJBTransactionRolledbackException if there is a constraint violation.

javax.ejb.EJBTransactionRolledbackException: Invalid object at persist time for groups [javax.validation.groups.Default, ]
Caused by: javax.validation.ConstraintViolationException: Invalid object at persist time for groups [javax.validation.groups.Default, ]

This is all nicely according to specification, but not really interesting information. You don't really want to know what happened, you want to know what went wrong.

So I recommend adding the following to your ejb-jar.xml:

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar
        xmlns="http://java.sun.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                            http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
        version="3.0">
   <assembly-descriptor>
      <application-exception>
         <exception-class>javax.validation.ConstraintViolationException</exception-class>
         <rollback>true</rollback>
      </application-exception>
   </assembly-descriptor>
</ejb-jar>

That way you can directly access your violations.

Exceptions should tell a story

So I was happily plumbing along to get bean validation to work in AS 5.2, when I got this client side:

org.jboss.serial.exception.SerializationException: Could not create instance of org.hibernate.validator.engine.ConstraintViolationImpl - org.hibernate.validator.engine.ConstraintViolationImpl
Caused by: java.lang.InstantiationException: org.hibernate.validator.engine.ConstraintViolationImpl

For some reason jboss-serialization was looking for a default constructor, which obviously wasn't there.

Now the most recent release showed ConstraintViolationImpl implementing Serializable, so I crossed that out as a problem. (I didn't realize at this point that I was using an old version, but that's not the point of this post. :-) )

Using the JDK serializer gave it away:

java.io.NotSerializableException: org.hibernate.validator.engine.ConstraintViolationImpl

At which point it was obvious that I was using the wrong version.

At the end of the day I only have a complaint about the exception in jboss-serialization. If it said something in lines of: "class is not serializable and has no default constructor" I would have been a happy camper.

So the moral is: always let an exception tell a story.

Remember: MC == Necromancer Magic

While working on EJBTHREE-1889 I stumbled right into an assumption boobytrap. In my mind I figured that a MicroContainer bean would have a state diagram as shown on the left side. In reality MC bean instances can be 'destroyed' and then 'created', because for MC it's just a state change with no additional semantics.

"Specifically the beans named in the @Depends or values will reach their CREATE states before the bean declaring the dependencies reaches its CREATE state. The same is true for the START, STOP and DESTROY states." [MC 12.3]

So MC is voodoo magic, it will resurrect your bean. :-)