Re-publish paradox 0.9.x series into new org/repos
mdedetrich opened this issue · 5 comments
As you are aware Pekko us using paradox and due to us needing to publish documentation using JDK 8 we are stuck with using the 0.9.x series of paradox since its the latest series of paradox that is built using JDK 8 (the later paradox series only supports JDK 11+)
Would it be possible to create a branch of for the 0.9.x series and cherry pick the relevant commits so that a new version (I guess 0.9.3?) can be published into the new org/repo.
@mkurz Pinging you since you seem to be spearheading this, I can also help out if you create the branch at the point of https://github.com/lightbend/paradox/releases/tag/v0.9.2
@mkurz Would it be possible to look into this? I can also help drive this (i.e. creating the 0.9.x branch and backporting relevant commits so that we can republish current 0.9.2 on maven central) if people are willing to give me maintenance role on this repo @eed3si9n @SethTisue
Sorry, but Paradox is a bit out of my purview (either at Lightbend or in my personal interests) — especially since it's about JDK 8 (more on this below).
I'm not sure who else at Lightbend might want to help. Let's try mentioning @ennru, but I suspect he has other fish to fry.
due to us needing to publish documentation using JDK 8
At the risk of seeming presumptuous by remarking on a situation I don't know the particulars of:
Being stuck on JDK 8 seems like a very unhappy and unfortunate spot to be in — one likely to be an ongoing source of grief for years to come if not addressed. I see JDK 8 support increasingly being dropped ecosystem-wide, both in Scala specifically and in the Java world more generally. And personally, I think it's healthy.
Die, JDK 8! I can't wait! Any minute spent keeping JDK 8 alive in the OSS world is a minute wasted, as far as I'm concerned.
Is there any possibility of attacking the problem at the root and getting your build off 8?
Actually discussing this point further here would be off-topic IMO for this repo, but if it's under discussion elsewhere, I'd be curious for a pointer to it.
Is there any possibility of attacking the problem at the root and getting your build off 8?
We are trying this but we are hitting issues. The biggest issue is not that paradox 0.9.x series ONLY supports JDK 1.8 and paradox 0.10.x series ONLY supports JDK 11+. This is a result of a split that happened with parboiled (a dependency off parboiled) which used to use sun.misc.unsafe and because multi-release jar isn't properly supported we couldn't do the ideal thing where parboiled would support JDK 1.8 and all later versions.
So the problem is that since we support JDK 1.8 (there are massive business critical users of Pekko that still run on JDK 1.8 and it will take them time, i.e. years to move off of it) we want to run build under JDK 1.8 so all of the docs/paradox/api links against JDK 1.8. Its likely that Pekko will only be able to drop JDK 1.8 for thee 2.x.x series which is going to be binary breaking but not source breaking.
The other more pertinent point is that Pekko 1.0.x series is strictly a maintenance series which is designed to have bare minimum changes (i.e. we only fix CVE's/critical bugs) and so for us its ideal to just use a frozen pinned paradox 0.9.x which leads to the next point being that the simplest, fastest and easiest way to solve the problem for us right now would be to just republish 0.9.2 as 0.9.3 under maven with the new org. This solves the more critical problem that we are dealing with now where we want to move off of the lightbend/typesafe repos onto maven and this will give us more breathing room to figure out a way to publish docs using paradox under JDK 11 if possible, but again for Pekko 1.0.x series the dependencies are going to be pinned.
Actually discussing this point further here would be off-topic IMO for this repo, but if it's under discussion elsewhere, I'd be curious for a pointer to it.
So this part of the code is a good explanation for it and you can see apache/pekko-http#478 for the problems we have in updating it.
@mdedetrich I think you can close this issue now since Pekko should be happy with how things are (see apache/pekko-http#478 (comment))
Yup closing