Develop Reference

JCentre may be down permanently. What are our options?

I have been trying to build a react native app since the early hour of today but was getting the follwing errors:
> Could not HEAD 'https://jcenter.bintray.com/com/facebook/react/react-native/maven-metadata.xml'.
> Read timed out
After checking out https://jcenter.bintray.com, I found out it was down. Can anyone point me to the right option to resolve this issue? Is there any alternative since they said the site may not come back up?

I guess your question is already answered here.
As mentioned in this source:
No more submissions will be accepted to JCenter since March 31st, 2021.
So you should migrate all of your repositories to the alternative hosts such as mavenCentral.

Based on the answered issue on Github, a temporary solution could be like the following:
android/build.gradle
all { ArtifactRepository repo ->
if(repo instanceof MavenArtifactRepository){
def url = repo.url.toString()
if (url.startsWith('https://jcenter.bintray.com/')) {
remove repo
}
}
}
if the issue came form node_modules you can use patck-package to keep the changes on production environment.

As stated in https://stackoverflow.com/a/74265617/772091 , dependencies can come with their own jcenter() repository. If you can wait for every dependency to be updated, you can force remove those repositories, using your android/app/build.gradle file :
allprojects {
repositories {
all { ArtifactRepository repo ->
if (repo instanceof MavenArtifactRepository) {
def url = repo.url.toString()
if (url.startsWith('https://jcenter.bintray.com/')) {
remove repo
}
}
}
...

Reference links, [FIXED] Android build failures : https://github.com/facebook/react-native/issues/35210

How to GPG sign and publish an aar directly to Maven Central?

I'm working on properly setting up my Gradle scripts for publishing an .aar directly to Maven Central (with JFrog sunsetting Bintray, numerous resources about publishing to Bintray are no longer relevant). One of the prerequisites is to have all artifacts (aar, sources jar, java-doc jar, pom.xml) uploaded alongside corresponding GPG-signature files (e.g. sources.jar.asc).
Following these two guides (which are very much alike), I've largely managed to do so:
https://medium.com/#nmauti/sign-and-publish-on-maven-central-a-project-with-the-new-maven-publish-gradle-plugin-22a72a4bfd4b
https://www.albertgao.xyz/2018/01/18/how-to-publish-artifact-to-maven-central-via-gradle/
However, though well describing the solution using Gradle, both guides seem to focus on plain .jar's rather than .aar's. In particular, I wasn't sure about what to set up as a project archive in order to put on the automated sign+publish list, as suggested:
project.artifacts {
archives sourceJar // Ok, I have a sourceJar task - will be signed and uploaded
archives javadocJar // I use Dokka, but got that to work by registering my dokka task
archives jar // What's "jar"? this doesn't help much!... :-/
}
I even tried registering the output .aar file, explicitly:
publications {
android.libraryVariants.all { variant ->
if (shouldPublishVariant(variant)) {
// ...
// ...
variant.outputs.forEach { output ->
project.artifacts {
archives output.outputFile // The full path of the .aar to publish!
}
}
}
}
}
But that seemed to have resulted in this flaky error:
Execution failed for task ':detox:publishMavenFullReleaseAarPublicationToMavenRepository'.
> Failed to publish publication 'mavenFullReleaseAar' to repository 'maven'
> Invalid publication 'mavenFullReleaseAar': artifact file does not exist: '.../build/outputs/aar/library-full-release.aar.asc'
I'm looking for a stable, bullet-proof solution that would sort this out end-to-end, with no flaky errors.

As a solution, I've found that registering the task generating the .aar as a project archive -- rather than registering the file itself, does the trick (much like as done for the sources and javadoc jars):
publications {
android.libraryVariants.all { variant ->
if (shouldPublishVariant(variant)) {
// ...
// ...
variant.outputs.forEach { output ->
project.artifacts {
// For example: bundleProdReleaseAar is the task that generates library-prod-release.aar
archives project.tasks["bundle${variant.name.capitalize()}Aar"]
}
}
}
}
}

How to change groupid if project is already uploaded to bintray and synced with jcenter?

I've recently uploaded my github project to bintray and successfully synced it with JCenter repository.
I used this tutorial:
http://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en
So my gradle dependency was :
dependencies {
compile 'com.github.danylo2006:hashtag-helper:1.1.0'
}
In order to upload it I've modified my build.gradle and added relevant peace of script. Everything like in the tutorial.
... some code here
ext {
bintrayRepo = 'maven'
bintrayName = 'hashtag-helper'
publishedGroupId = 'com.github.danylo2006'
libraryName = 'HashTagHelper'
artifact = 'hashtag-helper'
libraryDescription = 'This is a library designed for highlighting hashtags ("#example") and catching click on them.'
siteUrl = 'https://github.com/danylo2006/HashTagHelper'
gitUrl = 'https://github.com/danylo2006/HashTagHelper.git'
libraryVersion = '1.1.0'
developerId = 'danylovolokh'
developerName = 'Danylo Volokh'
developerEmail = 'v.danylo#gmail.com'
licenseName = 'The Apache Software License, Version 2.0'
licenseUrl = 'http://www.apache.org/licenses/LICENSE-2.0.txt'
allLicenses = ["Apache-2.0"]
}
Here is the tricky part:
I've changed my github nickname danylo2006 to danylovolokh and now I want to change gradle dependency:
dependencies {
compile 'com.github.danylo2006:hashtag-helper:1.1.0'
}
Change to:
dependencies {
compile 'com.github.danylovolokh:hashtag-helper:1.1.0'
}
I got groupId that I need from Sonatype
So I've modified my gradle script.
The only relevant change is :
publishedGroupId = 'com.github.danylo2006'
Has been changed to
publishedGroupId = 'com.github.danylovolokh'
I run the relative commands:
gradlew install
gradlew bintrayUpload
And I got BUILD_SUCCESSFULL
But if I add new dependency to any other gradle project I get an error that "Error:(36, 13) Failed to resolve: com.github.danylovolokh:hashtag-helper:1.1.0"

Inclusion to JCenter is done by the path of your groupId. JFrog needs to include the new path from your package to JCenter as well.
Please contact JFrog support at support#bintray.com

#JBaruch is correct. It seems that emailing bintray is the correct way to really get these things changed. But for completeness, I am attaching the response I received from Bintray. Hopefully posting their response will prevent them from getting bombarded by emails...
For context, I have a java repository with the package (groupID:artifact):
io.jeti.utils:serialize
There are currently versions (1.0.0/1.0.1/1.0.2/1.0.3/1.0.4/) using this groupID. I asked them to change this to
io.jeti:serialize
And in fact, I already pushed versions (1.0.5/1.0.6) to bintray with this shortened groupID. This was the response:
We understand your use case. In such cases, we recommend creating a
new package and submit a new inclusion request. Please let me explain,
let's take 'serialize' package from your java repo for example.
Currently it has 2 path prefixes when only one is synced with Jcenter:
io/jeti/utils/serialize/ -> Synced io/jeti/serialize -> doesn't exist
in jcenter
Relinking the new groupId, will cause the old/current groupId
(io/jeti/utils) and its versions (1.0.0/1.0.1/1.0.2/1.0.3/1.0.4/) to
be un-resolvable when since it rely on the old groupId. This might
broke current integrations with your builds and scripts. Therefore,
the best approach is to create a new package (e.g serialize2), submit
a new inclusion request (which includes the new groupId -
io/jeti/serialize) and we will approve it and make it synced with
JCenter. In this case, you will get a full resolution of all of your
existing versions of the package (as well as 1.0.5/1.0.6).
Please let us know how to proceed.

My painfully acquired advice would be to create a new bintray package and ask for that to be published to the new groupId. I have tried to move an existing package and 48 hours and 20 messages to and from JFrog support have left me unable to publish my original package at the old or new location, nor a new package at the new location.
In the end I have had to register a new domain name to host my project, as bintray have effectively denied access to the groupId I was trying to change to.

StickersManager class not found for Quickblox

I am trying to use Quickblox's sample chat application.
http://quickblox.com/developers/Android_XMPP_Chat_Sample
But I am getting this error "The import vc908 cannot be resolved"
At this line :
import vc908.stickerfactory.StickersManager;
I have used these libs :
- quickblox-android-sdk-chat-2.2.6.jar
- quickblox-android-sdk-core-2.2.6.jar
Also Added these :
- android-support-v7-appcompat
- google-play-services_lib
- pull-to-refresh

StickersManager is a part of StickerPipe library. To use stickers functionality, you must include dependency to this library
repositories {
maven { url 'http://maven.stickerpipe.com/artifactory/stickerfactory' }
}
dependencies {
compile('vc908.stickers:stickerfactory:0.2.2#aar') {
transitive = true;
}
}
This integration described at Stickers section of documentation
You need use android studio to build project. If you use Eclipse, try to migrate with this tutorial
UPDATE
Eclipse users now can follow this instructions to add StickerPipe library
And another sample with StickerPipe library

Publish on bintray using the gradle-bintray-plugin

I have an Android-Library that I would like to publish on bintray.
So far so good, I am using the gradle-bintray-plugin 1.2 with the following configuration:
bintray {
user = properties.getProperty("bintray.user")
key = properties.getProperty("bintray.apikey")
configurations = ['archives']
pkg {
repo = "android" // thats how my maven repository is called on bintray
name = "mylibrary"
websiteUrl = "https://somewebsite" // replaced this, since the project should not matter
issueTrackerUrl = 'some issuetracker url'
vcsUrl = "some repository"
licenses = ["Apache-2.0"]
publish = true
version {
// the 2 functions here, are building the version number
name = versionNameBuild() // i.e. 1.0.0-SomeName
vcsTag = versionName() // 1.0.0
gpg {
// keys are uploaded
sign = true
}
}
}
}
The first issue I ran into, was that after I uploaded the library the Version number was "unspecified". Meaning, that the file was uploaded successfully, but it was called smth. like "mylibrary-unspecified.aar". I figured out that I had to additionally specify the project version number in gradle.
like this:
project.version = "1.0.1"
After that, this was working fine. Now I have only 2 Questions left:
I would expect my files to be uploaded like this:
$BINTRAYUSERNAME/$REPONAME/$PACKAGENAME/$VERSION/*.aar
But they are actually uploaded to smth like this:
$BINTRAYUSERNAME/$REPONAME/$PROJECT_FOLDERNAME_OF_ANDROID_STUDIO/$SUBDIRECTORY_OF_THE_LIBRARY/$VERSION/*.aar
Can I change this "path" somehow? Does it matter?
Which leads me to my next question.
How can I specify the maven group-type? I mean it's a maven repository right? So I should be able to set this up? Is this may be related to my first question?

Can I change this "path" somehow? Does it matter?
Yes and yes. This path changed, as soon as I used the group variable:
group = "my.awesome.group"
This solves the second Question as well. The path of the uploaded file is then:
$BINTRAYUSERNAME/$REPONAME/$PACKAGENAME/$GROUPPATH/$VERSION/*.aar
I recommend using for Android libraries the example script.