Two weeks ago, all Scala projects required a little bit of extra configuration to point to a custom repository for Scala artifacts hosted at scala-tools.org. Today, Scala artifacts are now available directly from Central. The contents of scala-tools.org are now integrated into the Sonatype OSS repository hosting service, and other projects have started to publish artifacts Central.

The Scala community will see immediate benefits from this move. There are no more extra repositories to configure. It just got incrementally easier to use Scala. If you are new to Scala, you don’t need to reconfigure your repository manager to proxy another remote repository. The community will benefit from Sonatype’s continued investment in the infrastructure that runs Central: a cluster of machines in both the US and the EU continuously monitored by a dynamic DNS server that can reroute traffic instantly in the event of downtime.

How did this happen? Joshua Suereth, David Bernard, and Derek Chen-Becker provided the bulk of the administrative work, and they recently decided to decommision this server and transition repository hosting to the free Sonatype OSS service. Here’s the announcement by Joshua Suereth to the user forums on scala-lang.org on January 17th:

Scala-tools.org is going down and not accepting any new OSS projects. For those of us who wish to continue release software, I recommend migrating over to Sonatype. They put a few (good practice) limitations on contributions, but scala-tools.org would have done the same before long anyway. The benefit of Sonatype hosting is that your projects will make it onto the maven-central repository and benefit from the myriads of mirrors. Here’s the link for how to get started contacting Sonatype: http://nexus.sonatype.org/oss-repository-hosting.html

Publishing Your Scala Project to Central via Sonatype OSS

If you maintain a project that previously published to the scala-tools.org repository, here are three resources that provide guidance for Scala developers looking to publish Scala artifacts to Central:

• Publishing artifacts to Sonatype instruction written by Joshua Suereth on publishing to Sonatype OSS
• Publishing SBT Projects to Sonatype OSS from Cake Solution’s Specs2 Spring Project
• PublishToSonatype.scala some Scala code from Paul Phillips to automate the process of publishing artifacts to Sonatype’s OSS

The project automatically uses the latest Scala 2.8-Snapshot until it’s released (Maven will look for the latest version of the Scala language each time you build it).  We will setup the project to use cross-compiling, so the java-classes can access scala-classes and the other way around.

To read the full tutorial, click here.

Maven Stack Infrastructure

I’m going to talk about some of the under pinnings of the technologies we’re using as part of our Maven work. Why we selected the technologes and some of the current work that’s happening.

