Category Archives: Nexus

Component Lifecycle Management with your Apache Maven Infrastructure


July 5, 2012 By Jason van Zyl

The way software is being developed has changed over the last ten years, it has shifted from companies developing the vast majority of their own software to a software development approach that depends on open source components that are freely available. Today, the vast majority (upwards of 90%) of Java-based applications are assembled from components. Very little of these applications consist of code that companies build internally. The extent to which open source components are being used is not widely known within companies that have thousands of applications and hundreds of thousands of downloads from the Central repository.

In last week’s webinar I discussed the trends we’ve identified and the tools we’ve developed to address this challenge. Tracking down where components come from, managing your application to account for changes in components, and dealing with security and licensing issues that relate to your application’s dependencies is our focus. If you develop software using open source components, here’s a video of my webinar. If you are interested in learning more about our Insight products and starting to keep track of the components you consume, go to http://www.sonatype.com/insight.

Wait… you don’t have a repository manager?


By Tim O'Brien

I’ve seen it all. I really have. The highly paid consultant from a well-known enterprise software vendor who once told me: “I don’t need to use an IDE, I do everything in Notepad.”… all the way to a client that was convinced the best relational database was the one they built in-house (my reaction: really? you can do better than MySQL or Oracle or Postgres? With one developer? I’d like to see this).

You and I work in an industry full of exceptional hubris, and, very often, exceptional ignorance. When I see the development team that doesn’t use an SCM because they are “too complex”, or a $200/hour consultant that whittles away his time in Notepad, it just reminds me that our industry is chock full of oddities. But, what are you going to do? As long as that SCM-less team gets the job done and that Notepad-using consultant delivers, it often makes sense to “let it be” – not everyone can be convinced to make rational decisions about development infrastructure.

Correcting a few Repository Management Myths

Trust me, I’ve tried to convince them all, but there’s something about dev infrastructure that encourages a new level of stubborn-headedness – a resistance to objective reasoning. Take, for example, repository managers. I can’t tell you how many times I’ve heard people appeal to the following myths about repository managers:

  • Myth: “We’re not big enough for a repository manager.” Reality: I’m a team of one for most of the projects I work on, and I rely on Nexus as place to store 3rd-party libraries, and as a way to isolate me from depending on a network. The size of your team has no bearing on the benefits of Nexus. Download it.
  • Myth: “The fact that you need a repository at all is a failure in how Maven is designed.” Reality: Every reasonable tool that manages dependencies downloads artifacts from Central – Maven, Ivy, Gradle. Are you telling me that you want to download all of your dependencies manually and check them into source control? (if so, I’m giving my notice today because that is insane….) Again, invalid excuse, go download Nexus.
  • Myth: “You only need a repository if you are publishing artifacts to it.” Reality: No, the benefits of Nexus as a proxy are huge. You can track your exposure to licensing and security threats, and it gives you a place to control what artifacts people consume.
  • Myth: “Our projects only have three dependencies, I don’t see the benefit.” Reality: Sure, your projects have three direct dependencies, but they likely have transitive dependencies. The problem with dependency management is that tools like Ivy, Gradle, and Maven have made it too easy, no one understands the underlying complexity. In this case, maybe this individual needs Maven training.

I’m drawing a line at repository managers.

If you develop Java-based or .NET-based software and you don’t use a repository manager you might as well just wear a shirt emblazoned with the words: “Doing it wrong and proud of it”. Here are some very basic reasons why you shouldn’t just accept the fact that your group doesn’t want to use a repository manager:

  • You’ll lose your license – Ok, that’s not true, but it should be. Remember, Central is a public resource, it is a service that is made available to benefit everyone, and it is also something that should be conserved. If you run a large development effort with tens, hundreds, or thousands of developers and you just don’t care enough to run a caching proxy, you aren’t being a good citizen of Buildlandia. (No one is going to revoke your Central license, but maybe this will get your attention.)
  • Because it is always better to be informed – While your colleagues may think you only use three artifacts from Central, I promise that if they were to take a closer look, they would notice that the build is pulling in more than that. Do they know about security issues for the components they use? Do they understand that OSS software is released under various licenses? Ignorance of legal obligations in OSS is not a valid defense, so if you suspect that the organization you are working for is flying blind on licensing issues, download a Nexus Professional trial and find out. It is always better to know.
  • Best-practice – In this industry it often pays to invoke this nebulous idea of “best-practice”. Ignore the fact that you’ve tried to make the case using solid reasoning and examples. Make an appeal based on authority. Tell your colleagues and managers that Nexus is used by some of the largest Media companies, the largest international banks, and the most critical government agencies. If you need to make this case, and you are running into problems, send an email to our sales team. We’re here to help you make the case.

