Hi all, Thanks for the active and constructive discussion!
To summarize, here are the key considerations raised so far: Balancing leaner distributions against offering full feature sets out-of-the-box related to MicroProfile and EclipseLink / Mojarra vs MyFaces Technical concerns around startup time, image size, and library compatibility (MyFaces vs Mojarra; OpenJPA vs EclipseLink / Hibernate) Possibility of rebranding or restructuring distributions for greater clarity and flexibility EE11 is approaching, which may already introduce breaking changes — we should be mindful of the impact of multiple disruptive changes across versions like removing MP support in 10.x or 10.1.x A compromise would be to introduce a new, additional distribution starting with TomEE 10.1.x that excludes MicroProfile libraries by default. This would allow users who prefer a leaner runtime to benefit immediately, while keeping existing distributions unchanged for those relying on MP support. It would also give us valuable community feedback ahead of any broader decisions for TomEE 11 onwards (like streamlining the distributions as Thomas suggested). WDYT? Gruß Richard > Am 15.04.2025 um 10:17 schrieb Richard Zowalla <r...@apache.org>: > > Short clarifications: > > - This is _not_ a vote. It is a discussion thread to get opinions / different > views :-) > - I am not the chair of TomEE ;-) > > On a technical note: > > - We would still deliver TomEE MicroProfile with all its features. > >> Am 15.04.2025 um 10:10 schrieb Alex The Rocker <alex.m3...@gmail.com>: >> >> Hello Richard, >> >> [-1] for removing Microprofile from OOB TomEE 10.* >> >> Indeed: >> 1. From a semantic versionning standpoint, it is not possible to >> introduce a breaking change, so the earliest possible release to do >> such major change would be TomEE 11 >> 2. Competing applications servers (Payara, OpenLiberty, JBoss,...) >> seem to have OOTB MicroProfile support >> 3. MicroProfile is often quoted as "the incubator for potential new >> specifications [of Jakarta EE...]" (quoted from >> https://blog.sebastian-daschner.com/entries/microprofiles-role-jakarta-ee). >> >> This last point is the key reason why I disagree with removing >> MicroProfile from TomEE: enthousiatics developers willing to take >> advantage of those ahead-of-time features brought by MicroProfile will >> be less eager to use TomEE if MicroProfile isn't anymore part of it. >> They most likely they'll fall into other application servers' hands. >> >> That said, I welcome your initiative to cast such vote : your are >> playing your role as TomEE's PMC chairman, which is to inspire the >> future of this great community, with the democratic way to exchange on >> ideas. I will love seeying counter-arguments to my reply, and I'm sure >> that the more answers this proposal will get (whatever the final >> outcome will be), the healtiest TomEE community will be! >> >> Thanks, >> Alex >> >> Le lun. 14 avr. 2025 à 10:07, Richard Zowalla <r...@apache.org> a écrit : >>> >>> Hi all, >>> >>> Starting with TomEE 10.0.x, we've included MicroProfile 6.0 along with all >>> the necessary OpenTelemetry classes and libraries. >>> >>> From what I've seen, many libraries—such as JDBC drivers—automatically >>> enable OTEL features when the relevant libraries are present on the >>> classpath, regardless of any MicroProfile configuration settings. >>> >>> This puts us in a tricky position: we’re often forced to stick with older >>> library versions because upgrading from MP 6.0 to 6.1 tends to introduce >>> breaking changes. Moreover, MP 7 can only be supported once CXF provides a >>> compatible client, which is currently being targeted for Jakarta EE 11. >>> >>> Given this, I’d like to propose dropping the (de-activated) MicroProfile >>> support from the Web, Plus, and Plume distributions—meaning we would no >>> longer include the MP-related JARs by default. Instead, we could offer an >>> optional script-based approach (e.g., via a zip/tar.gz package) that users >>> can apply to add the MicroProfile flavor to Web/Plus/Plume as needed. >>> >>> Since this would be a breaking change, we could aim to roll it out starting >>> with version 10.1.x. >>> >>> WDYT? Any thoughts? >>> >>> Gruß >>> Richard >
