[GitHub] [camel-quarkus] ppalaga commented on a diff in pull request #4808: [2.13.x] Remove javax.servlet-api exclusion from jetty-server

["ppalaga (via GitHub)" <gi...@apache.org>]

ppalaga commented on code in PR #4808:
URL: https://github.com/apache/camel-quarkus/pull/4808#discussion_r1172334757


##########
poms/bom/pom.xml:
##########
@@ -7249,10 +7249,6 @@
                                     <gavPattern>org.apache.kafka:connect-api</gavPattern>
                                     <addExclusions>javax.ws.rs:javax.ws.rs-api</addExclusions>
                                 </autogeneratedBomEntryTransformation>
-                                <autogeneratedBomEntryTransformation>
-                                    <gavPattern>org.eclipse.jetty:jetty-server</gavPattern>
-                                    <addExclusions>javax.servlet:javax.servlet-api</addExclusions>
-                                </autogeneratedBomEntryTransformation>

Review Comment:
   Unfortunately, this will come back with the next `mvn process-resources -Dcq.flatten-bom.format`. These autogenerated exclusions are driven by banned dependencies defined by us in [tooling/enforcer-rules/camel-quarkus-banned-dependencies.xml](https://github.com/apache/camel-quarkus/blob/main/tooling/enforcer-rules/camel-quarkus-banned-dependencies.xml) or by [Quarkus](https://github.com/quarkusio/quarkus/blob/main/independent-projects/enforcer-rules/src/main/resources/enforcer-rules/quarkus-banned-dependencies.xml). javax.servlet:javax.servlet-api comes from Quarkus. There is currently no way to tell cq-maven-plugin to ignore some specific banned artifact only for some specific dependent, like we'd need here. It's now only possible to remove javax.servlet:javax.servlet-api from quarkus banns via XSLT in [tooling/enforcer-rules/quarkus-banned-dependencies.xsl](https://github.com/apache/camel-quarkus/blob/main/tooling/enforcer-rules/quarkus-banned-dependencies.xsl). I do not think w
 e should do that. 
   We could enhance cq plugin to be able to do these fine grained un-exclusions but I wonder if there are easier ways? 
   
   Maybe we could stop managing jetty in the application bom and perhaps not manage it at all or manage it only in the test bom? 
   
   Or we could perhaps upgrade to WireMock 3.x that runs on top of Jetty 11? [Here](https://github.com/wiremock/wiremock/issues/1760) they say they have -standalone artifacts, which perhaps shade jetty so the would be no conflict with those two JVM extensions using Jetty 9?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org