> > On Apr 6, 2021, at 10:37 AM, Zowalla, Richard <
> >
[hidden email]> 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 <
> > > >
[hidden email]> 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 <
> > > >
[hidden email]>
> > > > 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 <
> > > > >
[hidden email]>
> > > > > 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 <
> > > > > >
[hidden email]>
> > > > > > 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 <
> > > > > > >
[hidden email]> 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?
> > > > > > > > >
> > > > > > > > >