+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 (< [email protected]>) 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 < > [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? > > > > > > > > > -- Atentamente: César Hernández.
