Hacker News new | past | comments | ask | show | jobs | submit login

I think what you call "development productivity" shows exactly the cancer that makes the Java ecosystem a spaguetti of jars (whith some of them being dead projects) instead of a lasagna where you see libraries use only other libraries from the layer "below".

But not, it is the obsession to turn everything into agnostic "engines" and meta-somethings, where everything is abstracted to the extreme with little value. At the end, Maven implementation using XML, plugins, dependency injection and having a build dependency chain of 100 packages did not prevent them from being kind of stuck in version 3 and slowly abandoned for another tool (gradle), leaving behind the only important value: conventions and the repository concept.

I can build/bootstrap ant and ivy just fine. And I can build almost every package using it by just telling them, don't go to the network, but use the one I already built myself with little effort.

If you ask why maven had to be packaged, mostly because it had to be patched with ugly hacks.




Well, there's exactly the reason I try and avoid distributor packaging as much as possible and prefer to use Maven from upstream. Not only is it much simpler but it means it's not being patched with "ugly hacks" by people who dislike the project. Sorry, Debian proved multiple times that this whole arrangement is a recipe for disaster. Maven is convenient and fast, I think I'll stick with it for now.


So what do you do if you realize one of your dependencies has a very bad security issue that will not be fixed upstream for a while and you need to fix it and ship an update to the customer? (or the same example with a crash bug in one jar, and you can't workaround it)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: