Permanently Fixing examples after library upgrades

[David Blevins-2]

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?


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

[Zowalla, Richard]

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

[Daniel Dias Dos Santos]

Hello David,

+1 for the idea, it will help a lot.

thanks




Em sáb., 3 de abr. de 2021 às 06:37, Zowalla, Richard <
[hidden email]> escreveu:

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

[David Blevins-2]

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

[cocorossello]

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

[cocorossello]

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

[cocorossello]

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

[David Blevins-2]

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

[Zowalla, Richard]

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

[David Blevins-2]

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

[Zowalla, Richard]

Hi,

(a) https://issues.apache.org/jira/browse/TOMEE-3000

(b) I only know the "jira-rest-java-client-core" provided by Atlassian
(see
https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2
) - might be worth a try? Sadly, it will only work with the self-hosted
Jira Server instance. I do not know, if ASF is using the cloud-hosted
approach offered by Atlassian...

(c) https://issues.apache.org/jira/browse/TOMEE-3001

Gruss
Richard

Am Mittwoch, den 07.04.2021, 17:05 -0700 schrieb David Blevins:

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

--

Richard Zowalla, M.Sc.
Research Associate, PhD Student | Medical Informatics

Hochschule Heilbronn – University of Applied Sciences
Max-Planck-Str. 39
D-74081 Heilbronn
phone: [phone]
mail: [hidden email]
web: https://www.mi.hs-heilbronn.de/ 

[David Blevins-2]

> On Apr 8, 2021, at 12:12 AM, Zowalla, Richard <[hidden email]> wrote:
>
> (b) I only know the "jira-rest-java-client-core" provided by Atlassian
> (see
> https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2
> ) - might be worth a try? Sadly, it will only work with the self-hosted
> Jira Server instance. I do not know, if ASF is using the cloud-hosted
> approach offered by Atlassian...


Apache does self-host, so we're good on that front assuming there aren't specific options that need to be enabled.

I don't want to take too much of my time away from TCK work, but I'll see if I can create a small CLI for the jira-rest-java-client-core.  We could use it to file JIRAs for the remaining TCK failures so we could divide and conquer on that too.

If we could get even one or two more people helping there it'd make a huge difference.  When we did the long march to Java EE 6 Web Profile compliance, we had about 4 or 5 of us working on it after hours in bursts, averaging what felt like about 1.5 FTEs at any given time.  Every little bit helps.  Even getting 2 or 3 more people doing one test each would have a very big impact.

I think with the current status, no one knows who is working on what test so people are more inclined to stay out of the way.  Some JIRAs can definitely fix/improve that.

We actually couldn't file JIRAs for the remaining failing tests when we did Java EE 6 as the TCK at that time was commercially licensed and under NDA.  We don't have that issue any more :)


-David

[David Blevins-2]

> On Apr 8, 2021, at 12:52 PM, David Blevins <[hidden email]> wrote:

>
>> On Apr 8, 2021, at 12:12 AM, Zowalla, Richard <[hidden email]> wrote:
>>
>> (b) I only know the "jira-rest-java-client-core" provided by Atlassian
>> (see
>> https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2
>> ) - might be worth a try? Sadly, it will only work with the self-hosted
>> Jira Server instance. I do not know, if ASF is using the cloud-hosted
>> approach offered by Atlassian...
>
> I don't want to take too much of my time away from TCK work, but I'll see if I can create a small CLI for the jira-rest-java-client-core.  We could use it to file JIRAs for the remaining TCK failures so we could divide and conquer on that too.

I've gone ahead and created nice little JIRA CLI

 - https://twitter.com/dblevins/status/1381073496453775360

Did my best to document it so if you or anyone wanted to create tasks around updating examples it should be a bit easier.

I did use it to create issues for all the remaining TCK failures, but I'll post on that in a different thread.


-David

[Zowalla, Richard]

Hi David,

thanks for the CLI (worked smoothly - but note for future users: do not
try to create 174 subtasks at once without increasing http timeouts...)
and sorry for the spam on commit@

I just created the related issue (TOMEE-3234) and all related sub-tasks
for the examples, which are not yet transformed to the server / api bom
approach.

I think the focus is now on the TCK (I will hopefully find some time!),
but we have the complete example list for the BOM transformation in
JIRA.


