The whole point of Geronimo is nowadays to provide common reusable EE parts for other ASF projects. This is important for many projects which do not depend on TomEE. E.g. all the parts TomEE is actually using.
I do agree that those parts are moving a bit slower. But there is a very low boundary of becoming a committer in Geronimo and there are plenty of people around still. A few pieces - like MP are indeed not actively maintained anymore. But others are, BatchEE being one of em, mail, txmgr, etc as well. Splitting workforce is probably not the best solution but in the end it's a tomee community decision about how to move forward. The trend I do see is that EE is becoming bigger and bigger again. Adding functionality to the specs which are almost vendor specific and others which are very short lived is not helping. My personal preference would be to have libraries with a very small core which only implement the very core parts of a spec and having all the other features pluggable on top. This is not something which can be done easily in TomEE as here its about full spec compatibility. It's always a trade off. LieGrue, strub > Am 20.11.2022 um 12:33 schrieb Jean-Louis Monteiro <[email protected]>: > > 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
