I don't think we have a formal policy re this, although it's possible we do and it's just been followed so long that in my mind 'policy' and 'current practice' have blended into one in my head. ;) Let's think about it in terms of what our requirements should be, and then the technical solution needs to follow that agreed upon requirements. Some thoughts I have: 1) The process we use for defining dependencies needs to be solid and unambiguous. If someone understands how we do it they should be able to work out what versions are used by the server. Without having to use mvn dependency:tree mvn help:effective-pom etc. Using those might be the fast way to check what we use, but someone who understands what we do should be able to figure it out from looking at poms. 2) A nice-to-have is making things relatively simple, i.e. 'someone who understands what we do' shouldn't be limited to a handful of gurus. At least any lead for a WFLY / WFCORE JIRA component should understand. 3) We import a bom from WildFly Core and what we import should take precedence over anything else, except for an explicit declaration of a specific GAV in wildfly's boms. IOW if Core says foo:bar:1.2.3 and an otel bom said foo.bar:1.2.4, then core wins, and use of 1.2.4 requires an explicit entry for that GAV. 4) If we change the WildFly component set we should have a JIRA that describes what actual components changed, not just that there was a bom update. (If project X produces 5 components as part of the same release we don't need to list them all, but if an imported bom updates X and also its dependency Y, we need the JIRA to note X and Y, not just 'X bom update'. 5) The PR for the update should also be explicit about what artifacts are upgraded, beyond the obvious one (i.e. X in my example in #4.) This makes it efficient to ask component leads for other uses of the affected libs (i.e. Y) if the update is ok. 6) We should continue to add the RN or git diff into to the JIRAs, the way we have over the last couple years. I find that very useful, but won't blab on about why. ;) 7) We need to be able to exclude transitive dependencies to avoid ambiguity in what we support, to avoid things creeping into end user boms or getting irrelevant CVE scanner hits for things we don't even use. HTH, Brian On Fri, Nov 11, 2022 at 9:18 AM Jason Lee <jasondlee(a)redhat.com&gt; wrote: > Do we have a policy on importing third party boms (in > boms/common-ee/pom.xml, for example)? The OpenTelemetry project provides a > BOM to help synchronize artifact versions. I'm currently declaring > dependency with explicit versions (controlled by a Maven property, of > course) for each dependency. Things get tricky for otel as some artifacts > are $VERSION and some are ${VERSION}-alpha. Using a BOM would make that > transparent (as well as making the eventual transition from -alpha to ga > transparent). > > I don't see any BOMs being imported, so I thought I'd ask before I tried > to be first. :) > > Jason Lee > > Principal Software Engineer > > Red Hat JBoss EAP > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

I don't think we have a formal policy re this, although it's possible we do and it's just been followed so long that in my mind 'policy' and 'current practice' have blended into one in my head. ;) Let's think about it in terms of what our requirements should be, and then the technical solution needs to follow that agreed upon requirements. Some thoughts I have: 1) The process we use for defining dependencies needs to be solid and unambiguous. If someone understands how we do it they should be able to work out what versions are used by the server. Without having to use mvn dependency:tree mvn help:effective-pom etc. Using those might be the fast way to check what we use, but someone who understands what we do should be able to figure it out from looking at poms. 2) A nice-to-have is making things relatively simple, i.e. 'someone who understands what we do' shouldn't be limited to a handful of gurus. At least any lead for a WFLY / WFCORE JIRA component should understand.

3) We import a bom from WildFly Core and what we import should take precedence over anything else, except for an explicit declaration of a specific GAV in wildfly's boms. IOW if Core says foo:bar:1.2.3 and an otel bom said foo.bar:1.2.4, then core wins, and use of 1.2.4 requires an explicit entry for that GAV.

4) If we change the WildFly component set we should have a JIRA that describes what actual components changed, not just that there was a bom update. (If project X produces 5 components as part of the same release we don't need to list them all, but if an imported bom updates X and also its dependency Y, we need the JIRA to note X and Y, not just 'X bom update'.

5) The PR for the update should also be explicit about what artifacts are upgraded, beyond the obvious one (i.e. X in my example in #4.) This makes it efficient to ask component leads for other uses of the affected libs (i.e. Y) if the update is ok. 6) We should continue to add the RN or git diff into to the JIRAs, the way we have over the last couple years. I find that very useful, but won't blab on about why. ;)

7) We need to be able to exclude transitive dependencies to avoid ambiguity in what we support, to avoid things creeping into end user boms or getting irrelevant CVE scanner hits for things we don't even use.

HTH, Brian On Fri, Nov 11, 2022 at 9:18 AM Jason Lee <jasondlee(a)redhat.com&gt; wrote: > Do we have a policy on importing third party boms (in > boms/common-ee/pom.xml, for example)? The OpenTelemetry project provides a > BOM to help synchronize artifact versions. I'm currently declaring > dependency with explicit versions (controlled by a Maven property, of > course) for each dependency. Things get tricky for otel as some artifacts > are $VERSION and some are ${VERSION}-alpha. Using a BOM would make that > transparent (as well as making the eventual transition from -alpha to ga > transparent). > > I don't see any BOMs being imported, so I thought I'd ask before I tried > to be first. :) > > Jason Lee > > Principal Software Engineer > > Red Hat JBoss EAP > > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