Lastly, if you can’t convince your team to use a repository manager. Quit. Ok, just kidding, I’m not telling you to quit (although I can’t say it wouldn’t be a good reason). Maybe I am telling you to quit over this, maybe I’m not. You know what, I probably wouldn’t last very long on a dev team that willfully disregards repository managers.

Nexus OSS switched to the Eclipse Public License: A Clarification and an Observation


June 27, 2012 By Tim O'Brien

While I was discussing a particularly tricky Nexus configuration issue with a power user of Nexus last week I suggested that he write and ship a custom plugin with Nexus OSS. His response, “I’m not going to modify Nexus, it is covered under the AGPL?” Before I corrected him to tell him that Nexus 2.0 switched back to the Eclipse Public License back in February I tried to find out what the AGPL meant to this developer. The results were interesting, but before I get into that reaction, I’d like to take this time to make an unmistakable statement for those of you who missed the switch:

Nexus OSS is covered by the Eclipse Public License Version 1.0

Any questions? I was going to try to use the “blink” tag, but I was told that might be overkill. Basic clarification here is that Nexus OSS has nothing to do with the AGPL. If someone tells you that, point them at the 36 point, red letter announcement in this blog post.

Still not convinced? Take a look at the NOTICE.txt file in the Nexus OSS distribution you just downloaded. You’ll see the following statement:

This program and the accompanying materials are made available under the terms of the Eclipse Public License Version 1.0, which accompanies this distribution and is available at http://www.eclipse.org/legal/epl-v10.html.

If you are looking for more proof, here is an excerpt from Jason’s interview with InfoQ in February:

InfoQ: You recently announced that the upcoming Nexus repository would be licensed under the EPL-1.0 rather than the AGPLv3. What prompted the change of license?

Jason van Zyl: We find that the community is not receptive to the use of the AGPL in general, and we’ve had a few cases with potential contributors unwilling to publicly release their Nexus plugins because of the AGPL. The AGPL is a fairly aggressive license and just hasn’t been around as long as other well known licenses like the EPL. The AGPL tends to make lawyers wary and we don’t want to hinder adoption because of legal concerns. To date we have only had a small handful of plugins contributed to the Nexus project and we hope to encourage more participation from the community and expand the plugin ecosystem by adopting the EPL.

Why was he under this impression? This somewhat problematic comparison matrix had incorrect information until this morning, and I don’t think we made a big deal about the license switch for Nexus 2.0 to the Eclipse Public License Version 1.0 during our launch of the Nexus 2.0 features in February. We were focused on the compelling features we released with Nexus 2.0, but this license switch is a big deal.

After I corrected him, we started talking about what the AGPL really means. He took five minutes to tell me what his corporate lawyers had told him, and I took an equivalent amount of time to tell him what I had heard. The only thing we could agree on about the AGPL was that two different legal professionals had conflicting interpretations of the license with his expressing concern that the AGPL hadn’t been tested in a court. I understood his concerns, and skipped the rest of the conversation, “Well it doesn’t matter, because Nexus OSS is covered by the same license that covers the Eclipse IDE.”

Nexus Pro and Nexus OSS 2.0.6 Now Available: Stability and Security Fixes


June 26, 2012 By Tim O'Brien

We’re pleased to announce the availability of Nexus Professional 2.0.6. This is our sixth update to Nexus 2.0 since February, and this release includes a number of important bug fixes.

  • Nexus Professional Issue #4372 – Nexus running in ‘/’ breaks licensing redirection
  • Nexus Professional Issue #4374 – “upload a license file” link doesn’t work in IE9
  • NEXUS-5096 – Security should cache created WildcardPermission objects, not recreating them over and over again
  • NEXUS-5099 – Memory leak in attributes upgrader when running against virtual M1 -> M2 repo

If you are interested in evaluating Nexus Professional, you can download a 15 day evaluation and get started today. If you are an existing customer looking to upgrade to Nexus Professional 2.0.6 , go to our new Sonatype Support portal at http://support.sonatype.com.

To download Nexus OSS, visit http://nexus.sonatype.org.

How to Consume and Publish Artifacts with Nexus and Apache Ivy


June 21, 2012 By Tim O'Brien

Yesterday we published a Ivy-specific evaluation guide for Nexus Professional, and today we’re diving into the details of how to get Ivy to work with both Nexus OSS and Nexus Pro. Here are some simple Knowledge Base entries from our Support portal that do just that:

As we expand our coverage of build tools and technologies, we’d encourage you tell us which build tools you use for development. Next on our list is covering Nexus integration with Ant + the Aether Ant tasks.