Sonatype Blog
Posts by Brian Demers

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.

(more…)

The latest release of Nexus, 1.8.0.1 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:

https://repository.sonatype.org/content/repositories/third-party/org/apache/maven/mercury/mercury-md-shared/1.0-alpha-6-SONATYPE/mercury-md-shared-1.0-alpha-6-SONATYPE.jar

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.

(more…)

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. (more…)

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. (more…)

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.

(more…)