What The Software Maven is all about

Are you in a state of weltschmerz due to dealing with the proponents of accidental complexity that prevent us Software Mavens from enjoying our craft? Welcome home.

Here, we use the term Maven as described by Malcom Gladwell in The Tipping Point. Since wikipedia does such an excellent job paraphrasing it I'll quote:

Mavens are "information specialists", or "people we rely upon to connect us with new information." They accumulate knowledge, especially about the marketplace, and know how to share it with others. Gladwell cites Mark Alpert as a prototypical Maven who is "almost pathologically helpful", further adding, "he can't help himself". In this vein, Alpert himself concedes, "A Maven is someone who wants to solve other people's problems, generally by solving his own". According to Gladwell, Mavens start "word-of-mouth epidemics" due to their knowledge, social skills, and ability to communicate. As Gladwell states, "Mavens are really information brokers, sharing and trading what they know".

Unfortunately, as a Software Maven, we rarely get the level of respect deserved. Pathologically helpful? That really only means we fall victim to the sycophants who praise our ideas to benefit from our grunt work. "What a great idea. It just needs my two cents before I reply-all and become a member of this movement." This can be a manager, a shoddy architect or head of the fabulous committee. They will typically want to take the simplicity of your solution, the simplicity you worked so hard to boil the problem down to, and introduce a little overhead, called process, so it's ready for the enterprise.

Would you like an auto complete widget with that sir? Super size implied!

Us poor Mavens are left in the dust because we've concentrated more on solving the problems than how to market and promote our own ideas. Especially if the idea is too simple. While it should be ideal, the non-Mavens tend to gravitate towards more complex and elaborate ideas because it makes them sound smarter. Kiss K.I.S.S. goodbye! These same people also tend to blindly gravitate toward "proven technology" because it's safe. The pencil is proven technology, but it wasn't safe for the companies that fell behind the computer bandwagon.

So with this blog I'm striving to achieve a community of what I'm coining Software Mavens so it can serve as a connector for the people who like us, have a real passion for the field. Because it's not just a job, it's a craft.

Running tests from a Maven test-jar in your build

So one of the less frequently used features of Maven is that it allows you to package and deploy the test classes and resources to the repository. While the documentation suggests it's to reuse the tests, you can only use these as a standard dependency, not to re-execute them.

Well I was recently challenged with the task of re-executing the tests. I won't discuss the motivation behind the request as I'm not certain it's worthwhile. For now let's just assume you've been asked to do this too. I'll save you some time and share some of the things I discovered when trying to accomplish this.

So obviously we'll need to have the test-jar in the repository (see link above). We'll then need to pull it down and have surefire to execute it. The problem is that surefire does not have a "test jarfile" goal. So we'll need to leverage the unpack goal of the dependency mojo. Here is the xml for that:

<build>
<plugins>
...
<plugin>
<groupid>org.apache.maven.plugins</groupid>
<artifactid>maven-dependency-plugin</artifactid>
<executions>
<execution>
<id>unpack</id>
<phase>process-test-classes</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactitems>
  <artifactitem>
    <groupid>com.hirn</groupid>
    <artifactid>projecta</artifactid>
    <version>1.0-SNAPSHOT</version>
    <type>test-jar</type>
    <outputdirectory>${project.build.directory}/additionaltests/projecta/</outputdirectory>
  </artifactitem>
</artifactitems>
</configuration>
</execution>
</executions>
</plugin>
...

I'm assuming some basic Maven knowledge here but please comment if you have more questions about how this is configured. There are a couple personal selections worth discussing here.

The first is the outputDirectory within the artifactItems section. It may be tempting to unzip into src/test/java so that surefire will just execute the tests as a normal part of the cycle. This isn't good though because you could potentially clobber a test that already exists there. You can't create a separate directory within /src/test/java either because the package names wouldn't be correct anymore. I choose to use ${project.build.directory}/additionalTests/ (aka target) so that things get cleaned up naturally. It's also important to unzip each artifactItem into a separate folder to avoid possible namespace collisions.

