Geronimo future if any

[Jean-Louis Monteiro <jl...@tomitribe.com>]

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

Re: Geronimo future if any

[Richard Zowalla <rz...@apache.org>]

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

Re: Geronimo future if any

[Richard Zowalla <rz...@apache.org>]

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

Re: Geronimo future if any

[Mark Struberg <st...@yahoo.de.INVALID>]

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 <jl...@tomitribe.com>:
> 
> 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

Re: Geronimo future if any

[Swell <so...@gmail.com>]

Hi everyone, and thank you Jean-Louis for opening this topic again,

i would be more than happy to make the API switch and yank the specs jars
in favor of Jakarta EE official jars (cf. my mail from 9/nov/22
https://lists.apache.org/thread/cpt4cfhkv068cnrx3g2tl0cpgkb6rzj6)

i would also be happy to upgrade Tomee 8.x to MicroProfile 4.1 (EE 8) and
switch Geronimo impl with SmallRye. I would like to try on my machine to
clone TomEE 9.x branch and downgrade my clone from MP 5 to MP 4.1 and see
if the TCK passes. is this a good approach? what do you think?

on the part about adding projects/shadings, i am not a fan of growing up
the source code nor shade everything. maybe i don't understand the need for
shading, Would it be ok to use the com.sun implementations for Activation
and Mail? (left them out of TomEE scope and ease maintenance).

--
Swell


On Sun, 20 Nov 2022 at 12:33, Jean-Louis Monteiro <jl...@tomitribe.com>
wrote:

> 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
>