3 ms·

I think I already mentioned why Linux distros build the entire chain from source: they provide support for it, they need to be able to patch it and they can't t

I think I already mentioned why Linux distros build the entire chain from source: they provide support for it, they need to be able to patch it and they can't take responsibility for binaries built in an unknown environment. However, I don't understand why you mix two things: maven concept and design (which is fine) with what I criticized: a build tool that depends on everything that it intends to build in the first place.

hrjet 12y ago
Bootstrapping any tool is going to look that way. To compile gcc you need a C compiler don't you?
- dmacvicar 12y ago
  Yes, but gcc requires gcc and THAT is. gcc does not require KDE and apache to build (which is like Maven dependency chain looks like).
  - hrjet 12y ago
    You probably are angry at the "length" of the dependency chain, but I see no conceptual difference between the two bootstrapped tools. Of course, I am looking at this far from the battle-field, so maybe I am being too non-chalant.
mike_hearn 12y ago
So Maven is at fault because they prioritise their own development productivity over ..... Linux distributors? Why package Maven anyway? You aren't likely to add much value by doing that.
- dmacvicar 12y ago
  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.
  - mike_hearn 12y ago
    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.
    - dmacvicar 12y ago
      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)

hrjet 12y ago

Bootstrapping any tool is going to look that way. To compile gcc you need a C compiler don't you?

dmacvicar 12y ago
Yes, but gcc requires gcc and THAT is. gcc does not require KDE and apache to build (which is like Maven dependency chain looks like).
- hrjet 12y ago
  You probably are angry at the "length" of the dependency chain, but I see no conceptual difference between the two bootstrapped tools. Of course, I am looking at this far from the battle-field, so maybe I am being too non-chalant.

mike_hearn 12y ago

So Maven is at fault because they prioritise their own development productivity over ..... Linux distributors? Why package Maven anyway? You aren't likely to add much value by doing that.

dmacvicar 12y ago
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.
- mike_hearn 12y ago
  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.
  - dmacvicar 12y ago
    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)