Additional note: https://lists.apache.org/thread/m7y4fbygwdz1kyloh7z86r5042mtz9k4
Might be interesting to get Mark's opinion on this thread regarding EE10 / CDI 4.0 :-) Gruß Richard Am Dienstag, dem 22.11.2022 um 20:51 +0100 schrieb Richard Zowalla: > Hi, > > I think it is better to have separate repos, builds and release > cycles, > if we are going to adopt these projects. > > (1) Spec Jars > > It is a valid point to discuss, if we want to keep the tradition of > doing our own ASF specific spec jars or if we want to stick with the > artifacts provided by the Eclipse foundation. A switch might confuse > users, but the impact shouldn't be a breaking change. > > > (2) Activiaton / Mail > > This is a mixture of API and impl. We might want to keep the Geronimo > impl and give it some love to pass the standalone mail tck. For > activation, the Geronimo impl already passes the Jakarta standalone > tck. Users can easily switch between the RI and the Geronimo impl. > Migh > t be a breaking change for users, if the package names change. > > > (3) Transaction Manager / Connector > > I agree with that. We should adopt it. Might be a breaking change for > users, if the package names change. > > (4) BatchEE > > We should probably adopt that library too. Might be a breaking change > for users, if the package names change. > > > (5) XBean > > Sure. Might be a breaking change for users, if the package names > change. > > (6) MicroProfile > > We are ways behind and do not have the man power to reimplement the > MP specs our own. So if it moves to the attic, it can be revived if > needed. For now, we can stay with Smallrye and if Swell has some open > resources, we might be able to upgrade to MP4 via Smallrye on TomEE > 8.x > > So if the Geronimo project decides to retire / move some sub projects > to the attic, we should most certainly adopt what we need in TomEE to > keep things running and to do required adjustments ourselves. > > Making the projects sub-modules of TomEE might complicate our build > process and interfer with different release schedules. I am more > inclined to have separate repositories and a concise linking on our > website. > > I remember, that David proposed something similar on the Geronimo > list > some months ago? > > Gruß > Richard > > > Am Sonntag, dem 20.11.2022 um 12:33 +0100 schrieb Jean-Louis > Monteiro: > > Hi all, > > > > It's been a couple of months since it started. It never really > > landed > > but > > it's getting more and more obvious that there is absolutely no > > desire > > to > > keep the Geronimo project. > > > > The goal of this email isn't really to discuss the reasons or argue > > if it > > should or not disappear, but more to discuss the impacts for TomEE > > itself. > > If you want to argue or discuss, you are more than welcome to do it > > on the > > Geronimo mailing list. > > > > We do use from the Geronimo project (not exhaustive list, but good > > start) > > > > - specs jars - they are mostly outdated and not sure anyone will do > > the > > jakarta translation. Is it still useful now that Jakarta is at > > Eclipse to > > have our own APIs? (used by other projects at Apache) > > > > - Activation and Mail - maybe a good opportunity to create a > > tomee-activation and a tomee-mail project and take the source for > > jakarta > > translation (used by other projects at Apache) > > > > - Connector and Transaction Manager - same we could grab those and > > create a > > specific project tomee-connector and tomee-transaction (used by > > other > > projects at Apache) > > > > - BatchEE - to become tomee-jbatch > > > > - xbean - low level libraries but it's a critical part in many > > aspects of > > TomEE. It can also become tomee-xbean (used by other projects at > > Apache) > > > > - MP implementation - they will most likely be moved to dormant so > > the code > > remains accessible and it can be revived at any time > > > > Note that for simplicity, we could create a tomee-foo with > > submodules > > so we > > could have all projects under the same github project. They do not > > have the > > same lifecycle so I went one-to-one at first glance. > > > > Maybe some of them (or all) could also be TomEE submodules in the > > current > > tree. I'm just concerned that for modules that don't leave too > > much, > > we > > will have the build to become more complex and also take more time > > which is > > already an issue. I'd be tempted to look at TomEE and extract parts > > that > > don't leave too much or with a different lifecycle into their own > > project. > > > > Thoughts? > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com
