Make SplitPackageProcessor configurable

[famod]

Description

With 2.1.0 we are getting:

[WARNING] [io.quarkus.arc.deployment.SplitPackageProcessor] Detected a split package usage which is considered a bad practice and should be avoided. Following packages were detected in multiple archives: 
- "org.w3._2000._09.xmldsig_" found in [de.somecompany.someproject:register-webservice-a, de.somecompany.someproject:register-webservice-b]

because we a generating stubs from WSDL in two different Maven modules (via cxf-codegen-plugin).

I do get the point of avoiding split packages, but in this case I don't think our valuable project time is well invested in trying to separate (or unify) those generated packages. They are not subject to any injection anyway.

Therefore it would come in handy, if that processor could be configured in some way, e.g. add exclusions etc.

Implementation ideas

No response

[quarkus-bot]

/cc @manovotn, @mkouba

[mkouba]

We could easily implement this but I'm not quite it's worth the effort, i.e. to introduce a config property just to suppress some warnings. In theory, you should be able to set the log level to ERROR for the io.quarkus.arc.deployment.SplitPackageProcessor logger to suppress all warnings...

[famod]

Sure, I can suppress all warnings but this way I might miss warnings that are actually more relevant for me/my project.

[famod]

Sure, I can suppress all warnings

Well, spoke too soon: I failed at silencing it via logging config. Even tried adding:

<argLine>-Dquarkus.log.category."io.quarkus.arc.deployment.SplitPackageProcessor".level=ERROR</argLine>

to surefire to get rid of the warnings in #19030 but nope...

[mkouba]

Sure, I can suppress all warnings but this way I might miss warnings that are actually more relevant for me/my project.

No, I mean warnings from the logger of name io.quarkus.arc.deployment.SplitPackageProcessor.

to surefire to get rid of the warnings in #19030 but nope...

For tests you need to follow the steps described here: https://quarkus.io/guides/logging#how-to-configure-logging-for-quarkustest

[famod]

Sure, I can suppress all warnings but this way I might miss warnings that are actually more relevant for me/my project.

No, I mean warnings from the logger of name io.quarkus.arc.deployment.SplitPackageProcessor.

Sorry for being imprecise: I meant I would not see any warnings from that processor, even the ones that might be more relevant for me.

to surefire to get rid of the warnings in #19030 but nope...

For tests you need to follow the steps described here: https://quarkus.io/guides/logging#how-to-configure-logging-for-quarkustest

Thanks for the pointer but LogManager is already there since day one.
Besides, the warning from my initial comment/description is issued by quarkus-maven-plugin when building the app, so no tests involved there.

[manovotn]

So basically a configurable whitelist for the processor.
I am not sure it is entirely sensible and would prefer for users to either ignore all warning or solve them. OTOH, I get your point here.

It is definitely implementable, the property could pass in a list of Strings which represent different packages you want the processor to skip. I'll look into it.

[famod]

@manovotn if there was an option to switch it off it would be ok for me. I would then enable it on demand.
(to not waste your time on such a minor thing)

[geoand]

Something tells me that @manovotn got more than he bargained for when he decided to help out on the split package issue 😆

[manovotn]

@geoand It all started with good intention to let users know about split packages which may break Arc functionality.
Unfortunately, road to hell is also paved with good intentions :-D

[dhoffer]

@manovotn Can someone explain why split packages are a problem for Quarkus? We have some shared code in separate jars that use the same package names. That is perfectly fine for Java what issues does this cause for Arc/Quarkus?

[manovotn]

That is perfectly fine for Java

That's not true, JDK 11 with JPMS would complain :)

Anyway, IIRC, the issue was with proxying of beans if there types were split in packages. That could end up being an illegal access error. Some of the linked issues had a reproducer that showed that case.