3 ms·

Yeah, 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 publ

by jbooth 13y ago

Yeah, 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 ago
I 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 ago
    I 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.

by jbooth 13y ago

doktrin 13y ago

I 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 ago
  I 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.