We’re making SSL connectivity to Central available to anyone that downloads open source components regardless of the repository manager. Given the tremendous growth of Central, and the fact that modern applications are largely built from OSS components, this capability is likely to be leveraged by many organizations. SSL has become the standard mechanism for protecting web traffic – across the spectrum of Ecommerce, banking, health care, and so on. Providing SSL support for Central means that your components are no longer susceptible to man-in-the-middle attacks that could compromise the component. SSL also eliminates the potential for a hacker to gain visibility into your organization by tracking the components that you download for your development initiatives.

As of Nexus Pro 2.2 (available now), SSL is now the default connectivity option for Nexus Pro users. Because we take security of the ecosystem seriously, we aren’t stopping there, we’re making SSL connectivity to Central available to you even if you aren’t using Nexus Pro.

In order to ensure the highest level of performance for those who count on SSL, we are securing the service with a token. You can get a token for your organization simply by providing a $10 donation that will be donated to open source causes. For the first 60 days all donations will go to the Apache Software Foundation. After that, the donations will go to other open source foundations such as Eclipse. Sonatype will provide a donation on behalf of Nexus Pro customers since we’ve included SSL access to all Pro customers automatically.

If you happen to be using Nexus OSS (any version), support for the SSL token is included already. I’ve already reached out to the Artifactory and Archiva teams and they are working on the changes necessary to enable SSL to Central – we’ll let you know when that support is enabled. If you’re not using a repository manager at all, what are you waiting for?

If you are an existing Nexus Pro customer, you can download the latest release from the support page.

If you would like to make a donation to the open source community and get SSL access, you may do so here.

Have Jenkins (or Hudson) up and running, and want to give Insight for CI plugin a try? The plugin is available in the plugin center and easy to install and configure. — Just add a post build step and configure it to scan (e.g. your build output war file). Get the plugin.

Summary and component results are completely free and will give you a very good indication of the security and license issues (or better their absence) of your software. We’ve even got you covered for manual scans – have a try with Insight App Health Check.

Only a few years ago, Central was a single Dell server running in a Contegix datacenter in St. Louis (you can see it here). From 2007 to 2011 the server was used 12 billion times by 14.3 million unique IP addresses, and since then traffic from a world of developers has only continued to increase. Over the years we’ve invested in both capacity and stability improvements, but today I’m announcing what I consider to be the biggest improvement to date.

Today we announced an agreement with EdgeCast Networks. EdgeCast Networks is a CDN with global reach that we are going to use to both accelerate the delivery and increase the availability of Central. Every Java developer who uses Maven, Gradle, or Ivy (possibly every Java developer in the world) will see immediate improvements in the speed of Central. Index downloads and artifact downloads will be served from one of EdgeCast’s 21 points of presence distributed over four continents. Your builds are going to run faster because of Sonatype’s agreement with EdgeCast.

In addition to this, Sonatype Nexus Pro customers will now have access to end-to-end Secure Socket Layer (SSL) encryption, bringing a greater level of security to their software development processes.

Two weeks ago we talked about how many of the projects hosted in Scala Tools are moving over to publish directly to Central. That process is ongoing. In this post, I want to start something new. At Sonatype we touch a lot of different technologies and communities, and I want to make sure that we’re doing all we can to help put a spotlight on some of the communities that we’re watching. Whether it is a .NET-focused open source foundation like Outercurve, a customer that contributes back to Nexus OSS or, in this post, the Scala community, I think that Sonatype can at least help introduce some of these interesting technologies to a larger audience.

So, what is Scala?

The JVM saw an explosion of “alternative” languages over the past several years. From clojure to jruby to scala, each language tends to have a specific “sweet-spot” it solves more efficiently than other languages. If you are interested in rapid web development, JRuby has become a solid option alongside Rails. Scala’s “sweet spot” is providing a functional programming language that provides an elegant way to think about concurrency and parallelism while integrating concepts of OO programming. Where languages like Ruby and Python have become logical choices for front-end web development, Scala has increasingly become the default choice for the kinds of massively parallel systems that make sites like Twitter, LinkedIn, and Google run. Scala’s applications range from large-scale scientific simulations, to high-speed, algorithmic trading applications, to systems like ad-exchanges. Here are some interesting people, projects, and companies that use Scala:

