Ok, let me take a look at it tomorrow, I'll see what I can do On Sat, Apr 3, 2021 at 9:06 PM David Blevins <[email protected]> wrote:
> Excellent. > > I've just updated the pom generation code to create all the "-api" > modules, published snapshots, and tried it out on a couple examples: > > TomEE WebProfile example > - > https://github.com/apache/tomee/commit/f0d09e3438036e32b37048968538c38c49ba7d14 > > TomEE MicroProfile example > - > https://github.com/apache/tomee/commit/97f7e4b5038216891b711506689e144d4eae47ae > > Now we just need help updating all the examples like this. > > Vicente, would you be open to updating the examples that broke after the > CXF upgrade? Looks like most of them are web service examples, so the new > tomee-plus-api and tomee-plus dependencies would probably work. > > - https://builds.apache.org/job/Tomee/job/master-build-full/137/ > > Anyone else interested in helping out? > > > > -David > > > > > On Apr 3, 2021, at 2:37 AM, Zowalla, Richard < > [email protected]> wrote: > > > > Hi David, > > > > thanks for the this thread! > > > > I like the idea of using the generated BOMs in our examples rather than > > adding libraries by hand (and updating them all the time). > > > > Sometimes it will be necassary to still add some additional libs in the > > examples, but overall it will make it easier to maintain the examples > > (as long as we get the habit of regenerating the BOMs after library > > updates). > > > > Related to the "*-api" idea: Probably yes. Would be somehow natural to > > have an "api" and an "impl"-thing (even if it not called impl). > > > > I just tested it locally with one of the failing tests and it worked > > perfectly. So I am +1 here. > > > > Gruss > > Richard > > > > Am Freitag, den 02.04.2021, 15:09 -0700 schrieb David Blevins: > >> Richard mentioned some examples were broken after a recent library > >> upgrade and I promised to start a thread on the topic as we have > >> system issues there. > >> > >> One of the things that's aways bugged me and was on the "some day" > >> list is that in our examples we are encouraging people to have to > >> know how to put together the right dependencies to get a working > >> container for plain unit testing. > >> > >> Some examples show `openejb-core` and `javaee-api`, some show > >> `openejb-cxf-rs`, some show just `openejb-cxf`, some show `tomee- > >> jaxrs`, some also pull in specific dependencies like `cxf-rt-rs- > >> client`, some add a specific MicroProfile API. > >> > >> None of this documented anywhere, you just have to "know". And any > >> time we upgrade our dependencies, users must upgrade theirs. Any > >> time we change our excludes or mark things provided, users need to > >> add dependencies they weren't informed they now need. We're setting > >> people up for failure and frustration. Side note, this is one of the > >> reasons I really like having the examples in the main codebase as it > >> helps to keep us honest -- we experience the same things in our build > >> users experience in theirs. > >> > >> Some months back I wrote some code that will inspect a TomEE server > >> zip and generate a pom from it. The poms have zero transitive > >> dependencies, every dependency is explicitly listed and it is > >> therefore library to library identical to the zip, but usable as a > >> plain maven dependency. There is one for each of our servers: > >> > >> <dependency> > >> <groupId>org.apache.tomee.bom</groupId> > >> <artifactId>tomee-webprofile</artifactId> > >> <version>8.0.7-SNAPSHOT</version> > >> </dependency> > >> <dependency> > >> <groupId>org.apache.tomee.bom</groupId> > >> <artifactId>tomee-microprofile</artifactId> > >> <version>8.0.7-SNAPSHOT</version> > >> </dependency> > >> <dependency> > >> <groupId>org.apache.tomee.bom</groupId> > >> <artifactId>tomee-plus</artifactId> > >> <version>8.0.7-SNAPSHOT</version> > >> </dependency> > >> <dependency> > >> <groupId>org.apache.tomee.bom</groupId> > >> <artifactId>tomee-plume</artifactId> > >> <version>8.0.7-SNAPSHOT</version> > >> </dependency> > >> > >> I recommend we take this opportunity to go through all the examples > >> and replace the use of individual TomEE dependencies in favor of one > >> of the dependencies above. Once we've done that, the odds of our > >> users or our examples being affected by library changes drops > >> significantly. > >> > >> In writing this, the one gap I see is that we probably want an > >> equivalent API pom for each server dist. Our examples tend to have > >> javaee-api marked as scope `provided` and the server jars marked with > >> scope `test` so code in `src/main/java` isn't depending on our > >> internals. We could have an additional "api" pom that contains the > >> javaee-api jar, all microprofile-*.jar api jars and any API jars we > >> provide ourselves (at the moment that's just openejb-api.jar). > >> > >> That might give us examples that look like this in practice: > >> > >> <dependency> > >> <groupId>org.apache.tomee.bom</groupId> > >> <artifactId>tomee-microprofile-api</artifactId> > >> <version>8.0.7-SNAPSHOT</version> > >> <scope>provided</scope> > >> </dependency> > >> <dependency> > >> <groupId>org.apache.tomee.bom</groupId> > >> <artifactId>tomee-microprofile</artifactId> > >> <version>8.0.7-SNAPSHOT</version> > >> <scope>test</scope> > >> </dependency> > >> > >> It's tempting to think, "maybe the second dependency should have an > >> 'impl' suffix?" I asked myself, thought through it and came out on > >> the "no" side. There will be people who just want the one dependency > >> that has everything. Specifically anyone using TomEE in an embedded > >> fashion, as plain libraries, or aiming to create an uber jar. It's > >> only people who intend to deploy to a TomEE zip who need/want the two > >> differently scoped dependencies. I also think to when I'm using > >> Arquillian and there is an "api" and "impl" jar for literally > >> everything and I forget to add one or the other, things fail, and I > >> think "seriously, I'm never going to chose a different > >> implementation, why are you making me do this?" It's all the more > >> frustrating as you know darn well the impl dep needs a very specific > >> version of that api dep -- you can't just use an older or newer api > >> version and expect things to work. Therefore I think having an > >> "everything" dep and an "apis-only" dep is just fine. > >> > >> > >> Thoughts? > >> > >> > >
