Please publish to maven central or maven.google.com

[ZacSweers]

Currently, flexbox-layout releases appear to only be published to jcenter and are not present on maven central. JCenter has a long history of artifact integrity issues and we try to avoid it at all costs. I recognize that maven central's publishing process is sometimes considered more tedious, but this signing/verification process is part of why it's preferred.

https://blog.autsoft.hu/a-confusing-dependency https://twitter.com/jakewharton/status/1073102730443526144?lang=en

[ephemient]

This has taken on some more immediacy due to the imminent shutdown of jcenter: https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

[lukas1]

👍 +1 to this one, please make this a priority.

[thagikura]

I'll upload it to either google maven or maven central.

[engincancan]

"JCenter repository will keep serving packages for 12 months until February 1st 2022" just as an update

[gildor]

@thagikura Any updates? I vote to publish it to google maven, it already includes most of com.google.android artifacts, it's easier to apply exclusiveContent for google repository

[robpridham-bbc]

Although it's not due to be properly disabled until 2022, JCenter has had numerous problems over the last few days and is currently serving me 403s right now, with further planned brownouts scheduled for April, so the sooner this can happen the better.

[ebraminio]

As our project already was using jitpack, I removed jcenter by fetching flexbox from jitpack instead, implementation("com.github.google:flexbox-layout:2.0.1") instead of com.google.android:flexbox, which needs adding a maven("https://jitpack.io") to allprojects { repositories { ... } }, as can be seen https://github.com/persian-calendar/DroidPersianCalendar/commit/7a4bddd90fa53da2c53873a86c21d45f11d723b5 it isn't ideal but maybe as a temporarily solution.

Update: Went to use ConstraintLayout's Flow using this approach https://stackoverflow.com/a/61545990 eventually, not ideal yet one less outdated dependency anyway.

[AlanChiou]

Another option is the repository "https://dl.bintray.com/google/flexbox-layout/".

maven {
        url 'https://dl.bintray.com/google/flexbox-layout/'
}

[Update] Oh, this is a bad option. I didn't notice this repository is Bintray's.

[robpridham-bbc]

Another option is the repository "https://dl.bintray.com/google/flexbox-layout/".

maven {
        url 'https://dl.bintray.com/google/flexbox-layout/'
}

Bintray is going away just like JCenter.

[Daphne-CoffeeIT]

I'm not sure if I understand you correctly, but how is that another option when Bintray gets shutdown?

Ah sorry, @robpridham-bcc was faster haha.

[lukas1]

Is there any update please? :-) It's been two months now.

[prithivraj]

There is a really good tool https://github.com/martinbonnin/vespene to migrate multiple artifacts from jcenter to maven central.

[imohsenb]

UPDATE 4/27/2021: We listened to the community and will keep JCenter as a read-only repository indefinitely. Our customers and the community can continue to rely on JCenter as a reliable mirror for Java packages. https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

[hj-pulsara]

UPDATE 4/27/2021: We listened to the community and will keep JCenter as a read-only repository indefinitely. Our customers and the community can continue to rely on JCenter as a reliable mirror for Java packages. https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

I believe existing JCenter artifacts still can't be updated, so this issue will still need to be addressed before the next release. Ideally sooner - I've lost trust in JFrog and this is the only dependency I still need on JCenter.

[extmkv]

My team is trying to remove jcenter() and this library still not available on mavenCentral() or even google()

[osipovaleks-onix]

any updates?

[thagikura]

Sorry for the delayed response. I'm still discussing which option works better (gmaven or mavenCentral) and I plan to decide it and upload it soon after I/O.

[kenneth-leong-gt]

I know putting the library in androidx is quite troublesome but this lib kind of belongs in androidx imo.

[thagikura]

We decided to upload the artifacts to google maven for better reliability in the future.

But due to the restriction of how google maven hosts artifacts, the groupId of this library needs to be changed from com.google.android to com.google.android.flexbox.

Given that the artifacts on JCenter exist indefinitely and we can't change the groupId for the past versions, I'm going to update the version of this library as 3.0.0, which has the same code as 2.0.1 (the latest version as of now) except for the change of the groupId. And upload the artifacts to google maven for the 3.0.0 version and onward.

FYI @yaraki

[thagikura]

I have uploaded the artifact at https://maven.google.com/web/index.html?q=flexbox#com.google.android.flexbox:flexbox:3.0.0

It should be available by the following declaration.

