Merge quarkus/[service|server] modules in polaris-server

[jbonofre]

All quarkus modules can be merged together in a single module. This module should be polaris-server directly (no need to keep Quarkus there).

[snazy]

No, those cannot (and should not) be merged.

[snazy]

/cc @adutra

[jbonofre]

@snazy It has been discussed with @adutra and yes it's possible and should be done.

[jbonofre]

To be clear, the intent here is to "merge" the beans but still have a default module with just application.properties.

[snazy]

To be clear, the intent here is to "merge" the beans but still have a default module with just application.properties.

This is not what the title says: "merge admin-tool + server (+ service)". Those are two different executables

[jbonofre]

Ah yes, the idea is to merge service and server as app. admin is still "separated". Sorry I wasn't clear enough.

[adutra]

Yes, we can (and probably should) merge service and server. But we should not touch admin or defaults.

I already have the change ready btw, but it's waiting on #987.

Also, the change will introduce a tricky issue related to docker images and integration tests. It's manageable, but It would maybe be easier if we waited for quarkusio/quarkus#46232.

[jbonofre]

@adutra thanks for your update. I agree. The intent of this GitHub Issue is just to track it. I hope you don't mind: I assigned the issue to you as you already have the change ready.

[dimas-b]

What will the unified polaris-server module publish (to Maven)? Will it be the quarkus fat jar or a lean jar with just local classes?

How can downstream projects reuse service classes without pulling too much extra stuff?

[adutra]

What will the unified polaris-server module publish (to Maven)? Will it be the quarkus fat jar or a lean jar with just local classes?

How can downstream projects reuse service classes without pulling too much extra stuff?

It would be the fat jar (and the docker images).

You raise a very good point. Let me think about this more. It might not be a good idea after all.

[snazy]

It would be the fat jar (and the docker images).

I'd favor a zip/tgz distribution over a fat jar (aka don't tackle #797, #785 has a demo for this.)

Quarkus "fast jar" builds faster and leaves the individual dependency jars (although instrumented). IIRC "Quarkus uber-jar" is no longer really recommended.

A zip/tgz also allows us to include our own files (LICENSE/NOTICE or some README or whatever) in a "prominent place" next to some run.sh.

[jbonofre]

I agree with @snazy : I also prefer distributions (not far jar).
Also I would advocate to have several modules with beans that people can use in their own packaging (I don't say now but something we should consider at some point).

[adutra]

It would be the fat jar (and the docker images).

I'm sorry, stupid typo 😆 : I meant FAST jar, not fat jar.

So to summarize: the quarkus-server module currently builds:

• the FAST jar
• all the application data files and dependency jars, in build/quarkus-app
• Two distributions, zip and tar.gz, that contain the contents of build/quarkus-app + the NOTICE and LICENSE-BINARY-DIST files (the latter being renamed to LICENSE)
• A docker image named apache/polaris with two tags: latest and the version number.

[dimas-b]

Sorry about the confusion, but my concern is about what will be published in Maven, because that is what downstream projects will use in their respective builds (I assume).

Would it be possible to pull a Maven dependency with Polaris service classes but without any other jars added by Quarkus during its build (downstream builds will have different sets of dependencies in the server).

[adutra]

my concern is about what will be published in Maven

That's indeed the question. I bet it will be the FAST jar, but we need to check. I also think that the distributions would be attached as build artifacts, but with different classifiers (this also needs checking).

[snazy]

my concern is about what will be published in Maven

That's indeed the question. I bet it will be the FAST jar, but we need to check. I also think that the distributions would be attached as build artifacts, but with different classifiers (this also needs checking).

Maven artifacts published to Maven Central MUST have a pom, a jar, a sources jar and a javadoc jar. Other artifacts (e.g. a zip or a tgz) can be published as well - that works fine.

[dimas-b]

Publishing the "fast" jar LGTM 👍