I
ну если у тебя множество маленьких модулей, то нужен бак/базель
Кстати была новость что в twitter переходят с pants на bazel
(глядишь скоро все эти форки загнуться и будет только bazel)
(глядишь скоро все эти форки загнуться и будет только bazel)
Size: a a a
2020 June 02
AK
Кстати была новость что в twitter переходят с pants на bazel
(глядишь скоро все эти форки загнуться и будет только bazel)
(глядишь скоро все эти форки загнуться и будет только bazel)
там некоторые команды достигли просветления и переходят на баш
https://github.com/twitter/dodo
https://github.com/twitter/dodo
AN
там некоторые команды достигли просветления и переходят на баш
https://github.com/twitter/dodo
https://github.com/twitter/dodo
А потом у них перестанет вообще что-то работать и они опять что-то изобретут. Можно написать что угодно на баше, но проблема в том, что а) оно будет работать только в этом проекте и абсолютно не будет масштабироваться и б) надо держать специально обученного человека, который понимает, как оно работает. У всех новичков будут уходить месяцы на освоение.
AK
А потом у них перестанет вообще что-то работать и они опять что-то изобретут. Можно написать что угодно на баше, но проблема в том, что а) оно будет работать только в этом проекте и абсолютно не будет масштабироваться и б) надо держать специально обученного человека, который понимает, как оно работает. У всех новичков будут уходить месяцы на освоение.
так про любую динамическую скриптуху можно сказать так то
AN
так про любую динамическую скриптуху можно сказать так то
Разумеется. У сборки должна быть логика и узнаваемая модель. API так сказать. Аргумент "я могу сделать это на баше/питоне/жс" вообще не прокатывает
QH
Кто-нибудь может объяснить, в чём смысл?
https://github.com/square/retrofit/commit/a9c0512fa6f88933702bf0e12243f5a584c01f66
- http://example.com/foo/bar/pong%26/?kit=kat%26
+ http://example.com/foo/bar/pong&/?kit=kat%26
https://github.com/square/retrofit/commit/a9c0512fa6f88933702bf0e12243f5a584c01f66
d
А потом у них перестанет вообще что-то работать и они опять что-то изобретут. Можно написать что угодно на баше, но проблема в том, что а) оно будет работать только в этом проекте и абсолютно не будет масштабироваться и б) надо держать специально обученного человека, который понимает, как оно работает. У всех новичков будут уходить месяцы на освоение.
99.99% всех проектов это трансляция java —> class —> jar. Никакой там модели не требуется. 90% времени сборки грыдла занимается обслуживанием самой себя
d
Хвала прозревшим
d
Разработка грыдлы - классический пример вещи в себе и джоб секьюрити
(
99.99% всех проектов это трансляция java —> class —> jar. Никакой там модели не требуется. 90% времени сборки грыдла занимается обслуживанием самой себя
Вот так набросил
QH
99.99% всех проектов это трансляция java —> class —> jar. Никакой там модели не требуется. 90% времени сборки грыдла занимается обслуживанием самой себя
Интересно. Откуда такой вывод?
d
Интересно. Откуда такой вывод?
эмпирически, вот про 90% времени - тут скорее придраться можно, величина оценочная
d
javac -sourcepath src -classpath -d build/classes
jar cfm manifest *.class
- процент жира вокруг этих двух строчек в грыдл инфраструктуре на порядки больше чем в моих сообщениях
jar cfm manifest *.class
- процент жира вокруг этих двух строчек в грыдл инфраструктуре на порядки больше чем в моих сообщениях
QH
Я ни разу не фанат грэдла, но работы там побольше будет.
* зависимости
* модули
* тесты
* заливка артефактов
* всякие плагины — покрытие, ондроед, прогард
* зависимости
* модули
* тесты
* заливка артефактов
* всякие плагины — покрытие, ондроед, прогард
d
да это понятно, но ни зависимости толком не решаются (nexus тот же вообще отвязан он технологии которая используется при сборке - бери и используй), ни запуск тестов ничто не мешает добавить
d
Ну будет 6 команд вместо 2х в условном build.sh
AG
@dimiiix может ты сразу поделишься историей успеха в отказе от гредла на своём/своих проектах с наглядным примером, что улучшилось и насколько легче стало жить?