• Guice
• From Plexus to Guice (#1): Why Guice?
• From Plexus to Guice (#2): The Guice/Plexus Bridge and Custom Bean Injection
• From Plexus to Guice (#3): Creating a Guice Bean Extension Layer
• Peaberry
• Apache Shiro
• Enunciate

Maven

There are several develops going on in the various Maven projects. Maven 3.x is on the way, but we have some very interesting work happing with OSGi within our Tycho project. The Flexmojos project and NAR (the C/++ framework for Maven) are also popular.

Tycho

• Tycho Site
• Tycho @ Github
• Tycho/PDE Integration
• P2 Site

Flexmojos

• Flexmojos Site

NAR

• NAR Site
• NAR @ Github

M2Eclipse

The primary IDE integration we work on at Sonatype. The most important thing to talk about in M2Eclipse is the configuration framework.

• M2Eclipse Site

Hudson

Most of the work we’ve been doing on Hudson is still not really good enough for public consumption but we’re testing the changes we’re making on the Sonatype grid.

Hudson Site

Nexus

• Nexus Site
• Nexus: Improving Maven Central and Supporting the Maven Ecosystem
• Selecting OSS Software: 10 Questions Answered for Sonatype Nexus
• OSS Repository Hosting
• OSGi Central
• Ruby Central (We’re working on making that publicly available

Proviso

Proviso is not publicly released yet, but Alin and I have been working together to get our provisioning framework ready for a public release.

Git

We are starting to use Git heavily and soon likely exclusively. We are helping out on the EGit, and JGit projects at Eclipse and we’re trying to put a little Git server together based on JGit, MINA, and Apache Shiro.

• JGit Site
• EGit Site
• Tycho building EGit/JGit
• SShJGit @ Github

Maven Extensions

I’ll chat about these in the talk.

• Polyglot Maven Site
• Polyglot Maven @ Github
• Maven Shell
• Maven Shell @ Github

I’ll likely keep adding to the entry leading up the talk, but I thought I would get the ball rolling!

“This ended up being a much longer article than I anticipated but we’ve covered a lot of ground. Maven has worked it’s dependency voodoo which saved an enormous amount of time downloading jars and messing with classpaths. We’ve seen how the PAX toolkit from OPS4J makes creating, modifying and provisioning OSGi bundles a breeze. While the actual code examples were pretty trivial, we successfully managed to code up bundles in Java, Scala and Groovy. I think this displays a lot of the power that is offered by OSGi and points to a bright future for enterprise development on the JVM.”

Project-driven Plugins: Distributed, Open Innovation

In this case Maven is bridging a number of popular projects that have all created well-documented Maven plugins. Maven is the essential “glue” that allows someone like Brian to take a number of unrelated technologies and use them in ways that the designers of GMaven or the Scala plugin could never have predicted. As Maven matures and continues to evolve its Plugin API, we’re starting to see more projects and more systems commit to using it as an enabling “platform” for development. Those projects that have adopted Maven have found it beneficial to host and drive the Maven plugins that relate to their project or technology. Better support for Maven increases the adoption of Groovy, Scala, and (in this case) OSGi.

The PAX plugin is maintained and hosted by the Ops4J project, the Scala plugin is hosted and maintained by the Scala community, and the GMaven plugin is hosted and maintained by the Groovy community. Each community feels strongly enough about providing Maven support for their technology that they have made it a part of their project. This is important because it suggests an evolving approach to the way Maven plugins are created and supported. Four years ago, it was unlikely to see a project like Scala or Ops4J creating and hosting a Maven plugin. While Maven was already ubiquitous, projects still didn’t see Maven support as a primary concern. Instead, the plugin development would happen as part of the Maven community or in an ancillary community of Maven plugins known as the Mojo project at Codehaus.

Mojo is an important bridge. It allows third-party actors to craft support for tools like JBoss and GWT, but it is an aggregate, disjoint community with a single mailing list, perfunctory release votes, and little shared discussion about architecture or planning. It is a free-for-all. While Mojo does host some essential plugins it is also a dumping grounds for half-finished, owner-less plugins. As more projects provide their own Maven support, people should consider moving project from Mojo to the projects that develop the specific technologies in question. This is the “distributed” open innovation that will encourage quality, well-documented plugins.

Why Companies and Projects Need to “Own” Their Maven Support

We’ve transitioned into a point where projects need to start hosting and owning the Maven plugins that enable developers to use their software. Google would have been better off if they had invested a day or two crafting a solid Maven plugin for AppEngine before they announced Java support. Similarly, they should think about driving the development of the GWT plugin. If your project’s artifacts are available through the Central Maven repository, that is a first step, but if your project also publishes an artifact and a really compelling Maven plugin, you’ve made it trivial and easy for people to adopt your technology. “Going to market” without good Maven support no longer makes sense, and you should know that more and more developers are start with the question “how does this fit into my Maven build?” If your answer is “shrug, we don’t use Maven”, it is very likely that they will seek out other solutions that provide better integration.

If you are a tool vendor or create an open source framework, you should be hosting your own Maven plugin as a part of your project. If you support an SCM like Perforce or Clearcase, you should make sure that your software provides a solid SCM provider for Maven. If your company or project develops a server, you should be working with the Maven project to make sure that it integrates with Maven. To do otherwise is to invite your customers or users to look elsewhere for better integration. If you let someone else drive your Maven plugin, you are really just delegating an essential support function to the community. The message you are sending is, “we don’t really care that you use Maven, it isn’t a priority, someone will do the integration work for us”. This is true, but when that happens, you lose an opportunity to interact with your users and your customers.

PS: Brian’s post also inspired me to file this JIRA issue on the MVNDEF book project. Our book’s need code examples that can be more easily copied to the clipboard.