Re: [batchee] future?

Think it is a bit a too negative summary ;). On the identity part I guess we can decide it is important or consider we got a single mail and that whatever we do this issue can always popup with whatever name - in particular while we stay at "Apache". So not sure killing G solves anything at all

Re: [batchee] future?

Let's not forget that there is a branding issue that has been brought up over the years (most recently here [1]). My proposal for retirement [2] of Geronimo was in large part in response to that; but was also taking into account how low the activity is and how disjointed the sub-projects are and

Re: [batchee] future?

@François Papon cause we are far behind and it looked easier to use something already up to date (even if incomplete, smallrye has a ton of SPI but overall, once implemented it works) Romain Manni-Bucau @rmannibucau | Blog |

Re: [batchee] future?

Regarding our MP implementation, someone knows why the TomEE team decided to move from our to Smallrye? As TomEE is an Apache project, it can make sense to use and promote the Apache implementation of MP... regards, Francois On 23/11/2022 11:11, Romain Manni-Bucau wrote: In terms of

Re: [batchee] future?

Hi, It's good to see that this project is still used so no problem to keep it alive :) regards, Francois On 22/11/2022 23:30, Mark Struberg via dev wrote: I still use batchee very much. So I'd keep it well alive. Also investing time on and on. Is there anything which is required to do?

Re: [batchee] future?

Full agree JL - and btw we hijacked the thread ;). The key point for a spec is to be inclusive and take feedback from vendors to converge. Factually all feedbacks were rejected from the core members in several big specs - some went very well like JSON-B - and not only from a single contributor but

Re: [CDI40] how to tackle the jakarta 10 APIs?

Le mer. 23 nov. 2022 à 11:18, Mark Struberg a écrit : > > Not from a spec standpoint, it is the opposite, full is optional but is > based on lite (once again not saying it is good). > > > > From the wording of the spec. But this is totally inside out. > You mean at

Re: [batchee] future?

This is a big issue at the moment for the java ecosystem. The industry spends a lot of time trying to get specifications out and users/industry to adopt them regardless of the application server of implementation. But the more we move forward the less implementations we have. MicroProfile,

Re: [batchee] future?

That's right. The MicroProfile stuff is not much used these days anymore. Which is actually sad, because it was a good initiative. LieGrue, strub > Am 23.11.2022 um 11:11 schrieb Romain Manni-Bucau : > > In terms of storage and committers you are right but in terms of users a key > difference

Re: [CDI40] how to tackle the jakarta 10 APIs?

> Not from a spec standpoint, it is the opposite, full is optional but is based > on lite (once again not saying it is good). > From the wording of the spec. But this is totally inside out. Technically you can have 'CDI classic' without any of the 'CDI-light' (which adds tons of stuff to

Re: [batchee] future?

In terms of storage and committers you are right but in terms of users a key difference is "will it be a new release". If you look at MP it is quite unlikely since project seems way less consummed than it was some years ago and since TomEE moves to smallrye at the same time we don't update it

Re: [CDI40] how to tackle the jakarta 10 APIs?

Le mer. 23 nov. 2022 à 10:58, Mark Struberg via dev a écrit : > As written over at the OWB list: > > I intend only to update OWB to the jakarta package names plus implement > the core changes. > > All that 'cdi-light' stuff (which is imo rather broken) is technically > optional and can also get

Re: [batchee] future?

Yeah I understand there isn't much activity, but from time to time, they are updated to follow specifications and they are used by other projects (transaction manager, batchEE, etc). So they need a home. Of course we can split them apart and give them to different projects, but it does not solve

Re: [batchee] future?

Don't think the intent was to kill everything, it is more a matter of ensuring what we host is maintained. BatchEE is quite late behind the spec so worth a discussion IMHO but if there are plans to make it evolving and maintained no issue to keep it. To be transparent one concern I have is that

Re: [CDI40] how to tackle the jakarta 10 APIs?

As written over at the OWB list: I intend only to update OWB to the jakarta package names plus implement the core changes. All that 'cdi-light' stuff (which is imo rather broken) is technically optional and can also get implemented as a plugin. I just don't want to have all those tons of new

Re: [batchee] future?

> Overall I don't understand the recent discussions to kill all Geronimo > projects and subprojects. +1 Actually I'd rather keep it here as it is used outside TomEE as well. LieGrue, strub > Am 23.11.2022 um 10:15 schrieb Jean-Louis MONTEIRO : > > I've opened a thread on the TomEE side to

Re: [batchee] future?

I've opened a thread on the TomEE side to maybe transition BatchEE to TomEE. *Overall I don't understand the recent discussions to kill all Geronimo projects and subprojects.* Le mar. 22 nov. 2022 à 23:33, Romain Manni-Bucau a écrit : > No requirement, just making it living (updating versions

Re: [CDI40] how to tackle the jakarta 10 APIs?

Hi, Well, I guess the OSGi stuff is still a good justification to roll our own even if they didnt catch up yet jakarta - think they will anyway and owb runs in any case. On the flavor we can do a lite-free module but since standard version assumes lite extensions are ran as part of the runtime -