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?
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? >>> >> >>> >> >>> >>>
