> 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!)

> TX

Reply via email to