• Martin Odersky, creator of Scala, co-founder of Typesafe, discussed trends in parallelism that drive Scala at O’Reilly’s OSCON ‘11. This is a great if you are looking for some motivation behind functional programming.
• Everytime you Tweet, you Scala – Also from O’Reilly’s OSCON ‘11 Raffi Krikorian from Twitter discussed Twitter’s migration from a Ruby on Rails architecture, to an architecture that relies on Rails as a Front-end, Scala as a foundation for web-scale storage and retrieval.
• Scala at Square – Square’s a mobile payment service poised to garner some big attention this year as several major US presidential campaigns have adopted it as a mobile payment platform. Well, if you Square, you are also making use of Scala. Bob Lee, the CTO of Square mentioned Scala in his OSCON talk about a coming Java renaissance.
• Use Quora? You also use Scala. – According to this answer on Quora, Quora engineer Kah Seng Tay suggests that Quora is moving some systems to Scala because it is “fast, concise, type-safe, object-oriented yet functional, easy parallelism, extensible and built on the JVM”.
• Foursquare, Sony, Xerox, Siemens, The Guardian, Novell, LinkedIn, and more examples at scala-lang.org.

Note: What about Lift? Or Scala-tools? Why didn’t I mention X, Y, or Z? We’re not done featuring interesting Scala projects, this is the just the first installment.

When you Scala do you use Maven or SBT?

Now, you might assume that Sonatype has a definite opinion in this space. After all, didn’t we write a series of Maven books?

Yes, we did, but we’re also an increasingly “tool agnostic” company. While you’ll see a good number of our examples focus on Maven, we understand that the world uses more than one build tool. In Scalaland, it’s a choice between the maven-scala-plugin and SBT. Both seem to present a solid option with most pure Scalaist seeming to prefer SBT over Maven. There was a discussion at scala-lang.org about the relative merits of SBT vs. Maven in December of 2011, and it looks like there are a equal number of people suggesting SBT vs Maven.

Whatever you use, your build tool is still going to download from Central, and it would benefit from using a local repository manager like Nexus. In the next installment of our Scala coverage we’ll talk about how to use Scala with a repository manager.

One last thing…. The other nice thing about Scala is that Scala skills are in high demand. Every time I speak with someone running an organization that uses Scala, they are always looking for people familiar with Scala. Most companies that use Scala, end up having to just hire smart developers and train them on Scala. It’s clear that knowing Scala well will put you in an advantage for a particular type of company that is engaged in “big data” work. For example, last I heard Square was looking for Scala talent.

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

At Sonatype, we want to make synchronizing and publishing your artifacts to Central easier and to improve the quality of repository metadata for everyone at the same time. To facilitate this, we offer a dedicated instance of Sonatype Pro for Nexus at http://oss.sonatype.org specifically to host the artifacts of open source projects. In this post, I talk about the process of creating a repository for your open source projects and publishing artifacts so that they will be available from the Central Repository.

This service has been available since 2009 and includes many projects such as Plexus, Jetty, Google Guice, Spring and Ehcache (Greg wrote about his experience with migrating to oss.sonatype.org). We have tooling in place to make it easy for us to process a larger set of requests, so we invite everyone to use this resource. As of October, 2011, we have over 1,500 projects using this repository on a daily basis.

To get the process started, go here. We’ll setup a release and snapshot repository for your project, along with the appropriate configuration to allow you to use the staging features for your releases. If you have an existing repository somewhere, we can migrate that for you too. We’ll even help you add artifacts to Central that you use, but don’t necessarily own — assuming of course that it doesn’t violate the projects license.

The system allows customizable rules to be run during the staging process, which allows us to automatically check things like valid pgp signatures and correct POM parsing. This will ensure that your users have the best experience possible when using your artifacts, and relieve some of the manual validation on your side — a win for everyone.

On the technical details, this instance gets its network connection via Contegix‘s high availability network, the same one running Central, Codehaus.org and Atlassian.com. New Relic has donated monitoring services to help us monitor and tune this instance of Nexus. Since OSSRH is hosted on the same infrastructure as the Central Repository, we are able to frequently synchronize the repositories.

Next time you need to add a project to the Central Repository, you’ll know how.

Many JBoss projects, including JGroups, Javaassist, Netty, Hibernate, HornetQ, RestEasy, jBPM and Drools are now included in the Central Repository with more expected to be added in coming months. You’ll be able to easily locate and use these projects in a single, standard location.

