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 <cocorosse...@gmail.com> 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 <david.blev...@gmail.com> > 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 < >> richard.zowa...@hs-heilbronn.de> 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? >> >> >> >> >> >>
