Anybody out there?

Give me something,  anything to show you exist and saw this blog.

Significant Surefire release

This has a lot of long-awaited fixes in it.

copy/pasted from the email announcement:



The Maven team is pleased to announce the release of the Maven
Surefire Plugin, version 2.13

This release includes the maven-surefire-plugin, which executes the
unit tests of an application, the maven-surefire-report-plugin, which
parses surefire/failsafe test results and renders them to DOXIA
creating the web interface version of the test results, as well as the
maven-failsafe-plugin, which executes the integration tests of an
application.

Notable changes are;
A) Much improved summary of what went wrong when tests failed
B) Reusable forks supported for parallel builds; reuserForks="true"
gives forkMode="always" on stereoids
C) Stack trace trimming now works for JUnit4.x. The itch you didn't
know you had until it was scratched.
D) Includes and excludes can be read form file.
E) Nasty thread safey issue in parallel junit 4.x when class was
annotated with @Ignore.

You should specify the version in your project's plugin configuration:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>2.13</version>
</plugin>


Release Notes - Maven Surefire - Version 2.13



** Bug
    * [SUREFIRE-800] - redirectTestOutputToFile is not taken into
account in all cases with JUnit47 provider
    * [SUREFIRE-842] - maven-failsafe-plugin V 2.12 conceils issue #TRUEZIP-227
    * [SUREFIRE-892] - Surefire Report Plugin crashes on failsafe-summary.xml
    * [SUREFIRE-910] - Surefire 2.12.1 fails with "The forked VM
terminated without saying properly goodbye"
    * [SUREFIRE-913] - forkMode always - RejectedExecutionException
when > 500 tests
    * [SUREFIRE-915] - runOrder=failedfirst runs new tests last
    * [SUREFIRE-916] - surefire.junit4.upgradecheck fails with
ClassCastException: java.lang.Class cannot be cast to java.lang.String
    * [SUREFIRE-918] - Phase post-integration-test not executed when
tests are timed out with option 'forkedProcessTimeoutInSeconds'
    * [SUREFIRE-920] - -Dmaven.test.failure.ignore=true isn't honored
    * [SUREFIRE-926] - Multiple Providers, last one overwrites status
of first...
    * [SUREFIRE-930] - Regression - Failsafe does not execute TestCases
    * [SUREFIRE-931] - Surefire crashes if test depends on unknown group
    * [SUREFIRE-933] - forkMode onceperthread broken after fix for
JUnit category filter with empty result
    * [SUREFIRE-937] - Test count intermittently incorrect with
parallel junit provider
    * [SUREFIRE-939] - Class level @Ignore would create incorrect
shared state for parallel junit tests
    * [SUREFIRE-940] - Maven-failsafe-plugin do not run the TestNG.xml specified
    * [SUREFIRE-942] - surefire + testng suite doesn't do anything


** Improvement
    * [SUREFIRE-561] - after running test, when tests fail, it's hard
to the find the failure reason
    * [SUREFIRE-839] - If no tests are found that would match a given
JUnit category, mvn test should not fail in multi-module project
    * [SUREFIRE-925] - All includes and excludes to be read from files
    * [SUREFIRE-927] - configFailurePolicy is not supported on
Surefire plugin though it is supported on TestNG ant task
    * [SUREFIRE-932] - Improve or remove logging of TestNG configurator
    * [SUREFIRE-935] - Implement trimStackTrace  for JUnit 4.x
    * [SUREFIRE-936] - Make it easier to see which tests fail

** New Feature
    * [SUREFIRE-751] - Support parallel/fork mode similar to
http://maven-junit-plugin.kenai.com/
    * [SUREFIRE-882] - Fork x parallel JVMs once


** Task
    * [SUREFIRE-924] - generate every Surefire artifact site in
/surefire and redirect previous
/plugins/maven-(surefire|failsafe|surefire-report)-plugin
    * [SUREFIRE-934] - Remove getLocatedClasses() and size() from TestsToRun



Enjoy,

-The Apache Maven team

maven-compiler-plugin 3.0

I took a large multi-module build and used it to test out the reported build speed increases of the 3.0 release of the maven compiler plugin.



Here are my results:



mvn -Prelease -amd -fae clean org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:01.792s
[INFO] Finished at: Mon Dec 17 13:07:28 CST 2012
[INFO] Final Memory: 566M/1758M



