<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

Sonatype Blog

Stay updated on the latest news from the makers of Nexus

Brian Demers

Recent Posts by Brian Demers:

Goodbye SVN, Hello Git

We are moving both our public and private source repositories to Git for a few reasons:

  • Git works better for people with slow or lagging connections
  • Branch management is easy
  • Submitting patches via a pull request is easier to deal with than a patch attached to a bug report

We started out with SVN mostly because that was what everyone was used to. A year ago or so, one of our remote developers started using a git-svn mirror to remove some of the latency issues they had with SVN. Someone else put together a ten page wiki on how to easily use a git-svn mirror and push back to the canonical SVN repo. As time went on, interest in git grew and new modules were created in git, instead of our SVN repositories. Finally there was a push to move everything to git.

Nexus functionality and fixes

The latest release of Nexus, has been released. In this blog post you will find some of the new functionality and fixes. Click here to download the latest version of Nexus.

64bit Windows Wrapper Support

JIRA Ticket: https://issues.sonatype.org/browse/NEXUS-3844

We have compiled the 64 bit windows libraries for jsw 3.2.3 and now include them in our distributions of Nexus.

Maven 3 Metadata

JIRA Ticket: https://issues.sonatype.org/browse/NEXUS-3806

Maven 3 generates Maven-metadata with extra content that prior versions of Nexus wouldn't accept. Nexus now handles this metadata change, without complaining.

Also, if you find yourself stuck on an older release of Nexus for some particular reason, you can download this patched jar file to make your Nexus (back to version 1.3.6) work with Maven 3 deployed metadata:


Simply install this jar file in (install-dir)/runtime/app/nexus/lib

Make sure to remove the existing mercury-md-shared-1.0-alpha-6.jar file.

Nexus Pro 1.5.0: LDAP Failover, Federation, Performance, and Admin Tools

Last week we announced that we moved LDAP integration from Nexus Professional to Nexus Open Source in the Nexus 1.5.0 release. While we open sourced our LDAP plugin in 1.5.0, we also released an Enterprise LDAP plugin which provides features such as configurable caching, timeouts, templates, and the ability to interact with more than one LDAP server. In this post, I'm going to summarize the differences between Nexus Open Source's LDAP integration and Nexus Professional's LDAP integration.

Repository Manager LDAP Feature comparison

Before we dive into the details of the Enterprise LDAP support in Nexus Professional 1.5.0, here's a comparison of LDAP support in Nexus Professional 1.5.0, Nexus Open Source 1.5.0, Archiva, and Artifactory. If you are trying to decide between Nexus Open Source and Nexus Professional, the difference between the LDAP functionality in each is that Nexus Professional's Enterprise LDAP support adds more features one would expect to see in a mission-critical environment with multiple LDAP servers.

Nexus 1.5.0 Highlights: Open Sourcing Nexus LDAP Integration

With the 1.5.0 release of Nexus, Sonatype is opening up the current LDAP features in Pro, and making them a part of Nexus Open Source. Starting with this release, Nexus Open Source users will be able to integrate with LDAP, Active Directory, and Atlassian Crowd servers (via LDAP). Nexus is the only repository manager with both Authentication AND Authorization (group / role mapping) via LDAP and now this integration is free for all to use.

As we transition this feature to Nexus Open Source, we are also announcing a new Nexus Enterprise LDAP plugin that will support more advanced deployment use cases including support for federated LDAP servers and more intelligent caching of authentication information.

Nexus Tips: Disable Redeployment in Nexus

It's a fundamental tenet of Maven that release artifacts never change once they are released. This is enforced in Maven by the fact that once a release artifact or POM is located in the local repository, Maven will never check for an updated artifact in a remote repository. Once an artifact is released, it is considered a static, unchanging artifact. If you release an artifact and then subsequently change it (intentionally or otherwise), you're in for some fun as people will have different versions based on when they first retrieved it... that's a situation not exactly conducive to a repeatable, standard build. This blog post discusses a feature in Nexus 1.4 which can enforce this rule and help you avoid problems caused by the redeployment of release artifacts.

Using Staging Repositories for Deployment in Nexus

For a number of reasons you might want to require your developers to use a staging repository. Staged software releases in Nexus Professional are the best way to enable your development team to push a release to an artifact repository such as Nexus while providing management and quality assurance with a way to test and approve a release before "burning" it to production. If you want to learn how to make a staged release, you can watch this video. or read the remainder of this blog post.

Plexus Container Five Minute Tutorial

The goal of this blog is to show an updated and more involved example then what is currently located on the plexus site. This will cover creating a couple of components and explain the different ways to inject your dependencies. This example assumes you are using maven 2 to make your life easier.