If I one day decide to write a tech book (what kind of stupid idea is that? :>), it’ll definitely be a package manager related one … Obviously, I’m kidding here, but keeping in mind all the "perilous adventures" and "breathe-taking twists" I’ve (and my co-workers) been through, this could be a thrilling story ("In a maw of NuGet!").
It would start with not-that-recent VS2008 times, before NuGet appeared (known then by the name of NuPack) - it may seem unthinkable, but until 2010 (!) there was no tool for that in .NET world. Some smart people at my then-client had some interesting vision about how it should look like and what is more, they were capable of shaping it into working product. Kudos to them.
Few years have passed, NuGet has appeared, got included in Visual Studio by default and has got widely adopted, but we are still struggling with the most basic ideas ever:
- What if I have a solution large enough, that I prefer to separate particular projects into solutions, but I’d like them to share some artifacts : contracts, commons or just utility libraries?
- What if those shared artifacts change on daily basis and I don’t want to maintain several versions of those in the same time …
- … or to force developers to bump up version numbers each build
This is a very basic (and obvious) scenario, quite typical for a large-scale project. Believe or not - it hasn’t been properly dealt with by Microsoft yet. We’ve went through any product available (including platform-agnostic ones) and finally, in the end we’ve found an overlay over NuGet that seems to play its role properly (https://github.com/DarthFubuMVC/ripple), but some bad taste has definitely remained.
I definitely have to how this scenario would fit in Java world: would Gradle / Maven / Ivy / SBT deal with that properly or not?