4 ms·

Funny thing is, I have the exact opposite problem to you. I have zero issues with packaging or Nuget in .net land. But I (along with my co workers) are regularl

Funny thing is, I have the exact opposite problem to you. I have zero issues with packaging or Nuget in .net land. But I (along with my co workers) are regularly stuck in hell in java and scala package land. The tooling for java and scala builds is absolutely shit, whether you’re using maven or sbt. It really takes days to on board a new developer into this ecosystem just to get their build system and ide (IntelliJ) working correctly. I’ve never had to do anything like shading with nuget but we regularly have to do it in java world. For personal projects I would never ever use java just because the amount of friction around builds and packaging is so terrible.

mschaef 8y ago
> For personal projects I would never ever use java just because the amount of friction around builds and packaging is so terrible. As a counterpoint, I do tend to use the JVM for personal projects, but I'm also pretty strict about keeping complexity out of the build and deploy process. What that means, practically speaking, is that I compile to uberjars, and deploy as Unix services. I also have a little library that makes it easier to use an embedded in-process database for persistence. There are surely limitations to this approach, but I don't have enough time for my side projects to get to the point where I ever hit them. So I wind up in a spot where I can generally focus on whatever the small goal of the project is.
EdwardDiego 8y ago
That seems odd. I'm particuarly fond of the fact that every Java build tool has accepted Maven's artifacts as the way to do it, whether it be sbt, Buildr, Ivy, Leinigen, Gradle etc. I personally use Maven over sbt for Scala projects though, I much prefer declarative builds to... whatever leaky DSL sbt is rocking. May I ask why you're routinely shading? I only really use shading for deploying Spark jobs onto a cluster I don't control. Otherwise if I'm deploying an executable jar the assembly plugin and jar-with-dependencies does it fine. Have you seen Capsule? http://www.capsule.io http://www.capsule.io
james_s_tayler 8y ago
Ah Maven. It yes, not my favorite tool. You're quite right that by default there is no hand holding by Java itself on the matter and if you have to solve it yourself it's quite a not fun problem the first time you come across it. It bothered me in the early days, but after switching to Spring Boot the problem melted away entirely. If you use https://start.spring.io https://start.spring.io select what you want, hit download and import as a Maven (or Gradle) project and bobs your uncle. Boot automatically builds a fat jar and it just works. Friction drops to zero in that particular configuration. I'm not a fan of Maven either. Before leaving Java land I settled on using Gradle and was much happier with that. Some people don't like that it runs a daemon and uses resources or that builds are custom with it, but I don't mind those things at all and I found it a real breath of fresh air compared to Maven. Another point of difference between native .NET shops and native Java shops that I have found is approach towards development environments. My sample size is small here, but so far I've seen that Java shops run windows, but have development VMs that you can just download an image, drop it into your machine, pull down the repo and the image is pre-configured with all the right stuff to build and develop. Linux natives are heavily into scripting things and the devops usually works quite nice, but I find it also breaks more frequently because it tends to be _somewhat_ brittle. In .NET shops I haven't seen that. It's mostly been they run on Windows and develop on Windows (duh) but that means you have to manually do a bunch of setup and spend a day installing stuff when you start and everyones machine is a tiny bit different. I can't say I've found one better than the other, but if it were me I'd run .NET Core development and do it on Linux in VMs.

mschaef 8y ago

> For personal projects I would never ever use java just because the amount of friction around builds and packaging is so terrible. As a counterpoint, I do tend to use the JVM for personal projects, but I'm also pretty strict about keeping complexity out of the build and deploy process. What that means, practically speaking, is that I compile to uberjars, and deploy as Unix services. I also have a little library that makes it easier to use an embedded in-process database for persistence. There are surely limitations to this approach, but I don't have enough time for my side projects to get to the point where I ever hit them. So I wind up in a spot where I can generally focus on whatever the small goal of the project is.

EdwardDiego 8y ago

That seems odd. I'm particuarly fond of the fact that every Java build tool has accepted Maven's artifacts as the way to do it, whether it be sbt, Buildr, Ivy, Leinigen, Gradle etc. I personally use Maven over sbt for Scala projects though, I much prefer declarative builds to... whatever leaky DSL sbt is rocking. May I ask why you're routinely shading? I only really use shading for deploying Spark jobs onto a cluster I don't control. Otherwise if I'm deploying an executable jar the assembly plugin and jar-with-dependencies does it fine. Have you seen Capsule? http://www.capsule.io http://www.capsule.io

james_s_tayler 8y ago

Ah Maven. It yes, not my favorite tool. You're quite right that by default there is no hand holding by Java itself on the matter and if you have to solve it yourself it's quite a not fun problem the first time you come across it. It bothered me in the early days, but after switching to Spring Boot the problem melted away entirely. If you use https://start.spring.io https://start.spring.io select what you want, hit download and import as a Maven (or Gradle) project and bobs your uncle. Boot automatically builds a fat jar and it just works. Friction drops to zero in that particular configuration. I'm not a fan of Maven either. Before leaving Java land I settled on using Gradle and was much happier with that. Some people don't like that it runs a daemon and uses resources or that builds are custom with it, but I don't mind those things at all and I found it a real breath of fresh air compared to Maven. Another point of difference between native .NET shops and native Java shops that I have found is approach towards development environments. My sample size is small here, but so far I've seen that Java shops run windows, but have development VMs that you can just download an image, drop it into your machine, pull down the repo and the image is pre-configured with all the right stuff to build and develop. Linux natives are heavily into scripting things and the devops usually works quite nice, but I find it also breaks more frequently because it tends to be _somewhat_ brittle. In .NET shops I haven't seen that. It's mostly been they run on Windows and develop on Windows (duh) but that means you have to manually do a bunch of setup and spend a day installing stuff when you start and everyones machine is a tiny bit different. I can't say I've found one better than the other, but if it were me I'd run .NET Core development and do it on Linux in VMs.