dependencies {
    implementation 'com.google.android.flexbox:flexbox:3.0.0'
}

We'll make future releases on the google maven.

[mohand1993]

@thagikura Since the release version 3.0.0 is still not mentioned here, i cannot really follow if is just the latest version 2.0.1 being renamed to 3.0.0, or a new release. can you please provide more information in this regard? How about the older releases? will they be migrated to the new repo as well?

[thagikura]

@mohand1993 thanks for pointing that out. I mentioned the 3.0.0 release.

And it's a new release, but as I commented previously the functionalities are exactly same as 2.0.1. The only change was the groupId from com.google.android to com.google.android.flexbox.

Older versions are not migrated to google maven as it conflicts with the old artifacts on JCenter because we can't change the groupId for the past versions.

[PaulWoitaschek]

It's also not that necessary as bintray said they'll keep the repo up forever

[vitalyster]

3.0.0 release depends on old kotlin-stdlib version from jcenter

[AlanChiou]

3.0.0 release depends on old kotlin-stdlib version from jcenter

<dependencies>
    <dependency>
      <groupId>org.jetbrains.kotlin</groupId>
      <artifactId>kotlin-stdlib</artifactId>
      <version>1.4.32</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>

This kotlin-stdlib is on Maven Central https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib/1.4.32 https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-stdlib/1.4.32/

Does your project force an old version?

[vitalyster]

@AlanChiou sorry, my bad, I removed jcenter from gradle properties but forgot to add mavenCentral

[lucis]

@thagikura thanks for that!

One question for anyone who knows a bit more about Gradle: is it possible to use this new version in a transitive dependency? I'm using this time that jCenter is down to understand what it takes to really strip it out from my project. Unfortunately, a library I use intercom-sdk-base has a dependency on flexbox:2.0.1.

Yarn has this thing called resolutions which allows specifying the version which transitive dependencies may be fetched. I was wondering if something like this was also achievable in Gradle.

I know the right way would be to update intercom-sdk-base but for some other reasons, we are stuck with one older version.

[gmk57]

@lucis AFAIK, Gradle would pick a newer version if you just specify it as a direct dependency. But due to group id change you'll probably need to exclude an old one:

implementation('io.intercom.android:intercom-sdk-base:9.0.1') {
    exclude group: 'com.google.android', module: 'flexbox'
}
implementation 'com.google.android.flexbox:flexbox:3.0.0'

[robpridham-bbc]

Yarn has this thing called resolutions which allows specifying the version which transitive dependencies may be fetched. I was wondering if something like this was also achievable in Gradle.

I haven't thought super hard about whether this is what you need, but there is resolutionStrategy.

Perhaps:

configurations.all {
    resolutionStrategy {
        force 'com.google.android.flexbox:flexbox:3.0.0'
    }
}

A pet hate is Gradle snippets with no context about where they belong, so this lives in the top level build.gradle within the buildscript definition.

Also raise it with the Intercom devs if this still exists in the latest build, as everyone industry-wide wants off JCenter.

Edit: actually I forgot about the group ID change as @gmk57 pointed out, so the above probably won't work. It is generally useful though so leaving it for posterity.

[lucis]

Thanks @gmk57 and @robpridham-bbc. Indeed, because of the groupId change, those solutions wouldn't work.

I'm trying using a different feature from Gradle on android/app/build.gradle:

buildscript {
    configurations.all {
        resolutionStrategy.dependencySubstitution {
                    substitute(module("com.google.android:flexbox:2.0.1"))
                        .using(module("com.google.android.flexbox:flexbox:3.0.0"))
                        .because("jCenter sunset")
                }
        }
}

I still have some other jCenter errors to fix before checking if it really worked, but it's supposed to do what I want.

[jasmeralia]

I just ran into this issue recently. I had been using flexbox 1.1.1, but bintray is throwing errors and seems totally broken at the moment. (My first assumption had been that the build issues might have been related to log4shell, but I found it was jcenter when I took a closer look today.)

I tried moving the app to 3.0.0, which compiled fine, but my app is now crashing. Is there any specific guide from migrating off of 1.1.x to 3.0.0? I also had to update paperdb due to jcenter issues, so the crashes might not be on the flexbox side; I haven't had a chance to capture any stack traces yet. That said, the paperdb migration seems to primarily affect the group ID, while flexbox has more significant changes with the major version bump due to mentioned risk of breaking changes, so that's where I'm focusing at the moment.