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
signature.asc
Description: This is a digitally signed message part
