4 ms·

I find this is not Java specific and many of those other technologies have similarly painful project config, especially as soon as you do something non-triv

by saulrh 9y ago

I find this is not Java specific and many of those other technologies have similarly painful project config, especially as soon as you do something non-trivial. My experience with Java has indicated that the problem is actually in the opposite direction. I agree that all packaging systems suck for larger or unusual projects, but for small stuff there's a clear distinction - there is nothing in Java packaging that's trivial. Or you could see it as "nontrivial" being very different for different toolchains. If I'm doing something that'll never exceed 1KLOC and doesn't depend on any exotic libraries, I can throw together a crate, module, bundle, package, etc in a matter of minutes and then forget about project configuration. Java... anything other than "local-machine CLI project with no dependencies and an IDE" will have you spending more time on config than code.

bennofs 9y ago
I find it's pretty straightforward using gradle (except that it doesn't build fat jars out of the box). Can you elaborate on what you're having trouble with?
- saulrh 9y ago
  I didn't try gradle and my experiences weren't incredibly recent (three-five years in most cases), so maybe that's what I was missing. Dependencies and portability were by far the biggest issues. eclipse, netbeans, idea, et al didn't seem to do dependencies at all; even if you had a library jar actually on your filesystem it was a huge PITA to point at it, and getting a project that'd also compile on someone else's machine was horrible. leiningen didn't have a single tutorial that I could find and I voodoo'd my way through a clojure tutorial before giving up. maven broke in strange ways when I tried pulling in deps and figuring out the correct incantations in the pom files was a pain. More recently, I could probably have gotten along with sbt if I'd had a week to play with it, but it also has the "no useful tutorials" problem and I was on a time limit. Some of this is certainly lack of experience, or even simple Doin It Rong. I could see maven being much easier with a directory full of examples to look at, for example, and sbt I'm sure is great once you wrap your head around it. I just feel like, even if I was limited by typing bandwidth instead of figuring-things-out bandwidth, those tools wouldn't hold a candle to python's or rust's tooling. Even makefiles and cmake seem to have better happy paths. I'll look at gradle next time. There are situation where I could use a jar.
  - lmm 9y ago
    > eclipse, netbeans, idea, et al didn't seem to do dependencies at all; even if you had a library jar actually on your filesystem it was a huge PITA to point at it, and getting a project that'd also compile on someone else's machine was horrible. These things are oriented towards working with a dependency management/project management thing rather than manually specifying libraries. I'd really recommend maven, using the IDE's integration with it, particularly if you're getting started - Gradle can be more concise but it's definitely buggier and less well documented/supported. > maven broke in strange ways when I tried pulling in deps and figuring out the correct incantations in the pom files was a pain Dependencies should just work unless you were trying to do something weird like using jars from the local filesystem - don't do that (if you really must, install them into the local maven repository and use them from there: https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html https://maven.apache.org/guides/mini/guide-3rd-party-jars-lo... ). You shouldn't need any incantations, just simple XML that should autocomplete in the IDE, or you can use a GUI rather than directly - e.g. in eclipse you just right click on the project -> maven -> add dependency, and search/select the library you want. Do you remember what problem you had more specifically? > Some of this is certainly lack of experience, or even simple Doin It Rong. I could see maven being much easier with a directory full of examples to look at, for example, and sbt I'm sure is great once you wrap your head around it. I just feel like, even if I was limited by typing bandwidth instead of figuring-things-out bandwidth, those tools wouldn't hold a candle to python's or rust's tooling. Even makefiles and cmake seem to have better happy paths. SBT is awful throughout, but my experience is that Maven is much much better than anything in Python-land (no messing around and mode switching with virtualenv, no need to separately run pip, one consistent tool that everyone uses, one packaging format, one central repository, better integration of testing with the project), and directly comparable to Cargo.
pabl0rg 9y ago
If you've got a tiny project and are willing to use Kotlin on JRE 9, Kscript is a good option
danjoc 9y ago
I can start one of thousands of pre-configured projects instantly from maven central's archetype catalog (http://repo.maven.apache.org/maven2/archetype-catalog.xml http://repo.maven.apache.org/maven2/archetype-catalog.xml). I don't even have to know what I'm doing to get a karaf-camel-amq-archetype or aws-lambda-s3-example project up in seconds. Java tooling is just so amazing. How do I get a preconfigured quickstart project for say iron and diesel with rust? I read the rust book. I must have missed it.
- steveklabnik 9y ago
  > How do I get a preconfigured quickstart project for say iron and diesel with rust? I read the rust book. I must have missed it. The book doesn't cover everything. That said, we currently don't have a built-in solution for this feature; we had one but it never hit stable. Since it didn't get accepted before the impl period late last year, the discussion was effectively on-hold; it can get started up again now that it's past the new year. That said, many projects provide their own way to get started. Diesel's CLI has a "diesel setup" command to get going with it, for example. I'm not aware of one for Iron.
  - danjoc 9y ago
    Thanks for the reply Steve. I enjoyed v1 and v2 of the book. I look forward to having a standardized way to do this in rust.
- tdbgamer 9y ago
  Iron and Diesel are pretty new, so they may not have very sophisticated templates yet. If you just mean setting up a rust project though it's as simple as 'cargo new --bin [project_name]'. I've found cargo to be a lot simpler to use than Gradle with the added bonus of not having to learn Groovy!

by saulrh 9y ago

bennofs 9y ago

I find it's pretty straightforward using gradle (except that it doesn't build fat jars out of the box). Can you elaborate on what you're having trouble with?