Gruss
Richard

Am Samstag, den 10.04.2021, 19:42 -0700 schrieb David Blevins:

> > On Apr 8, 2021, at 12:52 PM, David Blevins <[hidden email]
> > > wrote:
> >
> > > On Apr 8, 2021, at 12:12 AM, Zowalla, Richard <
> > > [hidden email]> wrote:
> > >
> > > (b) I only know the "jira-rest-java-client-core" provided by
> > > Atlassian
> > > (see
> > > https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2
> > > ) - might be worth a try? Sadly, it will only work with the self-
> > > hosted
> > > Jira Server instance. I do not know, if ASF is using the cloud-
> > > hosted
> > > approach offered by Atlassian...
> >
> > I don't want to take too much of my time away from TCK work, but
> > I'll see if I can create a small CLI for the jira-rest-java-client-
> > core.  We could use it to file JIRAs for the remaining TCK failures
> > so we could divide and conquer on that too.
>
> I've gone ahead and created nice little JIRA CLI
>
>  - https://twitter.com/dblevins/status/1381073496453775360
>
> Did my best to document it so if you or anyone wanted to create tasks
> around updating examples it should be a bit easier.
>
> I did use it to create issues for all the remaining TCK failures, but
> I'll post on that in a different thread.
>
>
> -David
>
>

[David Blevins-2]

> On Apr 12, 2021, at 4:37 AM, Zowalla, Richard <[hidden email]> wrote:
>
> Hi David,
>
> thanks for the CLI (worked smoothly - but note for future users: do not
> try to create 174 subtasks at once without increasing http timeouts...)
> and sorry for the spam on commit@

We should definitely fix that.  Creating 174 subtasks is exactly the goal! :)

> I just created the related issue (TOMEE-3234) and all related sub-tasks
> for the examples, which are not yet transformed to the server / api bom
> approach.

Very excellent!


-David

> Am Samstag, den 10.04.2021, 19:42 -0700 schrieb David Blevins:
>>> On Apr 8, 2021, at 12:52 PM, David Blevins <[hidden email]
>>>> wrote:
>>>
>>>> On Apr 8, 2021, at 12:12 AM, Zowalla, Richard <
>>>> [hidden email]> wrote:
>>>>
>>>> (b) I only know the "jira-rest-java-client-core" provided by
>>>> Atlassian
>>>> (see
>>>> https://mvnrepository.com/artifact/com.atlassian.jira/jira-rest-java-client-core/5.2.2
>>>> ) - might be worth a try? Sadly, it will only work with the self-
>>>> hosted
>>>> Jira Server instance. I do not know, if ASF is using the cloud-
>>>> hosted
>>>> approach offered by Atlassian...
>>>
>>> I don't want to take too much of my time away from TCK work, but
>>> I'll see if I can create a small CLI for the jira-rest-java-client-
>>> core.  We could use it to file JIRAs for the remaining TCK failures
>>> so we could divide and conquer on that too.
>>
>> I've gone ahead and created nice little JIRA CLI
>>
>> - https://twitter.com/dblevins/status/1381073496453775360
>>
>> Did my best to document it so if you or anyone wanted to create tasks
>> around updating examples it should be a bit easier.
>>
>> I did use it to create issues for all the remaining TCK failures, but
>> I'll post on that in a different thread.
>>
>>
>> -David
>>
>>

[Cesar Hernandez]

+1 for the generated BOM's.
I see there is another thread with already work in progress [1] So I'll
follow up there since one of the tests I want to make is to perform a
maven release:prepare and check if the versions from the Examples (with our
without Boom) are all updated.

[1]
https://lists.apache.org/thread.html/r4ba417fe29a55e45bee4feb33ba646331aaf4289ba0654062c1a0a36%40%3Cdev.tomee.apache.org%3E

El sáb, 3 abr 2021 a las 12:55, Daniel Dias Dos Santos (<
[hidden email]>) escribió:

> Hello David,
>
> +1 for the idea, it will help a lot.
>
> thanks
>
>
>
>
> Em sáb., 3 de abr. de 2021 às 06:37, Zowalla, Richard <
> [hidden email]> escreveu:
>
> > 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?
> > >
> > >
> >
>

--
Atentamente:
César Hernández.