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 < [email protected]> 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? > > > > >
