> On Apr 6, 2021, at 10:37 AM, Zowalla, Richard > <[email protected]> wrote: > > 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]).
This looks like a good approach. In the past I used to use a jira command line tool (swizzle jira) I wrote to file those subtasks of the parent task. I.e. so things like this were not too difficult: - https://issues.apache.org/jira/browse/OPENEJB-142 If there was good java client, I could very quickly whip up a nice CLI with Crest. -David > > [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? >>>>>>>> >>>>>>>>
smime.p7s
Description: S/MIME cryptographic signature
