6 ms·

I like how, last I checked anyway, there was no way to say "install this package" with Gradle; I had to go get the URL first. There might have been a way to do

I like how, last I checked anyway, there was no way to say "install this package" with Gradle; I had to go get the URL first. There might have been a way to do it after first manually adding a repository (maven central or whatever), but I couldn't figure it out quickly. And then to upgrade to the latest I had to manually go figure out what the latest was, and manually change the line number to the latest version. I did see there's a separate plugin you can install to now add it though, built by a third party, but still. Decades.

stickfigure 5y ago
I don't understand your first bit, "install this package" isn't a thing in the java world. There are just dependencies, you don't "install" them. But this: > And then to upgrade to the latest I had to manually go figure out what the latest was Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick.
- egeozcan 5y ago
  NPM has had package locking since what feels like a million releases. I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.
  - catdog 5y ago
    https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...
    - egeozcan 5y ago
      I wasn't arguing that gradle didn't have such a mechanism but thanks :)
  - Larrikin 5y ago
    I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.
    - egeozcan 5y ago
      npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that. It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
      - gkop 5y ago
        The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke. [0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
        egeozcan 5y ago
        If you have a package.json and you run npm i it generates a package-lock.json from it. If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions. If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above. But of course you may think this behavior is a joke, I do not.
        gkop 5y ago
        How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
- NateEag 5y ago
  > Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick. I've been writing JS with npm locked to specific, exact versions of dependencies since 2014, IIRC. Not everyone does this, obviously, but the tooling has been able to at least do a decent approximation of this for a long time (and I was and am very far from being a bleeding-edge adopter).
- Aeolun 5y ago
  > There are just dependencies, you don't "install" them Pray tell me where the dependency comes from then? When I add a ‘This package requires dependency x at version y’ to my gradle/maven file, it doesn’t magically appear on my system. Or rather, I think it does magically appear on my system, which is incredibly confusing.
  - kaba0 5y ago
    It downloads it into cache for the first time and uses it at compile time at every subsequent build? How is it magical? Should it display ads instead and put random executables to my path? Or create a 1000000 file directory everywhere on which windows god damn chokes to open?
  - jeroenhd 5y ago
    The dependency comes from the list of repositories you provide. Even in nodejs you don't manually enter the full URL to an NPM package. You just yarn add node-ipc==10.1 and your tooling will figure it out on its own. If you enable the general maven repository (the maven() you see at the top of many gradle build scripts), you'll get the code from maven. If you also add your personal repositories (which most people probably don't have), you'll get packages from there as well. I'm not sure how you add a second repository to node package managers, but I assume it's possible in some way without specifying the http download url. The biggest difference between the two ways of package management in my opinion is that node packages are just a word or two and Java packages are a full com.example.product.service.package name. That's a lot better in my opinion as it distinguishes between projects much more easily. I thought node-ipc was related to the nodejs project, for example. Some nodejs packages use namespaces, but most don't. Another difference is that nodejs has tons of tiny packages (I'll never get over how silly it is that is-odd and is-even appeared in my node folder by transitive dependencies) whereas the Java world generally uses huge packages almost exclusively. This leads to more boilerplate code (actually having to write simple functions like that yourself), but also to less dependencies that can break.
- kaba0 5y ago
  To add, gradle also has dependency check as a feature which will show possibly out of date packages.
- lostcolony 5y ago
  Okay - "Download and make this package available to my code", if that makes you feel better. "npm install (dependency name)" will 'download and make this package available to my code' from the NPM repository, for the current node project you're in. I can also specify custom repos to use, rather than NPM, if so desired. Gradle's default is "nah, go find the fully qualified URL package name and version number for me and paste it in the gradle build file for me, in the right location". Once you do that in Node, the package lock will specify what version you've downloaded, to make it a repeatable build. You can tweak it to indicate you want to pin the version at a given levels, as well; that's done in one place, and separately from the package-lock file that gets generated, that tells you what -actually- is being used. My follow up point is that when that version eventually goes stale, it's as simple as 'npm outdated' to determine if there's something more recent, and 'npm update' to update everything (based on whether you've pinned to a major/minor in your dependency list). You can also update specific packages with 'npm update (package name)'. I sure wish the Java community would learn this obvious 'trick' that every OS package manager enables. I know I want Jackson, say, I should be able to say "gradle install jackson" or whatever, and it would tell me all the options in the repo with jackson in the name. Then 'gradle install jackson com.fasterxml.jackson.core' and it would add that to my gradle file, with the most recent stable version. And 'gradle update jackson' would seek to update that dependency to the latest stable (with some syntax to pin the release, major, and maybe the full version, to enable 'gradle update' to update everything within a particularly defined scope).
MrDresden 5y ago
This honestly sounds like you not knowing the tool, rather then the tool not having the capabilities.
- lostcolony 5y ago
  Could be! Given that I've been across multiple Java shops, including with people who have been in the Java ecosystem for decades now, and I've never had anyone point out how to do this, and in fact seen those self-same people work around these perceived limitations, I doubt it. But it's quite possible the functionality is there, just so buried no one knows about it. Certainly, I haven't seen a response, yours included, that explains how to do it.
  - MrDresden 5y ago
    Alright, I'll bite. With dependency management being 1) and the update flow being 2). 1.1) Gradle is a build system. As such it doesn't care where you are getting your dependencies. You can skip all public package repositories and only use your own private one or mix and match. Adding repositories is literally as easy as doing the following to your build.gradle file: buildscript { repositories { google() mavenCentral() maven("your private repo url") } 1.2) As has been mentioned in previous comments, you add dependencies to the project rather than install them in the system. Gradle then has various cache folders where these dependencies recide and will fetch those that it doesn't find locally (new libraries, new versions etc). This is akin to how most software defines its dependencies. Python's pip & requirements.txt, Flutter's pupspec.yaml etc. 1.3) Complaining about having to use a full resource identifier ('com.google.guava:guava:31.1-jre') for the dependency rather than just an alias ('guava:31.1-jre') for the package name simply sounds like complaining for the sake of it. What if a fork exists of guava ('my.forks:guava:31.1-jre'), how would that get used along side the original if dependencies are only defined by their project name? 2.1) In my books, package updating should be methodical processes where each and every update is made in isolation, thoroughly tested and then merged in. In that respect I find it very nice that the build system isn't constantly telling me about a new library version everytime it runs, as it pushes naive developers to upping all libraries to their latest versions immediatly and then scratch their heads when unexpected behaviour starts popping up all over the place. 2.2) Various IDE's have mechanisms for notifying visually about when a package has a new version available to them. There are also various tools available to check for package version statuses, such as the 'Gradle Version Plugin' just to name one. I use this plugin extensively to get information on stable dependency updates. 2.3) If you want to always use the latest version of a dependency, you have various mechanisms available to you. It is easy to declare if you want to always go for the latest major, minor og patch versions automatically. See 'https://docs.gradle.org/current/userguide/single_versions.html https://docs.gradle.org/current/userguide/single_versions.ht...' for details. I'd hate to work an a project that had not clear version definition though as that would just signal very naive developers and/or sloppy practices (automatically going for latest patch versions is fine in my books).

stickfigure 5y ago

I don't understand your first bit, "install this package" isn't a thing in the java world. There are just dependencies, you don't "install" them. But this: > And then to upgrade to the latest I had to manually go figure out what the latest was Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick.

egeozcan 5y ago
NPM has had package locking since what feels like a million releases. I wish the Java community (which I'm actually also a part of) would stop rejecting everything that's not "the Java/enterprise way" and be humbled by exploring better alternatives, or alternatives with different tradeoffs for once.
- catdog 5y ago
  https://docs.gradle.org/current/userguide/dependency_locking.html https://docs.gradle.org/current/userguide/dependency_locking...
  - egeozcan 5y ago
    I wasn't arguing that gradle didn't have such a mechanism but thanks :)
- Larrikin 5y ago
  I think his point was more of a cultural difference. My IDE actually lints non pinned dependencies as a potential source of errors, whereas in the JS world it seems very common to not pin.
  - egeozcan 5y ago
    npm uses locks per default, and to disable that, you need to create a file called .npmrc at the root of the project and add package-lock=false to it. I don't think any popular project does that. It's also a common practice to use npm ci in all build scripts to never update packages even if they declared a version range in package.json, and package.lock not being able to satisfy package.json won't cause lock to get overwritten.
    - gkop 5y ago
      The fact that npm ci does what npm i should do (well, except for starting from scratch each time [0]), says it all. npm is a joke. [0] Yes, that's right. npm doesn't allow to to install incrementally respecting the lockfile. You can install incrementally with npm i and roll the dice, or install from scratch with npm ci to respect the lockfile. Basically the npm authors took the rm -rf node_modules/ workaround and productized it.
      - egeozcan 5y ago
        If you have a package.json and you run npm i it generates a package-lock.json from it. If you run npm i against that package.json and package-lock.json, the latter will never be updated, even if the package.json would be happy with newer versions. If you manually edit your package.json to have different ranges and run npm i and those ranges aren't compatible with your package-lock.json then the latter will be updated with version that are compatible with your package.json. Further runs of npm i will be as with 2 above. But of course you may think this behavior is a joke, I do not.
        gkop 5y ago
        How can I incrementally install exactly what’s in the lockfile, raising an error if it’s incompatible with package.json? This is what I expect npm i to do, but as far as I can tell, npm simply doesn’t support.
NateEag 5y ago
> Yeah, in the java world you write code against specific known dependency versions. That's why when you try to build it again in a couple months, it still works. I sure wish the JS community would learn this old trick. I've been writing JS with npm locked to specific, exact versions of dependencies since 2014, IIRC. Not everyone does this, obviously, but the tooling has been able to at least do a decent approximation of this for a long time (and I was and am very far from being a bleeding-edge adopter).
Aeolun 5y ago
> There are just dependencies, you don't "install" them Pray tell me where the dependency comes from then? When I add a ‘This package requires dependency x at version y’ to my gradle/maven file, it doesn’t magically appear on my system. Or rather, I think it does magically appear on my system, which is incredibly confusing.
- kaba0 5y ago
  It downloads it into cache for the first time and uses it at compile time at every subsequent build? How is it magical? Should it display ads instead and put random executables to my path? Or create a 1000000 file directory everywhere on which windows god damn chokes to open?
- jeroenhd 5y ago
  The dependency comes from the list of repositories you provide. Even in nodejs you don't manually enter the full URL to an NPM package. You just yarn add node-ipc==10.1 and your tooling will figure it out on its own. If you enable the general maven repository (the maven() you see at the top of many gradle build scripts), you'll get the code from maven. If you also add your personal repositories (which most people probably don't have), you'll get packages from there as well. I'm not sure how you add a second repository to node package managers, but I assume it's possible in some way without specifying the http download url. The biggest difference between the two ways of package management in my opinion is that node packages are just a word or two and Java packages are a full com.example.product.service.package name. That's a lot better in my opinion as it distinguishes between projects much more easily. I thought node-ipc was related to the nodejs project, for example. Some nodejs packages use namespaces, but most don't. Another difference is that nodejs has tons of tiny packages (I'll never get over how silly it is that is-odd and is-even appeared in my node folder by transitive dependencies) whereas the Java world generally uses huge packages almost exclusively. This leads to more boilerplate code (actually having to write simple functions like that yourself), but also to less dependencies that can break.
kaba0 5y ago
To add, gradle also has dependency check as a feature which will show possibly out of date packages.
lostcolony 5y ago
Okay - "Download and make this package available to my code", if that makes you feel better. "npm install (dependency name)" will 'download and make this package available to my code' from the NPM repository, for the current node project you're in. I can also specify custom repos to use, rather than NPM, if so desired. Gradle's default is "nah, go find the fully qualified URL package name and version number for me and paste it in the gradle build file for me, in the right location". Once you do that in Node, the package lock will specify what version you've downloaded, to make it a repeatable build. You can tweak it to indicate you want to pin the version at a given levels, as well; that's done in one place, and separately from the package-lock file that gets generated, that tells you what -actually- is being used. My follow up point is that when that version eventually goes stale, it's as simple as 'npm outdated' to determine if there's something more recent, and 'npm update' to update everything (based on whether you've pinned to a major/minor in your dependency list). You can also update specific packages with 'npm update (package name)'. I sure wish the Java community would learn this obvious 'trick' that every OS package manager enables. I know I want Jackson, say, I should be able to say "gradle install jackson" or whatever, and it would tell me all the options in the repo with jackson in the name. Then 'gradle install jackson com.fasterxml.jackson.core' and it would add that to my gradle file, with the most recent stable version. And 'gradle update jackson' would seek to update that dependency to the latest stable (with some syntax to pin the release, major, and maybe the full version, to enable 'gradle update' to update everything within a particularly defined scope).

MrDresden 5y ago

This honestly sounds like you not knowing the tool, rather then the tool not having the capabilities.

lostcolony 5y ago
Could be! Given that I've been across multiple Java shops, including with people who have been in the Java ecosystem for decades now, and I've never had anyone point out how to do this, and in fact seen those self-same people work around these perceived limitations, I doubt it. But it's quite possible the functionality is there, just so buried no one knows about it. Certainly, I haven't seen a response, yours included, that explains how to do it.
- MrDresden 5y ago
  Alright, I'll bite. With dependency management being 1) and the update flow being 2). 1.1) Gradle is a build system. As such it doesn't care where you are getting your dependencies. You can skip all public package repositories and only use your own private one or mix and match. Adding repositories is literally as easy as doing the following to your build.gradle file: buildscript { repositories { google() mavenCentral() maven("your private repo url") } 1.2) As has been mentioned in previous comments, you add dependencies to the project rather than install them in the system. Gradle then has various cache folders where these dependencies recide and will fetch those that it doesn't find locally (new libraries, new versions etc). This is akin to how most software defines its dependencies. Python's pip & requirements.txt, Flutter's pupspec.yaml etc. 1.3) Complaining about having to use a full resource identifier ('com.google.guava:guava:31.1-jre') for the dependency rather than just an alias ('guava:31.1-jre') for the package name simply sounds like complaining for the sake of it. What if a fork exists of guava ('my.forks:guava:31.1-jre'), how would that get used along side the original if dependencies are only defined by their project name? 2.1) In my books, package updating should be methodical processes where each and every update is made in isolation, thoroughly tested and then merged in. In that respect I find it very nice that the build system isn't constantly telling me about a new library version everytime it runs, as it pushes naive developers to upping all libraries to their latest versions immediatly and then scratch their heads when unexpected behaviour starts popping up all over the place. 2.2) Various IDE's have mechanisms for notifying visually about when a package has a new version available to them. There are also various tools available to check for package version statuses, such as the 'Gradle Version Plugin' just to name one. I use this plugin extensively to get information on stable dependency updates. 2.3) If you want to always use the latest version of a dependency, you have various mechanisms available to you. It is easy to declare if you want to always go for the latest major, minor og patch versions automatically. See 'https://docs.gradle.org/current/userguide/single_versions.html https://docs.gradle.org/current/userguide/single_versions.ht...' for details. I'd hate to work an a project that had not clear version definition though as that would just signal very naive developers and/or sloppy practices (automatically going for latest patch versions is fine in my books).