mvn -Prelease -amd -fae clean org.apache.maven.plugins:maven-compiler-plugin:3.0:compile
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 59.787s
[INFO] Finished at: Mon Dec 17 12:56:53 CST 2012
[INFO] Final Memory: 90M/1964M


And to really knock your socks off:

mvn -Prelease -amd -fae clean org.apache.maven.plugins:maven-compiler-plugin:3.0:compile -T 1.5C
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 32.296s (Wall Clock)
[INFO] Finished at: Mon Dec 17 13:08:49 CST 2012
[INFO] Final Memory: 120M/1952M



You may also benefit with concurrency with your tests... since that is the bulk of your build times in Bamboo (or whatever CI server you use).

http://olafsblog.sysbsb.de/concurrent-execution-of-integration-and-unit-tests-with-maven/

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <configuration>
        <parallel>classes</parallel>
    </configuration>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <configuration>
        <parallel>classes</parallel>
    </configuration>
</plugin>

Graduating from ClearCase/ClearQuest

Once seen as the top source control tool by many, including myself, I have come to the conclusion that ClearCase is now dead. Yes developers, you can rejoice now - I said it... ClearCase is Dead. And I... Well, I am a former ClearCase zealot.

But why? What killed it? Speed, Support, and Windows/Eclipse.

Speed has to be factor #1. There is a reason why people wrote Subversion frontends to interact with ClearCase views... It took too many steps to get at their code. Making files read-only until checked out was a great idea 20 years ago -- but it is only a hindrance now (see Eclipse references later). ClearCase is also network transport intensive. Since the location of all the code was server-side only, in order to work with branches meant to create views and populate a snapshot -- or in our case you were forced to use a dynamic view or CCRC.

Support. Why does it have to be such a dirty word? Perhaps I should clarify... Why is knowledge so scarce? How is it that a consumer of a product could know more about the product than the vendor? Alright, I concede that I am certainly not the average ClearCase user -- and I have painfully learned that I am also not the average ClearCase administrator. But still, if I call your company, please be able to connect the dots -- and know what your software does. Don't make me do it for you.

And finally we come to the wonder that is Eclipse on Windows. I used to hate eclipse. It was the root of all evil. It is bloated and slow, and in my mind was replaceable with vi. Since then, I have learned that my issue isn't really with eclipse... it is with the population of developers that refuse to work in any environment other than eclipse in windows.

But why? It turned out to be the pain of supporting people using eclipse in ClearCase. Sure, the support for snapshot views are pretty good in eclipse -- and recently CCRC has received some great attention... but I am still marred by the support of users using dynamic views with eclipse.

The biggest problem? Files are read-only until checked out. CCRC addressed this with allowing the conversion of hijacked files to checkins. Without that, it was plain unusable. Those developers I referred to before who will only work on eclipse and in windows -- those are the same people who refuse to perform version control. They can keep their work in eclipse for a couple of months without trying to integrate it. This leads to pain, suffering, and merging hell.

So where can we go from here?

First Post - Welcome to SCME

So, you may be wondering…  “Why yet another SCM related blog (yasrb)?”   I submit to you that though there are many good blogs with decent information, there are some things that I know that I needed to research and put together all by myself - because no one published about it.

 

To all the CVS/Perforce/Subversion-ites out there…  I am not looking to create yet another forum for bashing ClearCase.  I happen to like the tool despite some of its shortcomings.  There are things I can do in ClearCase I couldn’t dream of doing in any other tool…

 

Now that we’ve cleared that up…

 

I am not an ancient oracle, nor am I a babe in the woods.  I have worked mainly with ClearCase, and have some experience with Perforce.  I started in Configuration Management in 2001, and have never looked back to doing straight development; or anything else for that matter.

 

Here is a summary of my current environment.  This may change if I change companies, but at good portion of entries after this one should be relating more or less to my experiences in this place.

 

·         We have about 700 ClearCase/ClearQuest users.

·         Running ClearCase 7.0.1 in Solaris with an NFS Maestro inter-op for Windows

·         95% of development is JAVA related.

·         80% of users use Eclipse

·         Most apps use WebLogic

·         Most apps are deployed with BladeLogic

·         There are 5 distinct groups of development with their own rules and needs which we are trying to bring together to one process

 

Feel free to leave a comment on this post to provide a topic that you would like to see discussed here in a future post.