Split package akka.http.ccompat

[lefou]

This is a follow-up to akka/akka#28304 (comment).

The two artifacts akka.parsing and akka.http.core. both in version 10.1.11, contain (disjunct) classes in the Java package akka.http.ccompat. A split package is considered bad practice, even in plain Java world. Split packages are even not possible when working with sealed packages/jars.

As we currently review the OSGi support for akka and akka-http in a separate project (as a consequence of akka/akka#28304), we wanted to ask the purpose of the found split package. If this is "by accident", I'd like to propose one of the following fixes:

1. Move all classes to the same package into the same artifact
2. Rename one of the packages to avoid the split-package issue, preferably choosing a package name which shares the artifact name as it's prefix
3. Keep it as-is. I think this way should be avoided, but could be necessary e.g. when the packages are part of a public API. But even then, maybe 1. will also work.

Related to woq-blended/akka-osgi#1

[jrudolph]

we wanted to ask the purpose of the found split package. If this is "by accident", I'd like to propose one of the following fixes:

It's mostly by accident, the problem is that we often cannot repair it because of binary compatibility constraints.

For this particular instance of the problem, we could rename the one in akka-parsing because it's only internal.

The last time I looked into it, this wasn't the only instance, though. e.g. akka.http.scaladsl.settings is also split but that's public API we don't want to change. Another one is akka.http.scaladsl.server.directives. Before we start doing this we would need a comprehensive list of all these instances to see whether it makes sense at all to start this endeavor. My hunch is that just because of those two, changing the structure will take at least a deprecation cycle until they could be finally moved. That would probably take 1-2 years.

So, the most realistic outcome from our side will be 3.

3\. But even then, maybe 1. will also work.

It does not work for us because we want to keep the current module structure. But maybe it could work for you? You could just mix together all artifacts of akka-http into a single big one. This, of course, defies the goal of modularity (same as your solution 1. above) but since most people use the akka-http-core and akka-http together anyway (and all the other modules are small), it might not matter so much in practice.

[lefou]

Yeah, we saw these other packages too and will also report it, but as each package needs a possible different solution, I reported it separately. Although I agree that the other (not yet reported) split-package issue are not so easy to fix, I think this one can and should be fixed now by renaming the internal package name in akka-parsing.

[raboof]

Although I agree that the other (not yet reported) split-package issue are not so easy to fix, I think this one can and should be fixed now by renaming the internal package name in akka-parsing.

I agree we could move those ccompat classes (which should be internal), though indeed other instances of the same problem might not be so straightforward.