Overall, I see some additional things which we should probabily map into Jira Issues, so others can participate and grab some issues / tasks:
- (a) Run the BOM generation in every build (via exec-maven-plugin). - (b) Update the other examples to use the BOMs. Organisational question: Same procedere as for the translation efforts: Jira issue per example + overview issue to split the work across many people? - (c) Add a not null check in TomEESecurityServletAuthenticationMechanismMapper (see [1]) and remove the exclusion in the related example (as discussed in [1]). Overall, the build should be green again when [2] is merged. Thanks @ Vicente for your PR. Gruss Richard [1] https://github.com/apache/tomee/pull/779#discussion_r607192663 Am Samstag, den 03.04.2021, 16:45 -0700 schrieb David Blevins: > > On Apr 3, 2021, at 4:06 PM, Vicente Rossello < > > [email protected]> wrote: > > > > Nevermind, I saw GenerateBom class before but didn't remember.... > > So I > > guess I can change used xmlsec and wss4j dependencies everywhere > > and > > regenerate those BOM, is that correct? > > That's right. The boms are generated analyzing the actual server > zips, so if we want to change a dep in the bom we just need to > upgrade the library used in the actual server zips and then > regenerate. > > Ideally we setup GenerateBom to run on every build so people don't > have to magically know it's a thing that should be done and how to do > it. Looks like Jean-Louis setup the `exec-maven-plugin` in the > `tomee-bootstrap` module, but it doesn't seem to be running. > > Thanks for the PR, Vicente! I'll take a look. > > > -David > > > > On Sun, Apr 4, 2021 at 1:04 AM Vicente Rossello < > > [email protected]> > > wrote: > > > > > Hi, > > > > > > May I ask how are those boms generated? > > > > > > I'm trying to fix "EJB WebService with WS-Security" but what I > > > can see is > > > that CXF is using xmlsec 2.2.1, but BOMs are generated with > > > 2.1.4. I'm not > > > sure on how to fix this. > > > > > > I fixed some simple ones in > > > https://github.com/apache/tomee/pull/779/files > > > > > > > > > > > > Vicente. > > > > > > > > > On Sat, Apr 3, 2021 at 11:43 PM Vicente Rossello < > > > [email protected]> > > > wrote: > > > > > > > Ok, let me take a look at it tomorrow, I'll see what I can do > > > > > > > > On Sat, Apr 3, 2021 at 9:06 PM David Blevins < > > > > [email protected]> > > > > wrote: > > > > > > > > > Excellent. > > > > > > > > > > I've just updated the pom generation code to create all the > > > > > "-api" > > > > > modules, published snapshots, and tried it out on a couple > > > > > examples: > > > > > > > > > > TomEE WebProfile example > > > > > - > > > > > https://github.com/apache/tomee/commit/f0d09e3438036e32b37048968538c38c49ba7d14 > > > > > > > > > > TomEE MicroProfile example > > > > > - > > > > > https://github.com/apache/tomee/commit/97f7e4b5038216891b711506689e144d4eae47ae > > > > > > > > > > Now we just need help updating all the examples like this. > > > > > > > > > > Vicente, would you be open to updating the examples that > > > > > broke after the > > > > > CXF upgrade? Looks like most of them are web service > > > > > examples, so the new > > > > > tomee-plus-api and tomee-plus dependencies would probably > > > > > work. > > > > > > > > > > - > > > > > https://builds.apache.org/job/Tomee/job/master-build-full/137/ > > > > > > > > > > Anyone else interested in helping out? > > > > > > > > > > > > > > > > > > > > -David > > > > > > > > > > > > > > > > > > > > > On Apr 3, 2021, at 2:37 AM, Zowalla, Richard < > > > > > [email protected]> wrote: > > > > > > Hi David, > > > > > > > > > > > > thanks for the this thread! > > > > > > > > > > > > I like the idea of using the generated BOMs in our examples > > > > > > rather than > > > > > > adding libraries by hand (and updating them all the time). > > > > > > > > > > > > Sometimes it will be necassary to still add some additional > > > > > > libs in the > > > > > > examples, but overall it will make it easier to maintain > > > > > > the examples > > > > > > (as long as we get the habit of regenerating the BOMs after > > > > > > library > > > > > > updates). > > > > > > > > > > > > Related to the "*-api" idea: Probably yes. Would be somehow > > > > > > natural to > > > > > > have an "api" and an "impl"-thing (even if it not called > > > > > > impl). > > > > > > > > > > > > I just tested it locally with one of the failing tests and > > > > > > it worked > > > > > > perfectly. So I am +1 here. > > > > > > > > > > > > Gruss > > > > > > Richard > > > > > > > > > > > > Am Freitag, den 02.04.2021, 15:09 -0700 schrieb David > > > > > > Blevins: > > > > > > > Richard mentioned some examples were broken after a > > > > > > > recent library > > > > > > > upgrade and I promised to start a thread on the topic as > > > > > > > we have > > > > > > > system issues there. > > > > > > > > > > > > > > One of the things that's aways bugged me and was on the > > > > > > > "some day" > > > > > > > list is that in our examples we are encouraging people to > > > > > > > have to > > > > > > > know how to put together the right dependencies to get a > > > > > > > working > > > > > > > container for plain unit testing. > > > > > > > > > > > > > > Some examples show `openejb-core` and `javaee-api`, some > > > > > > > show > > > > > > > `openejb-cxf-rs`, some show just `openejb-cxf`, some show > > > > > > > `tomee- > > > > > > > jaxrs`, some also pull in specific dependencies like > > > > > > > `cxf-rt-rs- > > > > > > > client`, some add a specific MicroProfile API. > > > > > > > > > > > > > > None of this documented anywhere, you just have to > > > > > > > "know". And any > > > > > > > time we upgrade our dependencies, users must upgrade > > > > > > > theirs. Any > > > > > > > time we change our excludes or mark things provided, > > > > > > > users need to > > > > > > > add dependencies they weren't informed they now > > > > > > > need. We're setting > > > > > > > people up for failure and frustration. Side note, this > > > > > > > is one of the > > > > > > > reasons I really like having the examples in the main > > > > > > > codebase as it > > > > > > > helps to keep us honest -- we experience the same things > > > > > > > in our build > > > > > > > users experience in theirs. > > > > > > > > > > > > > > Some months back I wrote some code that will inspect a > > > > > > > TomEE server > > > > > > > zip and generate a pom from it. The poms have zero > > > > > > > transitive > > > > > > > dependencies, every dependency is explicitly listed and > > > > > > > it is > > > > > > > therefore library to library identical to the zip, but > > > > > > > usable as a > > > > > > > plain maven dependency. There is one for each of our > > > > > > > servers: > > > > > > > > > > > > > > <dependency> > > > > > > > <groupId>org.apache.tomee.bom</groupId> > > > > > > > <artifactId>tomee-webprofile</artifactId> > > > > > > > <version>8.0.7-SNAPSHOT</version> > > > > > > > </dependency> > > > > > > > <dependency> > > > > > > > <groupId>org.apache.tomee.bom</groupId> > > > > > > > <artifactId>tomee-microprofile</artifactId> > > > > > > > <version>8.0.7-SNAPSHOT</version> > > > > > > > </dependency> > > > > > > > <dependency> > > > > > > > <groupId>org.apache.tomee.bom</groupId> > > > > > > > <artifactId>tomee-plus</artifactId> > > > > > > > <version>8.0.7-SNAPSHOT</version> > > > > > > > </dependency> > > > > > > > <dependency> > > > > > > > <groupId>org.apache.tomee.bom</groupId> > > > > > > > <artifactId>tomee-plume</artifactId> > > > > > > > <version>8.0.7-SNAPSHOT</version> > > > > > > > </dependency> > > > > > > > > > > > > > > I recommend we take this opportunity to go through all > > > > > > > the examples > > > > > > > and replace the use of individual TomEE dependencies in > > > > > > > favor of one > > > > > > > of the dependencies above. Once we've done that, the > > > > > > > odds of our > > > > > > > users or our examples being affected by library changes > > > > > > > drops > > > > > > > significantly. > > > > > > > > > > > > > > In writing this, the one gap I see is that we probably > > > > > > > want an > > > > > > > equivalent API pom for each server dist. Our examples > > > > > > > tend to have > > > > > > > javaee-api marked as scope `provided` and the server jars > > > > > > > marked with > > > > > > > scope `test` so code in `src/main/java` isn't depending > > > > > > > on our > > > > > > > internals. We could have an additional "api" pom that > > > > > > > contains the > > > > > > > javaee-api jar, all microprofile-*.jar api jars and any > > > > > > > API jars we > > > > > > > provide ourselves (at the moment that's just openejb- > > > > > > > api.jar). > > > > > > > > > > > > > > That might give us examples that look like this in > > > > > > > practice: > > > > > > > > > > > > > > <dependency> > > > > > > > <groupId>org.apache.tomee.bom</groupId> > > > > > > > <artifactId>tomee-microprofile-api</artifactId> > > > > > > > <version>8.0.7-SNAPSHOT</version> > > > > > > > <scope>provided</scope> > > > > > > > </dependency> > > > > > > > <dependency> > > > > > > > <groupId>org.apache.tomee.bom</groupId> > > > > > > > <artifactId>tomee-microprofile</artifactId> > > > > > > > <version>8.0.7-SNAPSHOT</version> > > > > > > > <scope>test</scope> > > > > > > > </dependency> > > > > > > > > > > > > > > It's tempting to think, "maybe the second dependency > > > > > > > should have an > > > > > > > 'impl' suffix?" I asked myself, thought through it and > > > > > > > came out on > > > > > > > the "no" side. There will be people who just want the > > > > > > > one dependency > > > > > > > that has everything. Specifically anyone using TomEE in > > > > > > > an embedded > > > > > > > fashion, as plain libraries, or aiming to create an uber > > > > > > > jar. It's > > > > > > > only people who intend to deploy to a TomEE zip who > > > > > > > need/want the two > > > > > > > differently scoped dependencies. I also think to when > > > > > > > I'm using > > > > > > > Arquillian and there is an "api" and "impl" jar for > > > > > > > literally > > > > > > > everything and I forget to add one or the other, things > > > > > > > fail, and I > > > > > > > think "seriously, I'm never going to chose a different > > > > > > > implementation, why are you making me do this?" It's all > > > > > > > the more > > > > > > > frustrating as you know darn well the impl dep needs a > > > > > > > very specific > > > > > > > version of that api dep -- you can't just use an older or > > > > > > > newer api > > > > > > > version and expect things to work. Therefore I think > > > > > > > having an > > > > > > > "everything" dep and an "apis-only" dep is just fine. > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > >
