Re: [VOTE] Apache Geronimo Mail 2.1 spec 1.0.0

[Mark Struberg via dev]

+1

LueGrue,
strub

> Am 10.06.2024 um 16:03 schrieb Jean-Louis MONTEIRO :
> 
> Hi everyone,
> 
> I fixed 2 bugs and realized we were still in milestone mode. So it's more 
> than overdue. Here is a vote for the final 1.0.0 of the Jakarta Mail spec 2.1
> 
> SVN Tag
> https://svn.apache.org/viewvc/geronimo/specs/tags/geronimo-mail_2.1_spec-1.0.0/
> 
> Staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1170
> 
> Sources
> https://repository.apache.org/content/repositories/orgapachegeronimo-1170/org/apache/geronimo/specs/geronimo-mail_2.1_spec/1.0.0/geronimo-mail_2.1_spec-1.0.0-source-release.zip
> 
> Dist
> https://dist.apache.org/repos/dist/dev/geronimo/specs/geronimo-mail_2.1_spec-1.0.0/
> 
> The release notes are
> Bug
> 
> [GERONIMO-6869 ] - 
> InternetAddress.toString(InternetAddress[] addresses) prints the same address
> [GERONIMO-6870 ] - 
> RFC822 violation with duplicated headers
> 
> The vote will be open for at least 72 hours or until the necessary number of 
> votes are reached.
> 
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
> --
> Jean-Louis

Re: [VOTE] Apache XBean 4.25 release

[Mark Struberg via dev]

+1

txs and LieGrue,
strub


> Am 15.04.2024 um 13:34 schrieb fpapon :
> 
> Hi everyone,
> 
> I submit Apache XBean 4.25 release to your vote.
> 
> This release mainly includes (other issue description is available on
> the release note):
> 
> * Bug
> - [XBEAN-343] - consistent handling of NoClassDefFoundError
> 
> * Improvement
> - [XBEAN-345] - Upgrade to ASM 9.7
> 
> * Task
> - [XBEAN-342] - remove xbean-classpath module
> 
> Staging Maven repository:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1169
> 
> Staging dist repository:
> https://dist.apache.org/repos/dist/dev/geronimo/xbean/
> 
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> -- 
> --
> François
> 

Re: Arthur release

[Mark Struberg via dev]

all fine, go on!

txs and LieGrue,
strub


> Am 05.04.2024 um 09:30 schrieb Francois Papon :
> 
> Hi all,
> 
> I would like to start the release process for Arthur, any objection?
> 
> regards,
> 
> François
> 

Status BatchEE-2.0.0

[Mark Struberg via dev]

Hi folks!

I've now finished the work on BatchEE-2.0.0.
I think we have to enable the TCK still, but all our internal tests do work 
again.

Note that I had to move back to an old Camel version due to getting test errors 
with a newer version.
Would be great if someone could please take a look at it!

LieGrue,
strub

Re: [VOTE] [RESULT] Release Apache Geronimo BatchEE-1.0.3

[Mark Struberg via dev]

Hi!

And here comes my own +1

That makes it:

+1: Romain, Francois, Jean-Louis, Mark

No -1 nor 0

I'll go on to publish the repo etc.

LieGrue,
strub



> Am 18.04.2023 um 12:26 schrieb Mark Struberg :
> 
> Hi!
> 
> I'd like to call a VOTE on releasing BatchEE-1.0.3.
> 
> This is mostly an update to the latest TomEE version and a fix in the 
> ChildFirstURLClassLoader
> 
> [BATCHEE-162 ] - improve 
> reproducible builds
> [BATCHEE-167 ] - upgrade 
> to TomEE 8.0.9
> [BATCHEE-168 ] - duplicate 
> class definition issue within ChildFirstURLClassLoader
> 
> The staging repo can be found here:
> https://repository.apache.org/content/repositories/orgapachebatchee-1010/
> 
> The sources are here:
> https://repository.apache.org/content/repositories/orgapachebatchee-1010/org/apache/batchee/batchee/1.0.3/
> 
> sha512 is
> 564ff0ab3602d87202aa7764084d03af60d64f6900d85e99ad8ad2843d0e4804383bd58ae3a516acef550c237325c2c4f808caaebaace7d0645a0071c889c831
> 
> Please VOTE:
> 
> [+1] yup, ship it!
> [+0] I don't care
> [-1] Stop, I found a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> 
> txs and LieGrue,
> strub

