Hi Taher,
absolutely, this is a major problem for production projects and for them
the timeframe is very short.
Thinking about your list of possible actions, the most convenient
(simplest) way for all parties would be to provide patches for the
affected release versions IF we are able to solve this just with
repository configuration.
Users can apply those patches or adjust their installations guided by us.
We might need to provide alternative download options for artifacts
which are not hosted by maven central, google or other central
repositories. Hopefully, those are only a few. I am currently checking
this. For trunk, we are at about seven libraries missing when using
maven central.
Of course, we should have a good communication towards our users
providing information and solutions through our various social media
channels, blog etc.
Let's gather some more information and make a plan when we have more
insight of the real impact (technically).
Best regards,
Michael Brohl
ecomify GmbH - www.ecomify.de
Am 06.02.21 um 12:01 schrieb Taher Alkhateeb:
Hi Folks.
I need to stress something very important here. The problem is not at
all future versions, the big problem is existing versions.
If you have a production system running and JFrog pulls the plug on
May 1st, you cannot run the server unless you have some existing
gradle cache and you need to pass the offline flag to ignore the
jcenter repository.
So any solution here is a painful one. Here are the solutions I can
think of:
- create a mirror of jcenter that at least covers the requirements of
older OFBiz versions. The problem here is that people who worked on
older versions of trunk are going to hit a wall. It's also hard and
costly to setup a mirrored repo.
- create a compressed archive of all cache artifacts for each major
version.
- Inform users to make a backup copy of gradle cache archives if they
are on an older version and encourage them to upgrade ASAP.
- create a patch file for each major release that alters dependencies
to switch to mavenCentral. The patch would mostly affect build.gradle.
- Make commits directly to all release branches. However the problem
here is that some people are running on old releases and cannot
upgrade immediately due to merge conflicts and whatnot.
This is a very nasty move by JFrog, they hurt a lot of projects.
Android depends on JCenter, React Native, OFBiz, and numerous other
projects and libraries that go even beyond the java eco-system.
- Taher
On 2/6/21 1:30 PM, Jacques Le Roux wrote:
Hi Taher,
Yes, yesterday I moderated/accepted, I guess the same message you
received, to the private ML. We received it in the private ML because
we (PMC members) have a credential we use to upload Gradle wrappers
version on Bintray:
https://cwiki.apache.org/confluence/display/OFBIZ/Load+new+gradle+wrapper+version+on+bintray
So it's also a release concern...
I agree we should not procrastinate... Fortunately we have 2 months
to decide and act...
We should try to use MavenCentral as much as possible, but IIRW maybe
it will not be enough.
HTH
Jacques
Le 05/02/2021 à 22:04, Taher Alkhateeb a écrit :
Hello Everyone,
I received emails and checked resources [1] that seem to confirm
JCenter from JFrog is going down and that the last day of operation
for the repository is going to be May 1st 2021.
This is a big deal as many running instances will crash unless
updated, so not only do future versions of OFBiz need to adapt, but
also existing installations.
I'm not sure how to best handle this? Especially for production
instances out there on older versions of OFBiz. Maybe one solution
is to host the existing libraries in some temporary location or try
to migrate them to MavenCentral ... Whatever is the solution I think
we should make a fast move.
[1]
https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter
https://www.infoq.com/news/2021/02/jfrog-jcenter-bintray-closure