The Sonatype team worked closely with JBoss Community project teams to evaluate legacy repositories, cleanup metadata and coalesce disparate content into a single site. Providing transparent, streamlined access to important project artifacts in the Central Repository further accelerates the development process and enables the JBoss Community to more rapidly provide its open source technologies to users.

The Central Repository is the industry-leading source for open source Java components used by over 40,000 development organizations daily. Sonatype has been working to expand the number of components available in Central.  By adding the JBoss projects and the Java.net projects announced last month, we expect the Central Repository to offer you access to more than 90 percent of all open source Java projects by the end of this year.

Read more in our press release.

Since 2007, Central has been hosted at Contegix in a shared rack with 100mbps data connections to the Internet. We’ve worked with Contegix to acquire a new dedicated switch that will have a 1gb connection directly to their core routers. The routing to the switches is done at the Layer 3 (IP) level and this means we are moving to a new dedicated ip subnet:

• 207.223.241.64/27 (207.223.241.65 – 207.223.241.95)

In addition to the network upgrade, we’ve added an entirely new tool to our belts: Dyn (formerly DynDNS.com) is partnering with us to provide active monitoring, failover and global load balancing along with enterprise DNS services for maven.org via their DynECT Managed DNS solution. DNS resolution time should be noticeably faster as Dyn has DNS servers all around the world.

Availability will be improved as we have added geographic diversity with servers located in both the US and the UK. The DynECT Active monitoring service monitors http://repo1.maven.org/maven2 every 60 seconds and if any timeouts or errors are detected, the system will instantly switch over to alternate Central servers.

Although traffic to Central from Europe represents nearly 50% of overall load, the UK servers are serving less than 2%. This means most of our European users aren’t using the http://uk.maven.org/maven2 urls directly. DynECT has a load balancing solution, Global Server Load Balancer (GSLB), that will transparently direct traffic to our servers based on the user’s location. While our bandwidth costs are higher in the UK, the enhanced experience for almost half of our users is well worth the investment.

Firewall Updates May Be Required

These changes that provide the community benefit of increased stability, uptime and geographic load balancing required us to change our IP addressing such that we can no longer offer a single, static IP address for Central.

If your organization utilizes firewall rules with specific IPs, please allow this list so that you won’t be affected by any failover or balancing that may occur:

• 207.223.241.90 : Current US primary
• 207.223.241.91 : Current US staging
• 207.223.241.92 : Current US standby
• 207.223.241.64/27 (207.223.241.65 – 207.223.241.95) Future US Subnet
• 89.167.251.252: UK Primary
• 89.167.251.253: UK standby
• 89.167.251.249: UK standby

We anticipate the cutover to the new switch and IP addresses to occur between August 1, 2011 and August 5th, 2011. Shortly after that, we will slowly start to roll out the global load balancing. As long as you have allowed the IPs listed above and use the http://repo1.maven.org/maven2 url in your systems, the only things you should notice are faster resolution and download times.

Thanks again to Contegix and Dyn for helping us to provide enterprise level services to the development community.

In the natural course of machine rotations, I had some out of warranty machines de-racked, packaged up and sent from the Contegix datacenter to our headquarters in Silver Spring, MD.

When I was unboxing them it dawned on me for the first time that I was laying eyes on a machine so many people have relied upon for years and yet had been so far unseen. Well here it is:

A few facts about Central during the time it was hosted on the machine you see here (3/2007 – 3/2011):

• Original configuration:
  • Dell PowerEdge 2950
  • 2 x E5310 Xeon 1.6ghz processors
  • 4gb 533Mhz RAM
  • 3 x 73gb SAS 15k Hard drives
• Artifacts requested over 12 billion times by 14.3 million unique IP addresses
• Repository size as of Jan, 2009: 60gb (this is the earliest confirmed size I can track down)
• Repository size as of today: 286gb
• Projected size next month with the addition of Java.net: 350gb
• This machine never had a hardware failure. In fact, even the original drives and RAM are still functioning perfectly.
• It was only rebooted / powercycled twice, once to add more RAM and once to add some bigger disks

It boggles my mind to think about how many applications both commercial and open source contain bits fetched from this singular machine. Now that we have 2 machines in the UK and 2 VMs floating across 6 hosts in the US, there can never be a single machine in the future we can gaze upon and say “that was Central.”