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.

Historically the JBoss and Java.net repositories have been painful for Maven users. The reasons for this pain differed in each case, but overall these repositories have affected a large section of the community because of the popularity of the artifacts they contain.

The JBoss repository generally had decent metadata and release practices.  The major concern in this repo was that the single repository contained artifacts in the following categories: 1) JBoss original artifacts 2) Copies of artifacts from other repositories 3) Artifacts with the same coordinates as artifacts in another repository, but that had been patched or otherwise altered

Ideally the repository should have contained only artifacts in category 1. Category 3 is what caused the most pain, because as soon as you pulled some artifacts from the JBoss repo, you potentially could get “polluted” with these altered artifacts.

We worked with the JBoss team to develop tools that could scan the repository, and categorize all the artifacts into the categories described above. Using that information, we where able to separate them into unique repositories in the new Nexus Pro repo, meaning now you can select which artifacts you want to include based on the url you use. Nexus’ ability to logically group repositories allows JBoss to merge these now separated repos back into a view that matches the old repo, making the migration transparent for existing users.

The problem with the java.net repo is more complicated. In addition to all of the problems described above, this repository suffers from a lack of oversight and quality. We found thousands of artifacts that referred to repositories that no longer existed, that contained snapshot dependencies, that weren’t in the proper folders, and so on. This problem has taken one of our developers almost a month to sort out, but it’s finally just about done. These artifacts will be synced into Central, and we are working with Oracle to prepare a Nexus Pro instance that can be the deployment location for these projects going forward.

In addition to the repository cleanup, the JBoss (and soon java.net) projects are now able to use the Staging and Promotion tools in Nexus Pro that are used in many other OSS forges like Apache, Codehaus, Scala-tools, and Terracotta. This allows developers to stage a release, have automated quality checks occur, and perform their voting and validation phase before promoting the artifacts to the public release repository. This process makes it dead simple to ensure that the basic quality of the releases is maintained.  This helps the entire community, which is why we make Nexus Pro available to OSS projects for free.

For projects that are too small, or otherwise don’t want to host their own instance of Nexus Pro, we maintain an instance at http://oss.sonatype.org.  Here, any OSS project can sign up (http://nexus.sonatype.org/oss-repository-hosting.html) and gain all the benefits of a managed repository, including dedicated Sonatype assistance with their builds. We have almost 400 projects using this instance, including Amazon Web Tools, Google App Engine, Google Inject, Jetty, and many more. Users of this system are able to get their releases published to Central in less than an hour, once they are configured to pass the automated quality checks.  It’s never been easier or faster for projects to release their artifacts to Central.

Based on the outstanding adoption rate of our tools in the community, it is clear that project development teams of all sizes really want to provide a quality product for their users in the form of clean artifacts and metadata. This just wasn’t easy to do in the past. Sonatype is making it a priority to empower these projects by providing first class tools and self-serve access to Central.

The Weld framework is an almost perfect case study of how using Archetypes benefits the community by making it easier for new users to get up and running quickly. A member of the Weld community, Steven Boscarine, proposed a Maven 2 archetype in November of 2009, and you can follow the discussion thread where he takes the time to explain the benefits of having an archetype to the community. One month later, the Weld framework has a functioning Maven Archetype which is available on Central, and which will now appear in the Archetype catalogs in m2eclipse and Netbeans.

Three months ago, to get started with a Weld application you likely had to copy and customize an example project from jboss-seam/examples. Today, if you want to get up and running with a basic Weld application, all you have to do is fire up an IDE, and use one of the Weld archetypes. By making it easier to fire up a new Weld project, they’ve increased the potential audience size. People expect to be able to get up and running with a new framework in seconds, they don’t want to stop and read the instructions, and we’ve all been influenced by the immediate ease-of-use of a framework like Ruby on Rails. Maven Archetype provide a similar level of immediacy for a whole array of technologies.

As projects start to use Maven Archetypes, Maven Repository Managers, and tools that can read the Nexus Index format, people are starting to realize that we’ve achieved a more immediate and more efficient way to distribute new frameworks (in this case Weld). This particular story isn’t just about the “build”, it is about the way that this project can publish new archetypes to central, and also how tools like m2eclipse can get an up to date list of available artifacts.

Here’s a quote we’re seeing more and more of as projects start to take advantage of Maven Archetypes:

There is no faster way to get started with CDI and JSF 2 than using these archetypes!

Sonatype’s work on Nexus has helped the industry move toward more integrated, immediate, and efficient systems to support development and distribution. The author of this article thanks Sonatype “for making it so streamlined for OSS projects to publish artifacts to the Maven Central repository with Nexus”.

Read the original article here: “Get Running on CDI & JSF2 in a Jiffy Using Maven Archetypes”