On Fri, Nov 11, 2022 at 10:25 PM James Perkins <jperkins(a)redhat.com&gt; wrote: > > > On Fri, Nov 11, 2022 at 8:01 AM Brian Stansberry < > brian.stansberry(a)redhat.com&gt; wrote: > >> I don't think we have a formal policy re this, although it's possible we >> do and it's just been followed so long that in my mind 'policy' and >> 'current practice' have blended into one in my head. ;) >> >> Let's think about it in terms of what our requirements should be, and >> then the technical solution needs to follow that agreed upon requirements. >> Some thoughts I have: >> >> 1) The process we use for defining dependencies needs to be solid and >> unambiguous. If someone understands how we do it they should be able to >> work out what versions are used by the server. Without having to use >> mvn dependency:tree mvn help:effective-pom etc. Using those might be the >> fast way to check what we use, but someone who understands what we do >> should be able to figure it out from looking at poms. >> >> 2) A nice-to-have is making things relatively simple, i.e. 'someone who >> understands what we do' shouldn't be limited to a handful of gurus. At >> least any lead for a WFLY / WFCORE JIRA component should understand. >> > > +1 > > >> >> 3) We import a bom from WildFly Core and what we import should take >> precedence over anything else, except for an explicit declaration of a >> specific GAV in wildfly's boms. IOW if Core says foo:bar:1.2.3 and an otel >> bom said foo.bar:1.2.4, then core wins, and use of 1.2.4 requires an >> explicit entry for that GAV. >> > > This can be done, but the order matters. We just need to ensure WildFly > Core's BOM is always first. > https://maven.apache.org/guides/introduction/introduction-to-dependency-m... > > >> >> 4) If we change the WildFly component set we should have a JIRA that >> describes what actual components changed, not just that there was a bom >> update. (If project X produces 5 components as part of the same release we >> don't need to list them all, but if an imported bom updates X and also its >> dependency Y, we need the JIRA to note X and Y, not just 'X bom update'. >> > > This is an interesting point. For argument's sake, let's say two BOM's > include the same dependency. Should we explicitly define that dependency > instead of inheriting from one BOM? If that is the case this becomes less > of an issue I would think. > > >> >> 5) The PR for the update should also be explicit about what artifacts >> are upgraded, beyond the obvious one (i.e. X in my example in #4.) This >> makes it efficient to ask component leads for other uses of the affected >> libs (i.e. Y) if the update is ok. >> >> 6) We should continue to add the RN or git diff into to the JIRAs, the >> way we have over the last couple years. I find that very useful, but won't >> blab on about why. ;) >> > > A big +1 here. It really helps. We don't need to go this far, but > dependabot does makes really nice PR notes when it knows about a project :) > Especially if you use GitHub releases. As an example > https://github.com/wildfly/wildfly-arquillian/pull/258. > > >> >> 7) We need to be able to exclude transitive dependencies to avoid >> ambiguity in what we support, to avoid things creeping into end user >> boms or getting irrelevant CVE scanner hits for things we don't even use. >> > > One thing to note here is exclusions don't work on import BOM's. That > said, they also don't show up as dependencies in the dependency tree. > > Yes, my understanding is we need to explicitly declare the dependency in order to pick it up from the bom and to get it shown in the dependency tree. About why the exclusion doesn't work on import bom, I don't know the reason. In any case, and in general from the exclusions of regular dependencies point of view, instead of using exclusions, what we should do is explicitly declare what we want in the WildFly standard maven boms. Depending on tweaks per dependency to pick up what we want from the transitive dependency graph is weak if we want to have all dependencies under control. That will increase the list of explicit dependencies, which also brings up some disadvantages, although that is what we have been doing with the Jakarta EE 10 ones.

If a dependency is explicitly defined in a child pom that uses any of the WIldFly Standard boms in its dependency management section, we do not need to exclude anything from any dependency, because the explicit declaration should be used instead of any of the transitive ones. Please, correct me if I am wrong.

> >> HTH, >> >> Brian >> >> On Fri, Nov 11, 2022 at 9:18 AM Jason Lee <jasondlee(a)redhat.com&gt; wrote: >> >>> Do we have a policy on importing third party boms (in >>> boms/common-ee/pom.xml, for example)? The OpenTelemetry project provides a >>> BOM to help synchronize artifact versions. I'm currently declaring >>> dependency with explicit versions (controlled by a Maven property, of >>> course) for each dependency. Things get tricky for otel as some artifacts >>> are $VERSION and some are ${VERSION}-alpha. Using a BOM would make that >>> transparent (as well as making the eventual transition from -alpha to ga >>> transparent). >>> >>> I don't see any BOMs being imported, so I thought I'd ask before I >>> tried to be first. :) >>> >>> Jason Lee >>> >>> Principal Software Engineer >>> >>> Red Hat JBoss EAP >>> >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> >> >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > > > -- > James R. Perkins > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s