I have been working with Java and its related technologies since 1997 - the first two years managing a team using the pre-release, 1.0, and 1.1 versions (primarily for the cross-platform benefit to make new front ends for a Unix/C++ system) and the remainder years as a consultant with Intertech. One of my favorite things about Java is its ecosystem, having watched a number of things form (and fade!) during that time.

Recently I had another conversation about its amazing ecosystem, commenting on the various facets of it - such as the JVM, community, products, support, maturity. With the community, it is mind blowing how many free-open-source (FOS) framework and tool products exist and continue to emerge. Yes, many are junk, unfinished, or just interesting (or not!) experiments. However, there are some very useful, successful, proven, well-adopted, and supported ones. We talk about some of them in everyday conversation - Spring, Hibernate, Tomcat, Maven, Ant, Eclipse, et al - almost taking them for granted. The Java ecosystem has enabled many successful new, and expansion of existing, companies.

At the onset, FOS software were few, far-between, and disorganized. Out of chaos emerges organization. Forges, such as SourceForge, emerged to provide some organization and aggregation. Curators such as Apache emerged to help foster higher quality, support, and consistency levels. More recently, Google established Google Project Hosting. Java FOS is very alive and well - thriving in fact. SourceForge reports over 43,000 Java projects.

The community around the FOS products is very large. Most of the products, particularly active ones, will have one or more email lists for help and discussion of the product, and I've seen this support exceed some of the commercial product support! Some products have individuals and/or organizations also offering commercial support contracts for escalated support response and priority for new features and correcting defects. Additionally, organizations using well-adopted FOS products also have an easier time finding people with existing skillsets in them - often learned from and participating in the FOS community.  Just look at some of Intertech's Java training offerings - Eclipse, Spring, Hibernate, iBatis, Struts...!

Another interesting facet of FOS in general is the corporate involvement in creating and supporting it. Besides individuals donating their time and talent, companies such as Google open source their free products that their employees create. Many of us use the Eclipse IDE.  IBM initiated this product and subsequently donated it to the newly established Eclipse Foundation (Eclipse has a very impressive release track record - the processes, tools, and coordination required to is a topic of its own!).  I have had a number of business people ask me about this - fascinated that companies and we developers would do this - and this is yet another topic of its own! :-)

The core enabler of Java's ecosystem is the JVM. It is highly performant, stable, and many languages can run on it. Besides the Java language, better-known ones are Groovy, Scala, JRuby, and Jython. Even ColdFusion has migrated to a JEE application that runs the CF apps. An interesting browse is the VM Languages blog - this site has listed over 300 languages that run on the JVM as of Feb 22, 2010: http://www.is-research.de/info/vmlanguages

Targeting the JVM with your language(s) of choice provides a flexible runtime environment. Most of us also know that there are JVMs for many different platforms, such as Mobile, Windows, UNIX, GNU/Linux, and mainframes. This allows your applications to run on the correct class of hardware for needs such as scaling and operations team skills/support. It also allows developing on the developer workstation of choice, e.g. Mac, Windows, GNU/Linux Desktop, and deploying to a potentially different operations environment, such as Solaris, or a multi-platform runtime environment.

Java's innovating ecosystem expands to other platforms too. A number of its tools and frameworks have been ported to other languages/environments, particularly .Net. For example, Ant -> NAnt, Maven -> NMaven, Spring -> Spring .Net, JUnit -> NUnit, CPPUnit (and many others).

My goal in sharing this is not an in-depth essay of all the merits of Java's ecosystem, but to share some of the recurring conversational points I have had, possibly encouraging you to further explore any of them. Java is very popular and successful, and its ecosystem is simultaneously a contributor and a result of it.

An SMTP Test Server

I am working on a new product for a customer, and it will send a number of emails to users.  I also set up sending emails to the development team for runtime diagnostic information for "those situations".

Of course, we need automated integration tests (ITs), aka functional tests, to prove these email features work.  There are a number of OSS SMTP server products to use, and the key thing is to use one that is fast & easy to setup and teardown in a functional test.

This time I chose SubEtha SMTP, a Java library with a simple email test harness named Wiser.  It's fast, easy, and works well in the functional tests.

Not Current

There was one problem though, the latest SubEtha SMTP version in Maven Central repository was really old, and we encountered a couple of problems that were fixed in more recent versions.  We needed the newest version, and since I have been successfully using Maven for over 5 years, and again on this project, this was important to resolve.

Fix It

I could have simply built SubEtha SMTP and deployed it to my customer's local Maven repo, hosted by Nexus (setup and managed by me!).  But that doesn't solve the real problem.  Since SubEtha SMTP was a pretty good product, I wanted to solve the problem permanently and for others.

Create Maven Build

I planned to create one, but found an existing request in SubEtha's issue tracker to deploy a new release to Maven Central and commented in it.  A discussion ensued; the summary is the SubEtha developers didn't care to use Maven or deal with Maven Central repo updates.  However, they were happy to have me do it for them.  So I created a POM for SubEtha SMTP and committed it.  With a simple command, Maven builds and packages the product into a jar, and also creates jars of the source and JavaDoc.  Almost there?

Host It

The next step was to setup something to get the artifacts to Maven Central.  I've done this before on other OSS products I've worked on, and it involved either a manual upload request (no thanks!) or syncing with a self-made repo on a forge, like SourceForge.  This was ok, but took some extra effort on my part and extra time waiting for it to happen.

Enter Nexus

Recently, Sonatype, the creators of Nexus (a Maven repository manager), began offering free Maven repository hosting for OSS products.  They have a page for the Nexus OSS Repository Hosting info.  Anyone can use/view the Nexus OSS repo, browsing the product repos and their artifacts already setup there.  Additionally, if the build artifacts comply with a number of items, the repo owner can request to have the Nexus OSS repo automatically synced with Maven Central.  Hmmm, sounds perfect.

Having setup Nexus for my current and prior customers (I even used and liked its predecessor, Proximity!), I know what a great product it is.  With the need to get SubEtha SMTP to Maven Central repo, this seemed like the best option - using it as the public repo and auto-syncs to Central.

Couldn't Be Easier

Setting it up was very easy - I just read and followed the information on the Nexus OSS Repo Hosting page.  I created the JIRA ticket requesting the Nexus repo on a Saturday, and Monday morning it was created.  That Monday night, I deployed to the new repo, and then requested the auto-sync to Central.  Approximately 5 hours later, the auto-sync was approved and occurred!  It can't get faster and easier than that! 

Done - D. U. N.

As my wonderful grandfather used to say, "Done, D  U  N"; I have very fond memories of him teasing me with that errant spelling when I was wayyyy too young to understand!  :-)

I reported the successful deploy to Maven Central on the SubEtha SMTP issue, closed it as fixed, and received a couple of thank you's :-).

Thank you Sonatype for creating Nexus and offering this service!  It is fantastic.  I'll move other projects' artifacts to there as well.

P.S.

Interestingly, with the many problems on java.net, especially with the (lack of) support for Maven deployed artifacts there, Sonatype is orchestrating a great effort to help java.net projects migrate their Maven repo hosting to Nexus OSS.  For more information on that, read the Sonatype blog on Java.net Maven Repository Rescue Mission on March 5th.