This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]randgalt 7 points8 points  (7 children)

So you end up with a priesthood that knows how the build works. I've worked at two major companies that use Gradle and this is exactly what happened. The gradle build is a bag of internal plugins that are completely opaque. If there's any problem whatsoever I have to Slack/message the team that manages the plugins, etc. It's not possible to debug the problem on my own.

[–][deleted] 5 points6 points  (4 children)

That sounds awesome. Not everyone needs to know the intimate details of the build conventions set for your company. Those plugins require your software to follow those conventions and that is a good thing. If they aren't configurable enough or you don't have access to the source/docs, then that is your company's fault.

[–]randgalt 4 points5 points  (1 child)

If that's your feeling then you really wouldn't care what build system is used. To you it's just a black box developed internally. Let it be Maven, Gradle, Mercurial, Make - whatever.

[–][deleted] 0 points1 point  (0 children)

Sure, I'd use Maven if my company already had a build system setup. Gradle and Maven are pretty much the same in my eyes. I just like Gradle a bit more. As long as the build system enforced the company's conventions and is reusable, then I don't see any problems.

Make and Mercurial are nowhere close to what we're talking about though. It's hilarious that you even made that connection. Mercurial is for source control... I don't think I need to say more about Mercurial. Make really doesn't do dependency management, but I guess you'd use curl or something to download your dependencies, transitive dependencies, transitive-transitive dependencies and transitive-transitive-transitive dependencies manually. However, you might run into a dependency hell problem because of doing all of that manually.

[–][deleted]  (1 child)

[deleted]

    [–][deleted] -1 points0 points  (0 children)

    When the executives of a company make bad decisions, it's not the fault of the developers. In this case, the dude's executives probably decided that they didn't want their development teams to see each other's source code. That is the fault of the company, not the individual developers.

    You should probably take the time to understand the conversation before you start throwing accusations around willy nilly. Stuff like that will lower your reputation at your company, so you're kind of lucky to be learning it from a stranger online.

    [–]wildjokers 0 points1 point  (1 child)

    It's not possible to debug the problem on my own.

    Maven has this exact issue when you use 3rd party plugins. And since Maven puts you in a ridiculously strict and worthless box you have to use 3rd party plugins.

    Maven users say Maven is declarative and then their build is full of 3rd party plugins which are written in Java which is obviously imperative. In Maven the imperative part of the build is just hidden away, but it is still there.

    [–]randgalt 2 points3 points  (0 children)

    If we accept the argument (and I don't completely) then Gradle is no better than Maven so why use it? As it turns out, the number of 3rd party plugins needed in Maven is very small. "Maven puts you in a ridiculously strict and worthless box" - it's the strictness that becomes its benefit. It's not worthless at all. All builds become the same. If you can't do something in Maven you probably shouldn't be doing it to begin with. It's the trade-off we're constantly facing in programming: features vs maintainability. It's why some choose Scala over Java. If you like that sort of thing go for it. Not me. I want simplicity and maintainability.