Re: [VOTE] Release Apache Geronimo BatchEE-1.0.3

[Mark Struberg via dev]

Hi Romain!

Can you please explain what you think is now broken?

This basically is just a lock using the method the JDK intends exactly for this 
situation. See the JavaDoc of getClassLoadingLock.

txs and LieGrue,
strub

> Am 18.04.2023 um 13:13 schrieb Romain Manni-Bucau :
> 
> Hi,
> 
> Looks like ChildFirstURLClassLoader got broken and forced loading in this 
> particular classloader for standalone launcher is now up to the way it is 
> launched (so from memory some use cases will be broken) so tempted to -1 to 
> try to really fix #168 instead of breaking other things.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
> <https://rmannibucau.metawerx.net/> | Old Blog 
> <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> 
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book 
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> Le mar. 18 avr. 2023 à 12:27, Mark Struberg via dev  <mailto:dev@geronimo.apache.org>> a écrit :
>> Hi!
>> 
>> I'd like to call a VOTE on releasing BatchEE-1.0.3.
>> 
>> This is mostly an update to the latest TomEE version and a fix in the 
>> ChildFirstURLClassLoader
>> 
>> [BATCHEE-162 <https://issues.apache.org/jira/browse/BATCHEE-162>] - improve 
>> reproducible builds
>> [BATCHEE-167 <https://issues.apache.org/jira/browse/BATCHEE-167>] - upgrade 
>> to TomEE 8.0.9
>> [BATCHEE-168 <https://issues.apache.org/jira/browse/BATCHEE-168>] - 
>> duplicate class definition issue within ChildFirstURLClassLoader
>> 
>> The staging repo can be found here:
>> https://repository.apache.org/content/repositories/orgapachebatchee-1010/
>> 
>> The sources are here:
>> https://repository.apache.org/content/repositories/orgapachebatchee-1010/org/apache/batchee/batchee/1.0.3/
>> 
>> sha512 is
>> 564ff0ab3602d87202aa7764084d03af60d64f6900d85e99ad8ad2843d0e4804383bd58ae3a516acef550c237325c2c4f808caaebaace7d0645a0071c889c831
>> 
>> Please VOTE:
>> 
>> [+1] yup, ship it!
>> [+0] I don't care
>> [-1] Stop, I found a ${showstopper}
>> 
>> The VOTE is open for 72h.
>> 
>> 
>> txs and LieGrue,
>> strub

[VOTE] Release Apache Geronimo BatchEE-1.0.3

[Mark Struberg via dev]

Hi!

I'd like to call a VOTE on releasing BatchEE-1.0.3.

This is mostly an update to the latest TomEE version and a fix in the 
ChildFirstURLClassLoader

[BATCHEE-162 ] - improve 
reproducible builds
[BATCHEE-167 ] - upgrade to 
TomEE 8.0.9
[BATCHEE-168 ] - duplicate 
class definition issue within ChildFirstURLClassLoader

The staging repo can be found here:
https://repository.apache.org/content/repositories/orgapachebatchee-1010/

The sources are here:
https://repository.apache.org/content/repositories/orgapachebatchee-1010/org/apache/batchee/batchee/1.0.3/

sha512 is
564ff0ab3602d87202aa7764084d03af60d64f6900d85e99ad8ad2843d0e4804383bd58ae3a516acef550c237325c2c4f808caaebaace7d0645a0071c889c831

Please VOTE:

[+1] yup, ship it!
[+0] I don't care
[-1] Stop, I found a ${showstopper}

The VOTE is open for 72h.


txs and LieGrue,
strub

Re: [VOTE] Release Geronimo Arthur 1.0.6

[Mark Struberg via dev]

+1

LieGrue,
strub


> Am 17.04.2023 um 20:54 schrieb fpapon :
> 
> Hi,
> 
> This is a call to vote in favor of releasing Apache Geronimo Arthur version 
> 1.0.6.
>  
> We solved 7 issues:
>  
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220=12351343
> 
> ** Bug
> * [GERONIMO-6833] - Ensure proxy hierarchy is registered for native-image
> 
> ** Improvement
> * [GERONIMO-6836] - Avoid warnings about allow-incomplete-classpath and 
> enableAllSecurityServices
> * [GERONIMO-6843] - Upgrade dependencies to avoid CVE in ossindex:audit
> 
> ** Task
> * [GERONIMO-6830] - Upgrade to jackson-databind 2.13.2.2
> * [GERONIMO-6831] - Upgrade to sshd-core 2.8.0
> * [GERONIMO-6840] - Support GraalVM 22.2 reflection model
> * [GERONIMO-6842] - Arthur can't find native libraries of java 17
> 
>  
> The source to be voted upon:
> https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git;a=tag;h=refs/tags/arthur-1.0.6
>  
> Staging repo for binaries:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1159/
> 
> Staging dist dev for sources:
> https://dist.apache.org/repos/dist/dev/geronimo/arthur/
> 
>  
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> GPG Key:
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
>  
> Vote open for 72 hours. Please do examine the source and binaries before 
> voting.
>  
> [ ] +1
> [ ] +0
> [ ] -1 (please include reasoning)
> 
> -- 
> --
> François

Re: [batchee] future?

[Mark Struberg via dev]

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 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 anymore, not sure we would do any new release.
> So while it is ok to keep it there, we should also communicate clearly we 
> don't intend to do any new release if it is the case - same story than 
> geronimo server basically.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
> <https://rmannibucau.metawerx.net/> | Old Blog 
> <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> 
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book 
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> Le mer. 23 nov. 2022 à 11:00, Jean-Louis MONTEIRO  <mailto:jeano...@gmail.com>> a écrit :
>> 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 
>> any problem. The people are the same. As soon as we allow all projects to 
>> contribute or even become committers here, I don't see any issue at the 
>> moment at least.
>> 
>> Le mer. 23 nov. 2022 à 10:53, Mark Struberg via dev > <mailto:dev@geronimo.apache.org>> a écrit :
>>>> 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 >>> <mailto:jeano...@gmail.com>>:
>>>> 
>>>> 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 >>> <mailto:rmannibu...@gmail.com>> a écrit :
>>>>> No requirement, just making it living (updating versions and spec impl).
>>>>> 
>>>>> Le mar. 22 nov. 2022 à 23:31, Mark Struberg via dev 
>>>>> mailto:dev@geronimo.apache.org>> a écrit :
>>>>>> 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?
>>>>>> 
>>>>>> LieGrue,
>>>>>> strub
>>>>>> 
>>>>>> 
>>>>>>> Am 18.11.2022 um 09:50 schrieb Francois Papon 
>>>>>>> mailto:francois.pa...@openobject.fr>>:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I don't have insights about how BatchEE is used today and how the 
>>>>>>> jbatch specification is support by others.
>>>>>>> 
>>>>>>> +1 for freeze.
>>>>>>> 
>>>>>>> regards,
>>>>>>> 
>>>>>>> François
>>>>>>> 
>>>>>>> On 18/11/2022 08:21, Romain Manni-Bucau wrote:
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> We discussed some time ago to drop batchee as an active subproject, 
>>>>>>>> wonder where we are now on this?
>>>>>>>> Do we freeze it and document we don't maintain it anymore?
>>>>>>>> 
>>>>>>>> Romain Manni-Bucau
>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
>>>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog 
>>>>>>>> <http://rmannibucau.wordpress.com/> | Github 
>>>>>>>> <https://github.com/rmannibucau> | LinkedIn 
>>>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book 
>>>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>>> 
>>>> 
>>>> -- 
>>>> Jean-Louis
>>> 
>> 
>> 
>> -- 
>> Jean-Louis

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

[Mark Struberg via dev]

> 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 'classic').
And this is what we should do. 

> Legally we are now fine to consume jakarta artifacts 

Yes, as long as they are really ALv2 (clearly) or EPLv2.0 (needs some 
attribution IF we also bundle those jars...) and not their 'Jakarta spec 
license'.
But that seems to be EPLv2 as far as I've looked through a bunch of spec api 
jars.

LieGrue,
strub

> Am 23.11.2022 um 11:02 schrieb Romain Manni-Bucau :
> 
> 
> 
> 
> Le mer. 23 nov. 2022 à 10:58, Mark Struberg via dev  <mailto:dev@geronimo.apache.org>> 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 implemented as a plugin.
> 
> Not from a spec standpoint, it is the opposite, full is optional but is based 
> on lite (once again not saying it is good).
>  
>> I just don't want to have all those tons of new classes around nobody needs 
>> if not running on Quarkus.
> 
> Well, if you look the way the spec was written, then you need it.
> Or said otherwise, if you think this way you must make all the extension API 
> optional as well and get "cdi-runtime-api", "cdi-lite", "cdi-full" or 
> something like that.
> Once again I don't think we can fight much there so guess we should just get 
> it as in the spec, optionally we can get as the spec intend lite bundle and 
> full bundle but not the other way around.
>  
>> 
>> What about the other spec APIs we still need? use the Eclipse one (EPL + 
>> spec)? What legal consequences does this have in comparison to updating our 
>> own packages? It's mostly just package renames for now anyway.
> 
> Legally we are now fine to consumme jakarta artifacts so last time we 
> discussed it we decided to keep our "forks" for OSGi but guess we can discuss 
> with karaf/smix projects to drop it and let them do it if you want to stop 
> doing spec jars.
> Just want we clearly document it for users on our website.
>  
>> 
>> LieGrue,
>> strub
>> 
>>> Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau >> <mailto:rmannibu...@gmail.com>>:
>>> 
>>> 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 - strictly speaking 
>>> they say runtime or build or anything but spec only defines a runtime so it 
>>> is literally at runtime - I guess owb still needs to impl it and I don't 
>>> like much the idea to implement a subpart of the minimum requirement of the 
>>> spec - never said I think what they did is ok, it is fully wrong but it is 
>>> what we have today and fighting against the spec is never good while using 
>>> its API IMHO.
>>> 
>>> So concretely I would just do a standard bundle for OSGi stuff and be it.
>>> We need to see what we do at OWB but fear we just back lite by a full 
>>> extensions at some point, at least in extension mode.
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
>>> <https://rmannibucau.metawerx.net/> | Old Blog 
>>> <http://rmannibucau.wordpress.com/> | Github 
>>> <https://github.com/rmannibucau> | LinkedIn 
>>> <https://www.linkedin.com/in/rmannibucau> | Book 
>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>> 
>>> Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev 
>>> mailto:dev@geronimo.apache.org>> a écrit :
>>>> Hi!
>>>> 
>>>> How do we want to approach the CDI-4.0 api?
>>>> I don't want to just use the official API as it is bloated with the 'CDI 
>>>> light' stuff.
>>>> So there is good reason to just keep our own version - even if it is just 
>>>> a shaded/spit of the official one.
>>>> 
>>>> What about the others? Do we still want to roll our own or also take the 
>>>> official ones?
>>>> What is the benefit of one approach over the other?
>>>> 
>>>> let's discuss!
>>>> 
>>>> LieGrue,
>>>> strub
>>>> 
>> 

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

[Mark Struberg via dev]

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 classes around nobody needs if 
not running on Quarkus.

What about the other spec APIs we still need? use the Eclipse one (EPL + spec)? 
What legal consequences does this have in comparison to updating our own 
packages? It's mostly just package renames for now anyway.

LieGrue,
strub

> Am 23.11.2022 um 09:01 schrieb Romain Manni-Bucau :
> 
> 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 - strictly speaking they say 
> runtime or build or anything but spec only defines a runtime so it is 
> literally at runtime - I guess owb still needs to impl it and I don't like 
> much the idea to implement a subpart of the minimum requirement of the spec - 
> never said I think what they did is ok, it is fully wrong but it is what we 
> have today and fighting against the spec is never good while using its API 
> IMHO.
> 
> So concretely I would just do a standard bundle for OSGi stuff and be it.
> We need to see what we do at OWB but fear we just back lite by a full 
> extensions at some point, at least in extension mode.
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
> <https://rmannibucau.metawerx.net/> | Old Blog 
> <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> 
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book 
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> Le mar. 22 nov. 2022 à 23:52, Mark Struberg via dev  <mailto:dev@geronimo.apache.org>> a écrit :
>> Hi!
>> 
>> How do we want to approach the CDI-4.0 api?
>> I don't want to just use the official API as it is bloated with the 'CDI 
>> light' stuff.
>> So there is good reason to just keep our own version - even if it is just a 
>> shaded/spit of the official one.
>> 
>> What about the others? Do we still want to roll our own or also take the 
>> official ones?
>> What is the benefit of one approach over the other?
>> 
>> let's discuss!
>> 
>> LieGrue,
>> strub
>> 

Re: [batchee] future?

[Mark Struberg via dev]

> 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 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  <mailto:rmannibu...@gmail.com>> a écrit :
>> No requirement, just making it living (updating versions and spec impl).
>> 
>> Le mar. 22 nov. 2022 à 23:31, Mark Struberg via dev > <mailto:dev@geronimo.apache.org>> a écrit :
>>> 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?
>>> 
>>> LieGrue,
>>> strub
>>> 
>>> 
>>>> Am 18.11.2022 um 09:50 schrieb Francois Papon 
>>>> mailto:francois.pa...@openobject.fr>>:
>>>> 
>>>> Hi,
>>>> 
>>>> I don't have insights about how BatchEE is used today and how the jbatch 
>>>> specification is support by others.
>>>> 
>>>> +1 for freeze.
>>>> 
>>>> regards,
>>>> 
>>>> François
>>>> 
>>>> On 18/11/2022 08:21, Romain Manni-Bucau wrote:
>>>>> Hi all,
>>>>> 
>>>>> We discussed some time ago to drop batchee as an active subproject, 
>>>>> wonder where we are now on this?
>>>>> Do we freeze it and document we don't maintain it anymore?
>>>>> 
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
>>>>> <https://rmannibucau.metawerx.net/> | Old Blog 
>>>>> <http://rmannibucau.wordpress.com/> | Github 
>>>>> <https://github.com/rmannibucau> | LinkedIn 
>>>>> <https://www.linkedin.com/in/rmannibucau> | Book 
>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
> 
> 
> -- 
> Jean-Louis

[CDI40] how to tackle the jakarta 10 APIs?

[Mark Struberg via dev]

Hi!

How do we want to approach the CDI-4.0 api?
I don't want to just use the official API as it is bloated with the 'CDI light' 
stuff.
So there is good reason to just keep our own version - even if it is just a 
shaded/spit of the official one.

What about the others? Do we still want to roll our own or also take the 
official ones?
What is the benefit of one approach over the other?

let's discuss!

LieGrue,
strub

Re: [batchee] future?

[Mark Struberg via dev]

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?

LieGrue,
strub


> Am 18.11.2022 um 09:50 schrieb Francois Papon :
> 
> Hi,
> 
> I don't have insights about how BatchEE is used today and how the jbatch 
> specification is support by others.
> 
> +1 for freeze.
> 
> regards,
> 
> François
> 
> On 18/11/2022 08:21, Romain Manni-Bucau wrote:
>> Hi all,
>> 
>> We discussed some time ago to drop batchee as an active subproject, wonder 
>> where we are now on this?
>> Do we freeze it and document we don't maintain it anymore?
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog 
>>  | Old Blog 
>>  | Github 
>>  | LinkedIn 
>>  | Book 
>>