BP
+ ознакомиться все же нужно, для того что бы ориентироваться и знать к кому обратиться и с какими вопросами/предложениями
Size: a a a
2021 May 15
BP
Это идеальный мир как коммунизм, вопрос в досягаемости
BP
Проекты частенько начинают с простого и потом уже развиваются и разрастаются.
Это оффтоп уже пошел.
Понятно зачем это нужно, и где поможет, но это не значит что это подходит всем
Это оффтоп уже пошел.
Понятно зачем это нужно, и где поможет, но это не значит что это подходит всем
BP
Ну вообще то это как раз идеология /оффтоп
VS
«не значит, что подходит всем» <— золотые слова.
Но у меня почему-то каждый раз получаются проекты-снежинки, где там-сям особенность.
Раз уж Maven вспоминали, то вот пример как было «до Gradle»: https://github.com/apache/calcite/blob/calcite-1.21.0/pom.xml
1300 строк xml кода с разнообразными profile.
Но у меня почему-то каждый раз получаются проекты-снежинки, где там-сям особенность.
Раз уж Maven вспоминали, то вот пример как было «до Gradle»: https://github.com/apache/calcite/blob/calcite-1.21.0/pom.xml
1300 строк xml кода с разнообразными profile.
VS
А потом оказывается, что «просто запустить javac недостаточно».
Например, если есть 2 модуля, один зависит от другого, то Gradle понимает «изменился ли public API», и, если не поменялось, то оно понимает, что перекомпилировать не нужно.
Как такое реализовать на make?
Например, если есть 2 модуля, один зависит от другого, то Gradle понимает «изменился ли public API», и, если не поменялось, то оно понимает, что перекомпилировать не нужно.
Как такое реализовать на make?
BP
ну там много мусора (xml в этом плане слабо подходит). А так выглядит не очень и долго нужно его "парсить"
BP
«изменился ли public API» - а если изменилась реализация :D ?
Я понимаю про что вы, не могу ответить так как у меня нет достаточно познаний в этой области, а на ум ничего не приходит. Ну и я не говорил про классический make, такой подход мне ткже не совсем нравиться.
Я на самом люблю когда "каждый отвечает за свое"
Я понимаю про что вы, не могу ответить так как у меня нет достаточно познаний в этой области, а на ум ничего не приходит. Ну и я не говорил про классический make, такой подход мне ткже не совсем нравиться.
Я на самом люблю когда "каждый отвечает за свое"
VS
А реализация методов (и private методы) не влияют на результат javac компиляции.
VS
Мы же не про запуск тестов говорим, а именно про компиляцию
BP
я может чего то не понимаю, но если я вместо хеш мапы решил использовать линкед то это кардинально меняет суть.
Или что вы имели под public API?
Или что вы имели под public API?
VS
Пример:
* Есть модуль core. Там class Registry { public Object get(String key) {…} }
* Есть модуль app, зависит от core.
Вот теперь, если внутри core меняется только реализация (например, внутри метода get добавили обращение к базе данных, то перекомпилировать app не нужно.
С другой стороны, если у класса Registry добавился новый public метод/поле, то перекомпилировать app уже нужно
* Есть модуль core. Там class Registry { public Object get(String key) {…} }
* Есть модуль app, зависит от core.
Вот теперь, если внутри core меняется только реализация (например, внутри метода get добавили обращение к базе данных, то перекомпилировать app не нужно.
С другой стороны, если у класса Registry добавился новый public метод/поле, то перекомпилировать app уже нужно
BP
ну вот про это я и гворю, это же кретична кому АПИ нужно без реализации ?
VS
Ещё раз: разработчик поменял реализацию core/Registry, и перезапускает приложение.
Gradle: перекомпилируем core, собираем jar. Реализация поменялась — вот вам новый jar. А перекомпилировать app уже не нужно, ведь у core не менялось public API с прошлой компиляции, поэтому можно брать прошлый app.jar. И потом уже запускать это всё вместе
Gradle: перекомпилируем core, собираем jar. Реализация поменялась — вот вам новый jar. А перекомпилировать app уже не нужно, ведь у core не менялось public API с прошлой компиляции, поэтому можно брать прошлый app.jar. И потом уже запускать это всё вместе
BP
ааа. Извините затупил.
VS
В случае с make подходом, core.jar будет зависимостью для компиляции app, и абсолютно любое изменение core приведёт к тому, что пересобираться будет всё остальное по цепочке