6 ms·

Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish

Too much XML? Seriously though what's a decent Java build tool? Hacking on Gradle means having to learn another PL entirely. Maven? Then say I want to publish a library for others to use from their own java project, how do I do that? I've never actually done it, but that page https://maven.apache.org/repository/guide-central-repository-upload.html https://maven.apache.org/repository/guide-central-repository... seems awfully complicated compared to say https://doc.rust-lang.org/cargo/reference/publishing.html https://doc.rust-lang.org/cargo/reference/publishing.html or even the pip equivalent. Granted, working on a well set up java project is nice, but the setup process is not simple.

paulddraper 3y ago
So you don't like a config language like XML because _____ and you don't like a DSL like Groovy because _____. What is acceptable? P.S. For easier publishing, use a different repo e.g. Artifactory instead of Maven Central.
pjmlp 3y ago
Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.
alex_smart 3y ago
That maven link is perhaps not the most useful, but it is not hard to find better-written articles. For example- https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven https://docs.github.com/en/actions/publishing-packages/publi... The steps are roughly: 1. Configure the repository you want to push to. 2. Set up your account with the repository. 3. Configure your credentials. 4. Deploy.
chriswarbo 3y ago
I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially opaque, with no way of knowing what it will do other than executing it. An example I ran into at work: there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix). SBT provides commands which claim to do that, but config files often append dependencies based on arbitrary logic; e.g. we had some like "when running unit tests, add this mocking plugin"; since "list dependencies" doesn't run the unit tests, that plugin dependency was missing from the sandbox. I can't speak to the "publishing" situation for Java, I don't have any experience with it. All of our projects transparently pushed/pulled via a Nix cache, whether we used Java, Scala, Python, NodeJS, etc.
- Tainnor 3y ago
  > there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix) Well, the same is true for Maven. I know because I've tried. Plugins can download arbitrary dependencies at execution time. That's where the point about Rice's theorem falls apart: it applies as much to maven as to Gradle because maven plugins can do whatever they want.
  - chopin 3y ago
    But that can't be runtime dependencies to your code? I've written a couple of Maven plugins and you must declare your dependencies explicitely even for those. Pulling in stuff dynamically would be possible but not very clever.
    - Tainnor 3y ago
      The maven surefire plugin downloads dependencies dynamically depending on the kind of tests it finds. Is it not very clever? I agree. But it's one of the most popular maven plugins.
      - chriswarbo 3y ago
        That sort of thing is unfortunate, but not too bad since we can add those packages to our own dependency list (e.g. in the pluginManagement section). It's a bit redundant, but as a bonus it ensures that such "dynamic" behaviour is acting as expected (since the build will fail if it picks different packages to the ones we wrote down!) The same approach can be used when depending on third-party jars/plugins which don't fully specify their dependencies: just add the missing ones as extra dependencies of our project. (This happens a lot, where projects have undeclared dependencies on some commonly-used library, and don't notice since it's usually available in a well-stocked ~/.maven2 cache)
      - chopin 3y ago
        During Maven build, sure. But it does not add unknown dependencies to your code at runtime. I am used to classpath problems with surefire but that it downloads undeclared stuff is new to me. Afair it pulls only in transitive dependencies. Could you give an example? I am mainly building war files and it turned out to be good practice to explicitely declare any ambigous transitive dependencies. There's even a Maven plugin which shows up classes with different hash during build, https://basepom.github.io/dependency-versions-check-maven-plugin/release-4.0.0/ https://basepom.github.io/dependency-versions-check-maven-pl...
gmfawcett 3y ago
Yes, Maven. Just embrace it, and move on: the decision will pay dividends.

paulddraper 3y ago

So you don't like a config language like XML because _____ and you don't like a DSL like Groovy because _____. What is acceptable? P.S. For easier publishing, use a different repo e.g. Artifactory instead of Maven Central.

pjmlp 3y ago

Not only do Maven and Gradle support binary libraries (including native code) instead of waiting to build the whole universe on each checkout, their plugins for mixed language development are way better than writing build.rs scripts.

alex_smart 3y ago

That maven link is perhaps not the most useful, but it is not hard to find better-written articles. For example- https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven https://docs.github.com/en/actions/publishing-packages/publi... The steps are roughly: 1. Configure the repository you want to push to. 2. Set up your account with the repository. 3. Configure your credentials. 4. Deploy.

chriswarbo 3y ago

I actually prefer using Maven and its giant XML files: at least they're declarative, and are easily parsed, transformed, generated, etc. by scripts. Most attempted replacements (Gradle, SBT, etc.) stick with largely the same model (i.e. no extra functionality) but use a full programming language for their "config" (Groovy, Scala, etc.). The latter gives us a "config" that's subject to Rice's theorem: it's essentially opaque, with no way of knowing what it will do other than executing it. An example I ran into at work: there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix). SBT provides commands which claim to do that, but config files often append dependencies based on arbitrary logic; e.g. we had some like "when running unit tests, add this mocking plugin"; since "list dependencies" doesn't run the unit tests, that plugin dependency was missing from the sandbox. I can't speak to the "publishing" situation for Java, I don't have any experience with it. All of our projects transparently pushed/pulled via a Nix cache, whether we used Java, Scala, Python, NodeJS, etc.

Tainnor 3y ago
> there's no way to list the dependencies of an SBT project (in order to set up an offline sandbox, in our case for reproducible building with Nix) Well, the same is true for Maven. I know because I've tried. Plugins can download arbitrary dependencies at execution time. That's where the point about Rice's theorem falls apart: it applies as much to maven as to Gradle because maven plugins can do whatever they want.
- chopin 3y ago
  But that can't be runtime dependencies to your code? I've written a couple of Maven plugins and you must declare your dependencies explicitely even for those. Pulling in stuff dynamically would be possible but not very clever.
  - Tainnor 3y ago
    The maven surefire plugin downloads dependencies dynamically depending on the kind of tests it finds. Is it not very clever? I agree. But it's one of the most popular maven plugins.
    - chriswarbo 3y ago
      That sort of thing is unfortunate, but not too bad since we can add those packages to our own dependency list (e.g. in the pluginManagement section). It's a bit redundant, but as a bonus it ensures that such "dynamic" behaviour is acting as expected (since the build will fail if it picks different packages to the ones we wrote down!) The same approach can be used when depending on third-party jars/plugins which don't fully specify their dependencies: just add the missing ones as extra dependencies of our project. (This happens a lot, where projects have undeclared dependencies on some commonly-used library, and don't notice since it's usually available in a well-stocked ~/.maven2 cache)
    - chopin 3y ago
      During Maven build, sure. But it does not add unknown dependencies to your code at runtime. I am used to classpath problems with surefire but that it downloads undeclared stuff is new to me. Afair it pulls only in transitive dependencies. Could you give an example? I am mainly building war files and it turned out to be good practice to explicitely declare any ambigous transitive dependencies. There's even a Maven plugin which shows up classes with different hash during build, https://basepom.github.io/dependency-versions-check-maven-plugin/release-4.0.0/ https://basepom.github.io/dependency-versions-check-maven-pl...

gmfawcett 3y ago

Yes, Maven. Just embrace it, and move on: the decision will pay dividends.