AN
да, это странно очень, что бинтрей заставляют паблишить javadoc jar
Не заставляет
Size: a a a
2020 September 02
IO
Не заставляет
меня на jcenter не пускали без него
AN
меня на jcenter не пускали без него
Это возможно, но bintray - это не обязательно jcenter. В общем, все можно. Но, возвращаясь к котлину, деплой стал лучше, но это все еще одна из основных болевых точек экосистемы.
IO
Это возможно, но bintray - это не обязательно jcenter. В общем, все можно. Но, возвращаясь к котлину, деплой стал лучше, но это все еще одна из основных болевых точек экосистемы.
вы про мейвен паблишинг?
IO
по-моему там все просто и понятно
AN
вы про мейвен паблишинг?
Деплой в том или ином виде. Особенно для мультиплатформы. Сейчас еще возникла большая путанница с совместимостью IR и не IR артефактов
IO
просто портянка из maven metadata жирненькая
IO
Деплой в том или ином виде. Особенно для мультиплатформы. Сейчас еще возникла большая путанница с совместимостью IR и не IR артефактов
ну обещали же вернуть обратную совместимость
AN
ну обещали же вернуть обратную совместимость
Где?
с#
Где?
+, ее и поломали потому что не хотели возвращать изначально
IO
Где?
ильмир писал где-то тут
AN
+, ее и поломали потому что не хотели возвращать изначально
Ну на JS черт с ней, мало либ еще, не сложно их перекомпилировать. А вот на JVM...
IO
Переслано от Ilmir
Да, могу. Когда я поднял этот вопрос в команде, мне ответили, что это ограничение временное и сделано, чтобы новым компилятором не компилировали библиотеки. В целом, процесс стабилизации нового бекенда следующее:
1. Компилируем только конечный код, не библиотеки. Фиксим баги, найденные пользователями.
2. Снимаем запрет, компилируем библиотеки, ждем фидбека.
3. После всего этого, объявляем его стабильным.
1. Компилируем только конечный код, не библиотеки. Фиксим баги, найденные пользователями.
2. Снимаем запрет, компилируем библиотеки, ждем фидбека.
3. После всего этого, объявляем его стабильным.
AN
Переслано от Ilmir
Да, могу. Когда я поднял этот вопрос в команде, мне ответили, что это ограничение временное и сделано, чтобы новым компилятором не компилировали библиотеки. В целом, процесс стабилизации нового бекенда следующее:
1. Компилируем только конечный код, не библиотеки. Фиксим баги, найденные пользователями.
2. Снимаем запрет, компилируем библиотеки, ждем фидбека.
3. После всего этого, объявляем его стабильным.
1. Компилируем только конечный код, не библиотеки. Фиксим баги, найденные пользователями.
2. Снимаем запрет, компилируем библиотеки, ждем фидбека.
3. После всего этого, объявляем его стабильным.
Ну да. Ладно, убедил
IO
Деплой в том или ином виде. Особенно для мультиплатформы. Сейчас еще возникла большая путанница с совместимостью IR и не IR артефактов
вот с нейтивом косяк. 1.4 не может использовать native-либы от 1.3.72. и поддержка старого нейтива в идее выпилена подчистую
AN
вот с нейтивом косяк. 1.4 не может использовать native-либы от 1.3.72. и поддержка старого нейтива в идее выпилена подчистую
Ну так натив по-определению несовместим. Вообще. Живите с этим
с#
Ну так натив по-определению несовместим. Вообще. Живите с этим
почему так ?
AN
почему так ?
Потому что натив в любом случае компилируется под платформу. Так что полной совместимости не будет никгда. А конкретно котлин-натив еще и не стабилизирован.
IO
Ну так натив по-определению несовместим. Вообще. Живите с этим
ъуъ
AM
Потому что натив в любом случае компилируется под платформу. Так что полной совместимости не будет никгда. А конкретно котлин-натив еще и не стабилизирован.
Я думаю, в первую очередь именно из-за того, что он не стабилизирован. Либы-то (и код исполняемый унутре) в своём формате, за совместимость отвечает формат, а не платформа.