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-unsubscr...@camel.apache.org

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

Reply via email to