Смотря что вам надо. Если вы занимаетесь философией позитивизма, то надо поработать над терминами.  Если с точки зрения сборки, то это зависимость, вы можете называть это модулем, если хочется, но вот скажем в идее будет другая терминология, там gradle module - это совершенно конкретная штука. В самом градле по-моему оно все-таки проектами называется, а не модулями, я тут ошибся. Короче вы определитесь, зачем вам нужно это определение, тогда и давайте.

Внешняя зависимость отличается от внутреннего модуля/проекта/whatever тем, что вы не контролируете ее жизненный цикл, а получаете просто куском - набором файлов.

Хорошо. Чуть-чуть больше понимаю - и слава Богу

Спасибо за отклик

Раз уж мы в офтопе, позволю себе момент философии. Любая терминлогоия (опять же в духе позитивизма) нужна в первую очередь для того, чтобы что-то с ней делать. Вы сначала выясните, зачем вам этот термин, как вы будете его использовать, а потом определяйте

Просто я котлин учил. Там есть новый, по сравнению с джавой, модификатор видимости, который позволяет видеть функции/свойства внутри модуля. Вот и я пытался сопоставить понятие, увиденное в грэдл, с понятием из доки котлина

Internal

The internal visibility modifier means that the member is visible within the same module. More specifically, a module is a set of Kotlin files compiled together:

an IntelliJ IDEA module
a Maven project
a Gradle source set (with the exception that the test source set can access the internal declarations of main)
a set of files compiled with one invocation of the <kotlinc> Ant task

В котлин это однозначно build unit, он же gradle project.

Даже source set, так правильнее

Спасибо. Чуть понятнее. Понапридумывают терминов, потом страдай

не совсем же
обычно это называют вроде compilation unit
потому что есть же мультиплатформа, где сорссеты зависят на друг друга, и всё равно internal везде виден

Можно и так. Хотя там тоже не совсем однозначно из-за зависиостей соурс сетов и стабов. Я бы сказал, что gradle project в большинстве случаев покрывает

не только же gradle-ом можно билдать
интересно, как это всё выглядит в bazel, если там по сути модуль = пакет

Кидай конкретные листинги

Подозреваю, что под него нет котлин плагина

https://github.com/bazelbuild/rules_kotlin
Есть что-то

grammar Calculator {
    token TOP { <calc-op> }
 
    proto rule calc-op          {*}
          rule calc-op:sym<add> { <num> '+' <num> }
          rule calc-op:sym<sub> { <num> '-' <num> }
 
    token num { \d+ }
}
 
class Calculations {
    method TOP              ($/) { make $<calc-op>.made; }
    method calc-op:sym<add> ($/) { make [+] $<num>; }
    method calc-op:sym<sub> ($/) { make [-] $<num>; }
}
 
say Calculator.parse('2 + 3', actions => Calculations).made;

А именно, разделение логики и грамматики. Это потребует заката солнца вручную и поддержку в компиляторе, чтобы выразить в статически-типизированном языке.

Ну я наверное не настолько перлом восхищаюсь как ты, но на работе есть пару скриптов, которые очень легко читать и понятно, и я даже не знаю перл.

grammar Calculator {
    token TOP { <calc-op> }
 
    proto rule calc-op          {*}
          rule calc-op:sym<add> { <num> '+' <num> }
          rule calc-op:sym<sub> { <num> '-' <num> }
 
    token num { \d+ }
}
 
class Calculations {
    method TOP              ($/) { make $<calc-op>.made; }
    method calc-op:sym<add> ($/) { make [+] $<num>; }
    method calc-op:sym<sub> ($/) { make [-] $<num>; }
}
 
say Calculator.parse('2 + 3', actions => Calculations).made;

Я не говорил, что не появляются в принципе новые правильные высказывания. Это выглядит логично