The second is when to execute the goal. Process test resources seemed like a natural selection here, even though it's slightly against purist Maven lingo as the "resources" directory non class files. Another option could be to use the pre-integration-test. Just as long as it's before the phase we configure surefire actually execute the tests.

Since we extracted the executable .class files to a separate directory, we need to tell surefire when and what to execute. Here's one example:

<build>
<plugins>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>project-a-tests</id>
<phase>test</phase>
<goals>
  <goal>test</goal>
</goals>
<configuration>
<testClassesDirectory>${project.build.directory}/additionaltests/projecta</testClassesDirectory>
  <reportsDirectory>${project.build.directory}/surefire-reports/projecta</reportsDirectory>
</configuration>
</execution>
</executions>
</plugin>

Pretty straightforward. You have to make sure the phase is declared after the phase where the dependency is unpacked and point it to corresponding directory. The other piece to consider is that you don't overwrite the surefire report produced from running the rest of the tests. I couldn't find a way to aggregate the the report but wither or not you want to is personal preference. Would you even want your CI or reporting tool to track the success of executing these tests? Probably not, but you certainly don't want to affect the output of the tests within the projects.

You can download an example of this to see it in action. Just `mvn install` projecta and then do the same for projectb. You'll see the test run from projecta all over again.

Why I had to do this seemed to be pretty special case. My situation was driven by a peculiar scenario. There was a project A with dependencies A->B->C where A has a defect due to code that lives in C. Rather than create a new B, we just want to touch C and modify A such that A->B,A-C'.

One way to look at it is that there's no code change in B so why build it? The alternative is to say why not? Not only is rebuilding cheap (or should be), version numbers are free and it communicates to other projects using B that they need to upgrade to B'.

So if you have a good reason for executing tests from a deployed test-jar, I'd like to hear it. The whole time I was doing this it felt unnatural. I've never had to do this in over two years of extensive Maven use. The thing I love about Maven is that if it doesn't work automatically, you probably shouldn't be doing it. If this were truly useful, there would be a surefire:execute-jar goal.

JQuery vs. Prototype

Well thank you Michael for my first comment. Michael Minella had posted this article in response to a comment I made about telling Prototype I was never coming home after being with JQuery. I thought Glenn made a nice fair argument that Prototype is NOT dead and JQuery isn't such a god send that we should never look at it again.

I'm still not coming home.

Without going into specific differences between the two (I think there are plenty of articles on that), what I personally enjoyed about JQuery was the almost configuration based approach to instrumenting events on the DOM elements, thus keeping all of the JavaScript in one place. Sure I learned after the fact that you can do it in Prototype too but JQuery kinda prescribes it with the $(document).ready() function. So I thank JQuery for opening my eyes to this style of instrumenting DOM elements.

Many people seem to use performance in this debate. I never noticed Prototype to be "slow" unless benchmarked against JQuery (slickspeed). But 1ms vs. 6ms? Come on it's the web! Where else do developers get so say to hell with shaving milliseconds? Most of my performance concern is server side where you are saving seconds or preventing a complete meltdown during peak hours. Sure if I were building an ACID compliant DB in JavaScript I might profile my JavaScript it but for making a <div> wiggle, the differnce in imprecivable. So any points about JQuery performance hold little water with me.

If performance were the primary concern, I would have prefered Dojo over Prototype. I'm sure Dojo's excellent in its own ways but the syntax always felt more geared towards developers instead of designers . When I'm knee deep in content, I prefer to keep my designer hat on. JQuery and Prototype/Scriptaculous both seem to keep me in my happy place, which is especially necessary for me when doing any front end development.

When it comes down to it, the tangible reason I now prefer JQuery was its suggestion that one should instrument elements in the ready() function, which in turn keeps event based function calls out of the HTML. That little trick was enough to make me really enjoy JQuery and I haven’t missed anything that would make me come home. Honestly, I wouldn't mind using either or at this point. They really are pretty similar as far as what you can get done and community support, even though JQuery seems to have the momentum at this stage in the game.

So, I’m sorry Prototype. I’ll never forget the awesome times we shared . Should we meet again, don’t be surprised if I pull out some tricks I learned while away.