7 ms·
I've gotta take beef with the deployment comment, we use Java at my job and the deployment is quite specifically awesome. There is a single package management
by jbooth 13y ago
I've gotta take beef with the deployment comment, we use Java at my job and the deployment is quite specifically awesome. There is a single package management system, maven repositories, and multiple build options using that management system.
But the reason deployment is awesome is because of the nature of shipping an assembled pile of bytecode. You can build an assembly that statically links in all the code you depend on, and bang: You have one jar (or war) file, can run java -cp myjar.jar MyClassName and all of your dependencies have been packed into the jar for you. It's so easy. No management of which dependencies have been installed where.
- barrkel 13y agoIf you specify the right options in the manifest (or configure the maven assembly plugin appropriately) you can reduce it to java -jar myjar.jar. But these megajars have other issues when you need to run in slightly more advanced scenarios, e.g. hosted Akka or Play. It's not hard to end up with multiple versions of the same library on the classpath, and the wrong ones getting chosen.
- saryant 13y agoI use SBT-Assembly with Akka to generate megajars and I haven't had any issues with multiple dependent libraries getting packaged with conflicting versions. SBT-Assembly has a pretty straightforward system for handling conflicts, allowing you to define merge strategies for different files or patterns.
- barrkel 13y agoThe problem with something like Akka Microkernel is that you get multiple megajars for different actors, living in the same JVM, with conflicts in the libraries in the separate megajars.
- doktrin 13y agoI think it helps to look at the scope of the analogies being presented. For instance, the friction of installing & configuring Postgres is compared unfavorably to MySQL. Objectively speaking, those are pretty minor differences (i.e. installing Postgres is easy). However, the point that was being made was that even minor increases in "friction" can negatively impact adoption. No-one is saying Maven / Gradle / Ant are terrible package management systems. However, when compared against tools used in other popular languages (ruby gems, pip, NPM), it's fair to argue that other language's package management systems are more fluid - in that neither of them require prior configuration and work quite well outside of an IDE.
- jbooth 13y agoYeah, that's what I'm disagreeing with. Maven doesn't require an IDE and uses a convention over configuration based approach where it will run against the public repo with zero config. Moreover, it's significantly 'more fluid' due to the ability to ship assembled fat binaries that have all of their dependencies packaged with them. No need to worry about which version of what is installed on this machine.
- doktrin 13y agoI think you glossed over the 'configuration' that adds friction to Maven adoption. Namely, the pom.xml file. You could argue that its complexity is typically overstated, but the fact remains that it exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems. > No need to worry about which version of what is installed on this machine. That's not a concern when using NPM (out of the box), and when using virtualenv it's not a concern when using pip (which most Python devs do).
- deleted 13y ago[deleted]
- karlmdavis 13y ago> the fact remains that it [Maven] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems. Are you saying that when developing in Node, you don't have to interact with npm or other build & deployment utilities? End-users of packaged Java applications don't have to interact with Maven any more than end users of packaged C applications have to interact with Make.
- doktrin 13y agoI was probably not clear. 'It' refers quite specifically to pom.xml, not Maven as a whole. Thus : > the fact remains that it [pom.xml] exists and most developers will have to interact with it at some point or another. That's simply not the case in many other systems. Again, I would like to highlight that this entire discussion should be viewed through the lens of friction vs. frictionless tools, and what that means for community adoption.
- 6ren 13y agoGoing back a step, Java itself is just download, unzip. Oracle actually made it even easier than Sun, by doing the "agree" on the website. But they do lose by not having it in ubuntu/debian.
- dottrap 13y agoIt's not so easy in the corporate world because you need Administrator access to install Java.