Add a 'bom' to support managing dependencies

[mattrpav]

No description provided.

[grgrzybek]

I understand you mean a BOM only with org.ops4j.pax.web.* groupId artifacts, right? Wiithout tests and samples?

[mattrpav]

It should include org.ops4j.pax.web groupId artifacts, and dependencies. Basically, anything listed in a pax-web-* feature, so downstream users can simply reference 'org.eclipse.jetty/jetty-server' and the version is managed.

For example:
jetty-continuation, jetty-deploy, jetty-http, jetty-io, jetty-plus, jetty-proxy, etc

• org.ops4j.pax.web artifacts
• org.ops4j.pax.web feature xml
• dependencies (ie. jetty, tomcat, undertow, etc)

[mattrpav]

Come to think of it, pax-web might need separate boms if there are any overlap of transitive deps for pax-web-jetty vs pax-web-tomcat vs pax-web-undertow.

[grgrzybek]

And the "dependencies" part is what I was afraid of... Because it'd include JavaEE APIs (even the fundamental one - jakarta.servlet/jakarta.servlet-api - but what if someone wants to use Geronimo/JBoss/SMX/Javax version of it?
I'll check and see where it's heading ;).

[mattrpav]

The pom section used in a bom is dependencyManagement. You can list all the servlet api options without them being transitive.

The dependencyManagement does not mean dependency, it only sets version and scope when referenced by child poms in a dependency section.

See: https://github.com/apache/karaf/blob/main/bom/pom.xml

[grgrzybek]

yes yes yes, I just work with BOMs for last few years and I know how messy they can be ;)
If Jetty/Tomcat/Undertow bundles bring in their own deps, it's sometimes hard to choose.

I like the clean approach of https://repo1.maven.org/maven2/org/springframework/spring-framework-bom/5.3.23/spring-framework-bom-5.3.23.pom - it lists only own managed dependencies.

[mattrpav]

@grgrzybek what is a scenario that breaks with boms?

If child project imports 2 boms that have different versions, maven will resolve one and the user has the option of using the resolved, or overriding version and scope.

The problem with only using ‘own’ managed deps is that there is now a gap from what is listed in the feature. For building offline repos (ie. pax-web + cxf) requires surgery.

[grgrzybek]

Yes, I understand. We could start with "project-bom" that lists only Pax Web managed deps and add optional, convenient "all-bom" (or "dev-bom", or "user-bom") that lists current dependencies (for example if there was Jetty BOM, I could use it there.

The point is that I prefer managing my own dependencies than include one BOM. I trust Spring Framework BOM, but for example, Spring Boot BOM is just too much - I want to control more. But that's personal approach.

Let me thing about it - maybe you could create a PR with a suggestion?