What is NuGet? (for Java Developers)
What is NuGet? (for Java Developers)
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Nexus Professional 2.0 supports NuGet repositories, and while you’ll hear much more about that next week I think it’s important to introduce what NuGet is before we introduce you to how Nexus supports it. NuGet and NuGet Gallery is a relative newly way for .NET developers and .NET open source projects to distribute binaries. Nexus provides first-class support for proxying, hosting, and grouping the NuGet package repository format.
Now, I understand that the bulk of our audience is comprised of Java developers, and when a Java developer sees a .NET announcement or feature fly by it’s often met with a shrug. For whatever reason, there’s almost no overlap between Java developers and .NET developers, so I think it’s important to talk about NuGet in terms Java developers can understand. I also think it’s important for people to realize just how interested Sonatype is in spreading the word about NuGet. NuGet and NuGet Gallery remind us of Central, and if you’ve been paying attention to my blog posts in particular, I’m convinced that Central transformed both the way Java developers consume artifacts and the rate at which open source innovation happened over the last decade.
Central created a more efficient “market” that facilitated open source development. With the arrival of NuGet, we think the same thing will happen to .NET. While .NET has and has had a rich set of open source projects for some years, open source isn’t the first thing you think about when someone says .NET. Give NuGet Gallery a few years, and we think that will change.
Differences between the Java and .NET Communities
Get a Java developer and .NET developer in a room, and they’ll either quickly realize that they speak entirely different languages. Where a .NET developer might start rambling off about some nuanced issue in WPF, a Java developer will start to talk about the differences between Vaadin, GWT, and Wicket. But it’s more than just jargon, there’s a whole different culture surrounding both communities. Java’s been a bit more focused on open source (ASF and Eclipse) for the last decade, while the .NET community has only recently started to coalesce around open source foundations like Outercurve. You can be a Java developer, implement enterprise systems, and never pay a single software company a dollar, while, on the other hand, .NET developers are very used to Microsoft driving the community.
There are advantages and disadvantages to .NET and Java. While Java is very diffuse and full of choice, it’s often difficult even for two Java programmers to effectively communicate with one another when there are 30+ viable web frameworks and 10+ viable ORM projects out there. On the other hand, while .NET developers might have fewer open source options for implementing something like a web framework, everyone who does so has immediate access to the best practice ASP.NET approach for something like a browser-based data table. On the other hand, Java appears to be a bit more more “polyglot” than the .NET world. While it is possible to run Ruby, Python and other languages on a .NET platform, my take is that there’s less polyglot activity going on in that community.
Despite the differences, there’s one emerging commonality, both platforms are converging on the reality that open source components play a critical role in all development efforts.
Common Open Source libraries Emerging and Maturing
There are a few projects out there that have always had a presence in both worlds. While NHibernate isn’t nearly as popular as Hibernate, and while NUnit does seem like a derivative of JUnit, you are seeing open source emerging as an important component of any company’s approach to .NET development. This is where NuGet and NuGet Gallery are going to have long-term effects on the .NET community.
It’s already happening, just as a Java developer expects access to Central as a prerequisite for any development environment, .NET developers are starting to rely on having access to NuGet Gallery from Visual Studio. Once you are used to having access to that huge library of components (in either Java or .NET) it’s inconceivable to go back. Unlike Central, NuGet isn’t yet a universal component. The .NET developers I work with know of it, but it hasn’t been something they’ve adopted at work yet. That being said, every .NET developer I know is planning on starting to use it to consume public packages from the NuGet Gallery.
Once it because a universal in .NET development efforts, more and more companies will start to deploy internal NuGet packages and more and more open sources projects will have an incentive to deploy to NuGet Gallery. Like the rapid emergence of Central for Java development, this transition happens very quickly. It is something of a feedback loop of efficient software distribution. The very success of a central repository increases the rate of adoption and the incentive to contribute to it.
Where Nexus can Help
Nexus and the capabilities it provides have been informed by Sonatype’s stewardship of Central. Many of the features and support we’ve added into the core project are there because we’ve had to work with the largest customers in the world and come up with bullet-proof approaches to security, staging, and procurement for binary artifacts. Sonatype’s convinced that Nexus’ support for NuGet will help customers new to the concept of repository management for .NET adopt some of these best practices that the Java community has perfected.
In the process, we’re hoping that Nexus’ cross-platform support for both .NET and Java helps facilitate more collaboration between these two disparate groups. In the past, a company’s .NET development efforts have been isolated from Java development efforts. Going forward, we expect companies to start using our NuGet support alongside our established support for Maven repositories creating opportunities for these now separated development groups to start talking about common best practices for things like staging, releases, and artifact selection.
We’re convinced that the power of sharing binary artifacts with a local repository manager is something that transcends either platform.
Opinions expressed by DZone contributors are their own.