HN user

justoreply

114 karma
Posts0
Comments53
View on HN
No posts found.
Cuis Smalltalk 2 years ago

For what I know, Pharo VM was forked in the past from OpenSmalltalk, so they are no longer using the same

I have a company-provided mac, I don't have an App Store account as it requires a phone number (and I'm not going to use my personal phone number to register it, it is not even allowed by policy) so I'm not going to update any app via the store

Gradle still sucks 3 years ago

I rarely build big projects, we usually create multiple small ones instead and if necessary reuse through artifactory or something, but unless I misunderstand you, this is exactly the same as Maven does in a multi module project, isn't it?

for example when when you change an api module in a multi module project, gradle will rebuild/test all the modules that depends on that: you can't do automatically with maven, if you have separate artifacts shared via a repository (at least for my understanding). You can use a reactor module, but maven is not caching efficiently in local builds and not caching at all from a common, distributed cache.

But why should other developers have a relation to the source of dependencies except for debugging?

Because in a multi module project, each developer has access to the complete project source code and can change whatever module: this is the whole idea of the setup (monorepo idea as Google, for example). In this scenario it is possible to have fine grained module boundaries without the cost of creating new project or the evolution of the interface. If a module doesn't provide the information needed it is easy to change it and gradle will rebuild everything that depends on that. If a new module is needed, it is just a new directory with a build.gradle file in it.

Just to be clear, the end result of a multi module project, at least in my setup, is the creation of single artifact that is going to be deployed.

Gradle still sucks 3 years ago

given a project split in several modules, we don't want to build them separately, we want to type check at compile time that everything works and we have a single build system managed by Gradle. Gradle is smart enough that if we are changing a module, we can build all the dependent ones, and only them.

The cache system comes into play when someone is changing something: when a developer is updating the code locally with changes from other developers, they don't have to compile and run tests of modules they are not changing locally, as gradle is downloading automatically the changes from the build cache.

* Developer 1 changes module A * code is pushed * CI pipeline is running and uploading all the artifacts (final production code, final test code, test results) * Developer 2 pull code locally * gradle find changes from the last local run, it tries to compile/run the tests of updated modules but results are downloaded from the cache, instead of running locally

Gradle still sucks 3 years ago

Maven is very slow in big, multi module projects. Gradle can cache module results (avoiding rebuilding), test results and can distribute build artifacts between developers