On Mon, Nov 14, 2022 at 3:11 AM Yeray Borges Santana <yborgess@redhat.com> wrote:

On Fri, Nov 11, 2022 at 10:25 PM James Perkins <jperkins@redhat.com> wrote:

On Fri, Nov 11, 2022 at 8:01 AM Brian Stansberry <brian.stansberry@redhat.com> 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-mechanism.html#importing-dependencies

 

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.

I think for test and client dependencies that is okay. However, for subsystem/extension/api dependencies I think we should use wildcard excludes and explicitly include what we need. I say that because we have to create the module graph as well.

The clients, which aren't many, are a bit different IMO. We do need to be careful though that what we ship is what we test. In other words we shouldn't just allow a transitive dependency for testing, but we ship a different version.

 

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.

If I'm understanding correctly, yes I think that sounds correct.

 

 

HTH,

Brian

On Fri, Nov 11, 2022 at 9:18 AM Jason Lee <jasondlee@redhat.com> 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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

--

James R. Perkins

JBoss by Red Hat