> On Oct 12, 2016, at 7:40 PM, Trejkaz <trej...@trypticon.org> wrote: > > On Wed, Oct 12, 2016 at 7:02 PM, Antoine Toulme <anto...@toulme.name> wrote: >> Good job Michael, I look forward to using the lock_jar gem in my projects. >> >> Trejkaz, is lock_jar covering your use case? > > It does appear to and will be something I'll investigate. I'll also go > digging for whether the similar plugins for Gradle will give us a > similar result. > >> I hate non-reproducible builds and semver-relaxed dep-of-the-dep issues, but, >> while a broken dep fails the build for lots of people (downside), the upside >> of this >> is that very quickly (within hours of a new dep being published) there will >> be lots >> angry people complaining about it on GitHub, and a faulty dep will be >> typically >> quickly rolled back / superseded with a patch. Otherwise, some bugs might be >> sitting hidden for a long time. > > What we find is that obscure broken dependencies are not found > immediately after the commit. Most of the time, they are not even > found before release, or during testing. They are found the first week > after release, or in some cases, 2 months after release, when it can > do the most damage. > >> When Maven came about, it’s biggest value-add compared to Ant or makefiles >> was that it made builds reproducible. > > Not true. What Maven actually did was to bring non-reproducible builds > into the mainstream. > > Ant builds were *very* reproducible, because the only easy way to get > your dependencies was to check in your jars. And although it's true > that the repository is also external, if you have corruption in that, > you're pretty much screwed, no matter which build tool you want to > use. Fair enough. > > But using Maven, if we want to use a library, we're supposed to get it > from an "artifact server". These servers can give you different data > for two identical requests a few minutes apart, without you even > changing anything in your code. I have even *seen* our artifact server > at work doing that while we have been using Gradle, which is no better > than Maven in this regard. > > Sometimes, someone will try to gloss over this problem by saying > things like, "but the local cache will ensure that two builds will be > the same!". This is ridiculous as well, because other people who build > your software don't have the same cache as you. Different members of > the team have different caches. Different slaves within the build > cluster for the same team don't even share the same cache. So I can > only assume people who make that sort of claim are working on toy > projects with one developer, where one computer can still build > everything they make in a reasonable time frame. Or perhaps they don't > write any tests, thus making their builds fairly fast. I’ve seen this happen with snapshots, but not with release builds. We banned snapshots at $work. > > So basically, with Maven, we can't even have a *truly reproducible > build*, as long as there is at least one dependency. > > Remind me again, though, what *did* Maven improve exactly? It has > never really been clear to me. Every time I check out a project from > somewhere and try to run the Maven build, it has failed to build. That is very far from my experience, contributing to various Apache, Eclipse and other projects. I welcome you to read the blog post that the original committer wrote when announcing Buildr (2007!) http://web.archive.org/web/20070427081228/http://blog.labnotes.org/ <http://web.archive.org/web/20070427081228/http://blog.labnotes.org/>
> > TX
