4 ms·

Okay. The point of dymanic dependencies is that Rig could run some code to figure out what the main function imports, transitively, and use that info to build

Okay. The point of dymanic dependencies is that Rig could run some code to figure out what the main function imports, transitively, and use that info to build the entire project. All without listing dependencies in the build file. A good API might look like this: build_java_package("com.yzena.rig"); So when you add a new package and use it, you do not have to change the build files; Rig would pick it up automatically.

layer8 3y ago
In Java, there is no 1:1 relation between package imports and jars. A jar (dependency) usually contains many packages (namespaces), and of course the same packages can be contained in multiple (usually mutually incompatible) dependencies. (Java imports are often more fine-grained than, say, C/C++ header files.) Dependency selection therefore requires a conscious decision. IDEs provide tooling to suggest matching dependencies to be added to the build file based on the names of unresolved imports. However, the much more common direction is to first decide which libraries (dependencies) you want to use and add those to your build file, which then allows the IDE to suggest imports when you reference some unresolved type in your source code. So the dependency declarations in the build file generally come first, before you start writing your corresponding code. (This can be likened to specifying coarse-grained includes in your project build file, from which fine-grained sub-includes are then selected in each source file.) The conscious selection of dependencies is a good thing, IMO. Dependencies also don’t change frequently, so there isn’t much work to be saved by determining them automatically (except for transitive dependencies upon version bumps, which are determined automatically by the build system). Moreover, it’s not only the dependencies as such that are consciously selected, but also their respective version numbers. This prevents unexpected breaking changes.
- speed_spread 3y ago
  Yes. Cargo and Maven is where it's at. It's clear to me that any build system that's NOT based on a declarative file format and strong project model is a nightmare waiting to happen. Each generation of maintainer will add it's own customizations until it becomes a super specific brittle undocumented jumbled mess that's nigh impossible to work with and that prevents refactoring of project code.

layer8 3y ago

In Java, there is no 1:1 relation between package imports and jars. A jar (dependency) usually contains many packages (namespaces), and of course the same packages can be contained in multiple (usually mutually incompatible) dependencies. (Java imports are often more fine-grained than, say, C/C++ header files.) Dependency selection therefore requires a conscious decision. IDEs provide tooling to suggest matching dependencies to be added to the build file based on the names of unresolved imports. However, the much more common direction is to first decide which libraries (dependencies) you want to use and add those to your build file, which then allows the IDE to suggest imports when you reference some unresolved type in your source code. So the dependency declarations in the build file generally come first, before you start writing your corresponding code. (This can be likened to specifying coarse-grained includes in your project build file, from which fine-grained sub-includes are then selected in each source file.) The conscious selection of dependencies is a good thing, IMO. Dependencies also don’t change frequently, so there isn’t much work to be saved by determining them automatically (except for transitive dependencies upon version bumps, which are determined automatically by the build system). Moreover, it’s not only the dependencies as such that are consciously selected, but also their respective version numbers. This prevents unexpected breaking changes.

speed_spread 3y ago
Yes. Cargo and Maven is where it's at. It's clear to me that any build system that's NOT based on a declarative file format and strong project model is a nightmare waiting to happen. Each generation of maintainer will add it's own customizations until it becomes a super specific brittle undocumented jumbled mess that's nigh impossible to work with and that prevents refactoring of project code.