LINUX.ORG.RU

jcenter накрылся

 , , , ,


0

1

Сидел тут, потихоньку кодил в Android Studio, потом заметил что при сборке gradle долго какой-то maven-metadata.xml скачивает и завершается с ошибкой read timeot. Погуглил, узнал, про репозитории, где хранятся java проекты.

Вообщем оказывается что jcenter признали устаревшим и рекомендуют переходить на Maven Central.

Ну, хорошо, подумал я, делов то, нужно ведь просто добавить mavenCentral в gradle конфиг и убрать jcenter

allprojects {
    repositories {

        //jcenter()
        google()
        mavenCentral()



    }
}


Добавил, все хорошо, в целом, но у меня есть некоторые пакеты, которые находятся только в jcenter и нигде больше их нет. Это, например, exoplayer, который имеет зависимость rtmp-client, которая есть только в jcenter. Иду в github в Issues, нахожу там где пишут что сие нужно переносить из jcenter, на что был ответ

I see. Thank you.
I think we definitely add the lib to the maven repo or somewhere.

Типа да это круто, мы когда-нибудь добавим нашу библиотеку в репозиторий maven или еще куда-нибудь, но пока ее нигде нет кроме как в jcenter. Как выяснилось, не добавили.

Потом искал эти пакеты на https://mvnrepository.com/ это вроде как агрегатор репозиториев. Добавлял репы, но ни к чему это не приводило, либо репа выдавала 404, либо 500, либо 403 ошибку.

В общем, у меня есть проект в Android Studio, жил он с этими зависимостями около 3 лет

android {
  dependencies {
    implementation 'com.google.mlkit:barcode-scanning:17.0.0'
    implementation "androidx.camera:camera-camera2:1.0.1"    
    implementation 'com.squareup.okhttp3:okhttp:4.9.0'

    implementation 'com.google.android.exoplayer:exoplayer:2.15.0'
    ...
  }
}


который собирался, запускался и работал. Сейчас я его не могу запустить, потому что не работает какой то там jcenter. Получается никто за это не отвечает, я пользовался этим на свой страх и риск? Я ничего не понимаю

★★★★

Ответ на: комментарий от fsb4000

Понятно. А я то думал все это из астрала берется, ну как минимум из гугла или он хоть за этим следит. Оказывается вот оно как. Неужели никто не может склонировать jcenter и поддерживать его? А если завтра github закроется?

gobot ★★★★ ()
Ответ на: комментарий от cocucka

Сейчас я этим вопросом как раз и озадачен. Вопрос только где взять эти пакеты и как сделать локальный кэш. Со вторым вопросом еще можно разобраться, а вот с первым не понятно. Я очищал уже кеш поэтому пакеты удалились локально

gobot ★★★★ ()

Получается никто за это не отвечает, я пользовался этим на свой страх и риск?

Ну да, это же опенсорц. У меня такая же ситуация с одной софтиной из фдройда была -  MiMangaNu - разраб периодически фиксил проблемы с парсингом источников, но потом ему надоело и он тупо все бросил. Прога не работает, ибо опять все поменялось. Форкнул, полез ковыряться сам, но пока так и не дошли руки допилить. Да и не хочу, проще свой простенький скрипт написать, чем разбираться в чужом коде.

И вангую, что так во всем опенсорце, если это не «мейнстрим», разработчики тебе ничем, собственно, и не обязаны.

А по твоему вопросу: вот в IDEA помимо сборки через mvn можно библиотеки в виде *.jar файлов подсовывать в проект, в андроид-студии так не получится?

Zhbert ★★★★★ ()

Вот новость о закрытии jcenter:

Компания JFrog объявила о скором закрытии сервисов Bintray, JCenter, GoCenter и ChartCenter

Виновник сего, Барух Садогурский, даже появился о обсуждении той новости под анонимусом.

Что касается решения, пока этот LibRtmp-Client-for-Android не перенесли в Maven Central его можно собрать самому из исходников и результат сборки выложить на github-е так, чтобы сам github использовался как Maven репозиторий.

hummer ()
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от gobot

А если завтра github закроется?

Все мои проекты, которые я открывал на гитхабе, туда лишь зеркалятся с моего личного GitLab. Даже если что-то упадет, все мое останется у меня.

Zhbert ★★★★★ ()
Ответ на: комментарий от fsb4000

Все же я думал, что гугл что то понадежней придумает. Ну или хотя бы будет deprecated предупреждения кидать год для начала. А тут на тебе, за один день все рухнуло. Предупреждали конечно, да кто же их блог читает девелоперский

gobot ★★★★ ()
Ответ на: комментарий от gobot

Правильный способ это поднять локально репозиторий, например на artifactory, в режиме зеркала, все зависимости перекачать, чтобы они осели там в базе и потом всё архивировать со своим проектом.

Ленивый способ это тупо заархивировать ~/.m2/repository. Но с грэдлом не проканает.

А вообще хорошая практика это добиваться того, чтобы твой проект всегда собирался на оффлайн-машине на чистом образе (например докере).

Legioner ★★★★★ ()
Ответ на: комментарий от gobot

Да, понятно, что все самому собрать можно. А обновлять как? Можно конечно не обновлять…

Это уже из области devops, которую я не очень люблю. Видимо нужно использовать какой-то сборочный сервер, например Jenkins, который будет следить за репозиторием автора, при появлении нового тага запускать новый билд и результат деплоить к тебе на github в «репозиторий». Возможно github уже умеет это делать, я просто не люблю ковыряться в devops и поэтому не в курсе.

hummer ()
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от Legioner

У вас много опечаток в ~/.ivy2/cache/.

Но лучше зеркало поднимать, безусловно, да, чем тупо кэш копировать и ручками резервировать куда-то.

BattleCoder ★★★★★ ()
Последнее исправление: BattleCoder (всего исправлений: 1)
Ответ на: комментарий от gobot

Все же я думал, что гугл что то понадежней придумает. Ну или хотя бы будет deprecated предупреждения кидать год для начала. А тут на тебе, за один день все рухнуло. Предупреждали конечно, да кто же их блог читает девелоперский

Гугл уже примерно полгода пишет варнинг о jcenter при сборке проекта)

jcenter как бы решили сделать ридонли, и пропадать он не будет. Я не смотрел особо, но у тебя или просто с сетью проблема, или сам jcenter прилёг на время, но рановато ты бросился его выпиливать) Все с ним должно собираться нормально

F457 ★★★★ ()
Ответ на: комментарий от Legioner

А вообще хорошая практика это добиваться того, чтобы твой проект всегда собирался на оффлайн-машине

О у нас пионеры как раз с этими идеями носятся. Сделали значится свой артифактори... и теперь гредл синк занимает вместо пары минут час ибо артифактори еле ворочается. Порекомендовали во время обеда синк делать, чтоб на работу не влияло.

F457 ★★★★ ()
Последнее исправление: F457 (всего исправлений: 1)