6 ms·

Speaking of tooling, correct me if I'm wrong but one thing I miss when working on Java (I've not worked much on Java) is intuitive and build/package manager.

Speaking of tooling, correct me if I'm wrong but one thing I miss when working on Java (I've not worked much on Java) is intuitive and build/package manager. Java build tools seems to be painful to use outside IDE. Cargo on other hand, I can get started working in minute.

chamakits 11y ago
I have found the opposite to be true in my experience. IDE's have some level of trouble with most popular Java build tools (Maven and Gradle), while they are quite capable command line tools, and they themselves know how to work well with the IDE's (They each have plugins to create the 'meta' files for the most popular IDE's) What issues have you had with which build tool when using it outside the IDE?
- sk5t 11y ago
  Same here. Maven works great from the CLI, and Eclipse works great as a dumb-ish consumer of the dependencies and Maven reactor stuff in which to write code. But I don't use Eclipse for real build / test / package tasks, nor is the IDE a very nice place in which to configure the project skeleton.
- EdwardDiego 11y ago
  IDEA's Maven and Gradle support is pretty good. I haven't had to use any Maven plugins to generate project files for an IDE since IDEA 7. But yeah, mvn and gradle are the definitive, the IDE support is a nice to have.
  - mavelikara 11y ago
    IDEA's native Gradle support is excellent. I haven't had to use Gradle's IntelliJ plugin (the Gradle bit that generates the IDE files) for at least two years now. All I have to do is (on Mac OS X): open -a /Applications/IntelliJ\ IDEA\ 15\ CE.app build.gradle At work, we have a Gradle project with 346 submodules. We have about 200 engineers working on the codebase. Gradle/IDEA combination works well beautifully. There are a few rough edges, especially when one uses custom source sets. IDEA 16 is going to get better support for that [1]. [1]: http://blog.jetbrains.com/idea/2015/12/intellij-idea-16-eap-starts-the-faster-release-cycle/ http://blog.jetbrains.com/idea/2015/12/intellij-idea-16-eap-...
- reitanqild 11y ago
  > IDE's have some level of trouble with most popular Java build tools (Maven and Gradle) Can't speak for gradle but Netbeans has worked excellent with Maven for years. Idea seems to work nicely as well (I haven't used it much for the last few years but my coworker across the table seems to like it with Maven as well.) As for eclipse I haven't used it regularly since 2012 so I don't know.
firebones 11y ago
Package management with Cargo is one reason that the Rust ecosystem will evolve very rapidly. It reduces a lot of friction and makes it easy to test out new libraries and approaches. This will pay off in the long run as the community starts to fill in the gaps. Another underrated part of the Rust ecosystem is their RFC process, the multiple development streams and the six week dot-release iterations.
moonchrome 11y ago
Gradle is the best general purpose build system I've seen, a bit of initial overhead but as soon as you need something more than basics you're very glad it's done the way it is. Not without flaws but better than other "API" build systems I've used (WAF, CMake)
- krotton 11y ago
  I like Gradle too, although I very much recommend having a look at QBS (Qt Build Suite, although unlike Qmake it's not really bound to Qt and can be used for general build scripting). I've used it about a year ago and was really amazed to see what was probably the first sane build tool I've used for years. Of course Gradle is rooted in (yet not limited to) the JVM ecosystem and QBS started as a C++ build tool, so they are not really equivalent, but comparing the ease of use, predictability and the overall impression, QBS beats Gradle by a full grade in my opinion.
- pjmlp 11y ago
  Assuming you have a quad-core and enough GB to spare. I am yet to see Gradle perform as fast as Ant and Maven without fine-tuning and background daemons tricks .
  - avita1 11y ago
    What are these fine-tuning and background daemon tricks? I have yet to see gradle run as fast as ant period.
    - pjmlp 11y ago
      What Gradle advocates present on their sessions about leaving a running daemon, configuring the JVM memory, changing the way the build is done and so on.... Still, the end result is as you say.
- vorg 11y ago
  You do know Gradle uses Groovy as the syntax for its build files, right? The people behind Groovy had a problem a year ago where they were retrenched from their jobs working on Groovy, and haven't found any businesses since then who'll pay them to continue improving Groovy. Gradle doesn't mention Groovy much on its gradle.org website, perhaps out of embarrassment.
guelo 11y ago
No matter what all the other commenters are saying here maven and gradle are awful. Cargo is much more pleasant to use.
- dikaiosune 11y ago
  In my opinion cargo > maven/Gradle > most other build/dependency systems I've used, including setuptools, cmake, and others.
- _asummers 11y ago
  I didn't have terribly many issues with Gradle and consider it pretty good. What about it do you consider awful and how does Cargo solve those issues? What features does Gradle lack that stick out to you in Cargo?
lmm 11y ago
Maven is the best build tool I've used, with any language. You have to really embrace its declarative, convention-over-configuration style, but once you do it's wonderful: just declare the projectId, groupId and version, and any dependencies, and there, you're done.
- sunnyshahmca 11y ago
  I think, SBT is better than Maven. It allows interactive development.
  - lmm 11y ago
    Maven allows interactive development too when using the IDE integration. An IDE is in a better position to have that kind of information and integrate it well (e.g. an IDE can run tests on save without having to watch the filesystem for changes). SBT is not adequately documented, relies too much on symbol-heavy syntax, and allows arbitrary code in build definitions.
    - koide 11y ago
      Symbol heavy syntax as opposed to symbol free xml? Could you elaborate?
      - lmm 11y ago
        XML uses three symbols: <, >, and /. And it's a well-known, documented standard. Looking at the last project I depended on, its build.sbt uses :=, %, %%, /, <+=, <<= (in addition to standard Scala symbols like +=, ++=, ++, =>, <=, >=, which an inexperienced developer wouldn't necessarily realise weren't part of SBT's own syntax). That's not an exhaustive list (I've used :+= and :++= as examples in another thread) and I have no idea where to find one. Heck, I've been a professional Scala developer for 5 years and I have literally no idea what <+= or <<= mean.
        llogiq 11y ago

chamakits 11y ago

I have found the opposite to be true in my experience. IDE's have some level of trouble with most popular Java build tools (Maven and Gradle), while they are quite capable command line tools, and they themselves know how to work well with the IDE's (They each have plugins to create the 'meta' files for the most popular IDE's) What issues have you had with which build tool when using it outside the IDE?

sk5t 11y ago
Same here. Maven works great from the CLI, and Eclipse works great as a dumb-ish consumer of the dependencies and Maven reactor stuff in which to write code. But I don't use Eclipse for real build / test / package tasks, nor is the IDE a very nice place in which to configure the project skeleton.
EdwardDiego 11y ago
IDEA's Maven and Gradle support is pretty good. I haven't had to use any Maven plugins to generate project files for an IDE since IDEA 7. But yeah, mvn and gradle are the definitive, the IDE support is a nice to have.
- mavelikara 11y ago
  IDEA's native Gradle support is excellent. I haven't had to use Gradle's IntelliJ plugin (the Gradle bit that generates the IDE files) for at least two years now. All I have to do is (on Mac OS X): open -a /Applications/IntelliJ\ IDEA\ 15\ CE.app build.gradle At work, we have a Gradle project with 346 submodules. We have about 200 engineers working on the codebase. Gradle/IDEA combination works well beautifully. There are a few rough edges, especially when one uses custom source sets. IDEA 16 is going to get better support for that [1]. [1]: http://blog.jetbrains.com/idea/2015/12/intellij-idea-16-eap-starts-the-faster-release-cycle/ http://blog.jetbrains.com/idea/2015/12/intellij-idea-16-eap-...
reitanqild 11y ago
> IDE's have some level of trouble with most popular Java build tools (Maven and Gradle) Can't speak for gradle but Netbeans has worked excellent with Maven for years. Idea seems to work nicely as well (I haven't used it much for the last few years but my coworker across the table seems to like it with Maven as well.) As for eclipse I haven't used it regularly since 2012 so I don't know.

firebones 11y ago

Package management with Cargo is one reason that the Rust ecosystem will evolve very rapidly. It reduces a lot of friction and makes it easy to test out new libraries and approaches. This will pay off in the long run as the community starts to fill in the gaps. Another underrated part of the Rust ecosystem is their RFC process, the multiple development streams and the six week dot-release iterations.

moonchrome 11y ago

Gradle is the best general purpose build system I've seen, a bit of initial overhead but as soon as you need something more than basics you're very glad it's done the way it is. Not without flaws but better than other "API" build systems I've used (WAF, CMake)

krotton 11y ago
I like Gradle too, although I very much recommend having a look at QBS (Qt Build Suite, although unlike Qmake it's not really bound to Qt and can be used for general build scripting). I've used it about a year ago and was really amazed to see what was probably the first sane build tool I've used for years. Of course Gradle is rooted in (yet not limited to) the JVM ecosystem and QBS started as a C++ build tool, so they are not really equivalent, but comparing the ease of use, predictability and the overall impression, QBS beats Gradle by a full grade in my opinion.
pjmlp 11y ago
Assuming you have a quad-core and enough GB to spare. I am yet to see Gradle perform as fast as Ant and Maven without fine-tuning and background daemons tricks .
- avita1 11y ago
  What are these fine-tuning and background daemon tricks? I have yet to see gradle run as fast as ant period.
  - pjmlp 11y ago
    What Gradle advocates present on their sessions about leaving a running daemon, configuring the JVM memory, changing the way the build is done and so on.... Still, the end result is as you say.
vorg 11y ago
You do know Gradle uses Groovy as the syntax for its build files, right? The people behind Groovy had a problem a year ago where they were retrenched from their jobs working on Groovy, and haven't found any businesses since then who'll pay them to continue improving Groovy. Gradle doesn't mention Groovy much on its gradle.org website, perhaps out of embarrassment.

guelo 11y ago

No matter what all the other commenters are saying here maven and gradle are awful. Cargo is much more pleasant to use.

dikaiosune 11y ago
In my opinion cargo > maven/Gradle > most other build/dependency systems I've used, including setuptools, cmake, and others.
_asummers 11y ago
I didn't have terribly many issues with Gradle and consider it pretty good. What about it do you consider awful and how does Cargo solve those issues? What features does Gradle lack that stick out to you in Cargo?

lmm 11y ago

Maven is the best build tool I've used, with any language. You have to really embrace its declarative, convention-over-configuration style, but once you do it's wonderful: just declare the projectId, groupId and version, and any dependencies, and there, you're done.

sunnyshahmca 11y ago
I think, SBT is better than Maven. It allows interactive development.
- lmm 11y ago
  Maven allows interactive development too when using the IDE integration. An IDE is in a better position to have that kind of information and integrate it well (e.g. an IDE can run tests on save without having to watch the filesystem for changes). SBT is not adequately documented, relies too much on symbol-heavy syntax, and allows arbitrary code in build definitions.
  - koide 11y ago
    Symbol heavy syntax as opposed to symbol free xml? Could you elaborate?
    - lmm 11y ago
      XML uses three symbols: <, >, and /. And it's a well-known, documented standard. Looking at the last project I depended on, its build.sbt uses :=, %, %%, /, <+=, <<= (in addition to standard Scala symbols like +=, ++=, ++, =>, <=, >=, which an inexperienced developer wouldn't necessarily realise weren't part of SBT's own syntax). That's not an exhaustive list (I've used :+= and :++= as examples in another thread) and I have no idea where to find one. Heck, I've been a professional Scala developer for 5 years and I have literally no idea what <+= or <<= mean.
      - llogiq 11y ago