saulrh 9y ago
I didn't try gradle and my experiences weren't incredibly recent (three-five years in most cases), so maybe that's what I was missing. Dependencies and portability were by far the biggest issues. eclipse, netbeans, idea, et al didn't seem to do dependencies at all; even if you had a library jar actually on your filesystem it was a huge PITA to point at it, and getting a project that'd also compile on someone else's machine was horrible. leiningen didn't have a single tutorial that I could find and I voodoo'd my way through a clojure tutorial before giving up. maven broke in strange ways when I tried pulling in deps and figuring out the correct incantations in the pom files was a pain. More recently, I could probably have gotten along with sbt if I'd had a week to play with it, but it also has the "no useful tutorials" problem and I was on a time limit. Some of this is certainly lack of experience, or even simple Doin It Rong. I could see maven being much easier with a directory full of examples to look at, for example, and sbt I'm sure is great once you wrap your head around it. I just feel like, even if I was limited by typing bandwidth instead of figuring-things-out bandwidth, those tools wouldn't hold a candle to python's or rust's tooling. Even makefiles and cmake seem to have better happy paths. I'll look at gradle next time. There are situation where I could use a jar.
- lmm 9y ago
  > eclipse, netbeans, idea, et al didn't seem to do dependencies at all; even if you had a library jar actually on your filesystem it was a huge PITA to point at it, and getting a project that'd also compile on someone else's machine was horrible. These things are oriented towards working with a dependency management/project management thing rather than manually specifying libraries. I'd really recommend maven, using the IDE's integration with it, particularly if you're getting started - Gradle can be more concise but it's definitely buggier and less well documented/supported. > maven broke in strange ways when I tried pulling in deps and figuring out the correct incantations in the pom files was a pain Dependencies should just work unless you were trying to do something weird like using jars from the local filesystem - don't do that (if you really must, install them into the local maven repository and use them from there: https://maven.apache.org/guides/mini/guide-3rd-party-jars-local.html https://maven.apache.org/guides/mini/guide-3rd-party-jars-lo... ). You shouldn't need any incantations, just simple XML that should autocomplete in the IDE, or you can use a GUI rather than directly - e.g. in eclipse you just right click on the project -> maven -> add dependency, and search/select the library you want. Do you remember what problem you had more specifically? > Some of this is certainly lack of experience, or even simple Doin It Rong. I could see maven being much easier with a directory full of examples to look at, for example, and sbt I'm sure is great once you wrap your head around it. I just feel like, even if I was limited by typing bandwidth instead of figuring-things-out bandwidth, those tools wouldn't hold a candle to python's or rust's tooling. Even makefiles and cmake seem to have better happy paths. SBT is awful throughout, but my experience is that Maven is much much better than anything in Python-land (no messing around and mode switching with virtualenv, no need to separately run pip, one consistent tool that everyone uses, one packaging format, one central repository, better integration of testing with the project), and directly comparable to Cargo.

pabl0rg 9y ago

If you've got a tiny project and are willing to use Kotlin on JRE 9, Kscript is a good option

danjoc 9y ago

I can start one of thousands of pre-configured projects instantly from maven central's archetype catalog (http://repo.maven.apache.org/maven2/archetype-catalog.xml http://repo.maven.apache.org/maven2/archetype-catalog.xml). I don't even have to know what I'm doing to get a karaf-camel-amq-archetype or aws-lambda-s3-example project up in seconds. Java tooling is just so amazing. How do I get a preconfigured quickstart project for say iron and diesel with rust? I read the rust book. I must have missed it.

steveklabnik 9y ago
> How do I get a preconfigured quickstart project for say iron and diesel with rust? I read the rust book. I must have missed it. The book doesn't cover everything. That said, we currently don't have a built-in solution for this feature; we had one but it never hit stable. Since it didn't get accepted before the impl period late last year, the discussion was effectively on-hold; it can get started up again now that it's past the new year. That said, many projects provide their own way to get started. Diesel's CLI has a "diesel setup" command to get going with it, for example. I'm not aware of one for Iron.
- danjoc 9y ago
  Thanks for the reply Steve. I enjoyed v1 and v2 of the book. I look forward to having a standardized way to do this in rust.
tdbgamer 9y ago
Iron and Diesel are pretty new, so they may not have very sophisticated templates yet. If you just mean setting up a rust project though it's as simple as 'cargo new --bin [project_name]'. I've found cargo to be a lot simpler to use than Gradle with the added bonus of not having to learn Groovy!