A
одним джарником не обойтись
когда в своё время пытался обновлять builtin hive на свежую версию столкнулся с тем что у хайва внутренняя иерархия классов поменялась
паттерн матчинг на instanceof в спарке скомпилировался
но работал неправильно =)
Size: a a a
2021 March 30
A
A
ну и в момент компиляции
<sources>
<source>v${hive.version.short}/src/main/scala</source>
<source>v${hive.version.short}/src/main/java</source>
<source>src/main/scala-${scala.binary.version}</source>
</sources>
<sources>
<source>v${hive.version.short}/src/main/scala</source>
<source>v${hive.version.short}/src/main/java</source>
<source>src/main/scala-${scala.binary.version}</source>
</sources>
A
хотя смотрю там не сильно много классов в 3м уже было
K
я просто потратил неделю боли, а потом нашел офф версию спарка спрятаную
AZ
Обычно в таких случаях поступают иначе, держат свою сборку с работающими зависимостями, а потом тянут ее до нужных патчей и бранчей
AZ
Ну мы так делали
AZ
Иначе процесс не факт что сойдётся за приемлемое время, кода то много там
AE
это ж какой объём работы
K
Обычно в таких случаях поступают иначе, держат свою сборку с работающими зависимостями, а потом тянут ее до нужных патчей и бранчей
возможно мне проще джобы будет поправить и все
K
не работая с хайв м етастором
AZ
Объём работы большой, но с определенного масштаба оно того стоит, в сумме с остальными преимуществами ванилек
AZ
Можно же не только с античными версиями сидеть, но и cutting edge, получая конкурентное преимущество
AE
и собрать все косяки early adopting
A
всё зависит от расхождения веток
иногда работы не так уж и много, только несколько патчей
иногда работы не так уж и много, только несколько патчей
AE
в спарке кодовая база довольно грязная, немало приватных форков сторонних зависимостей
A
и собрать все косяки early adopting
ну а куда без этого, но иногда это имеет смысл, всё зависит от задачи
AE
поддерживать свой форк верный головняк, не?
A
почему?