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

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

Re: [VOTE] geronimo-javamail_1.6_spec 1.0.1

[Mark Struberg]

+1

LieGrue,
strub

> Am 07.10.2021 um 21:30 schrieb Jean-Louis MONTEIRO :
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-javamail_1.6_spec 1.0.1 
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1141 
> 
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1141/org/apache/geronimo/specs/geronimo-javamail_1.6_spec/1.0.1/geronimo-javamail_1.6_spec-1.0.1-source-release.zip
>  
> 
> 
> SVN tag
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.6_spec-1.0.1/
>  
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> -- 
> Jean-Louis

Fwd: OpenJPA 3.2.0 with Java 16

[Mark Struberg]

Hiho!

Sorry for x-posting, but this is really something we need to fix in 
geronimo-specs.
Gonna roll the changes and perform a release if there is no objection.

LieGrue,
strub

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Mark Struberg 
> Betreff: Aw: OpenJPA 3.2.0 with Java 16
> Datum: 30. September 2021 um 20:01:47 MESZ
> An: us...@openjpa.apache.org
> Antwort an: us...@openjpa.apache.org
> 
> Hi Rob! 
> 
> It's even a bit more complicated. During the javax -> jakarta spec migration 
> we found a few javax packages which will remain in the JDK and thus remain to 
> keep the javax package name. The javax.transaction.xa is one of those. It is 
> also not part of the official jakarta jta packages. Thus I'd say we should 
> also remove this package from the geronimo specs jar and roll a new release. 
> Just checked that the xa package is also part of Java 17 still.
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 28.09.2021 um 18:11 schrieb Rob Scala :
>> 
>> Hi Everyone,
>> 
>> I hope I have the right mailing list.
>> 
>> I'm working on upgrading from java 8 to java 16, and updating dependencies 
>> in the process.  My project is modular.  I hit a stumbling block with a 
>> split package:
>> 
>> module X reads package javax.transaction.xa from both 
>> org.apache.geronimo.specs.geronimo.jta.spec and java.transaction.xa
>> 
>> where X is a lot of different modules, including apache commons, awssdk, 
>> jersey, etc.
>> 
>> I understand that this error is caused by a core java module 
>> (java.transaction.xa) and a geronimo.jta module both containing classes in 
>> the packate "javax.transaction.xa".  That is not allowed in modular 
>> projects.  Since the geronimo module is required by OpenJPA, I tried 
>> excluding the core java module, but that didn't work, and I don't know if it 
>> even should work.
>> 
>> Has anyone used OpenJPA in a modular project?  Is there a solution for this?
>> 
>> Thanks a bunch!
>> 
>> Rob Scala
>> 
> 

Re: [VOTE] - Move Svn to Gitbox

[Mark Struberg]

+1

LieGrue,
strub

> Am 15.05.2021 um 08:25 schrieb fpa...@apache.org:
> 
> Hi,
> 
> I would like to start a vote about moving some projects from svn to gitbox:
> 
> - http://svn.apache.org/repos/asf/geronimo/xbean/ 
> 
> 
> - http://svn.apache.org/repos/asf/geronimo/javamail/ 
> 
> 
> - http://svn.apache.org/repos/asf/geronimo/components/txmanager/ 
> 
> 
> Discussion thread:
> 
> - 
> https://lists.apache.org/thread.html/r5a89c97f4afb2cf900277c14fd27cb14c463855ca0d4093b9921e80a%40%3Cdev.geronimo.apache.org%3E
>  
> 
> 
> Please vote:
> 
> 
> [ ] +1 Approve
> [ ] -1 Don't approve (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> regards,
> 
> -- 
> François
> fpa...@apache.org 

Re: [DISCUSS] - SVN to Gitbox

[Mark Struberg]

I think we could do a VOTE for all repos excluding specs. And then discuss 
those separate without having any pressure.
Wdyt?

LieGrue,
strub


> Am 12.05.2021 um 08:50 schrieb Francois Papon :
> 
> Thanks all for your feedback, I will start a vote to move forward!
> 
> regards,
> 
> François
> fpa...@apache.org <mailto:fpa...@apache.org>
> Le 12/05/2021 à 08:46, Francois Papon a écrit :
>> +1 to have one repo per spec
>> 
>> regards,
>> 
>> François
>> fpa...@apache.org <mailto:fpa...@apache.org>
>> Le 11/05/2021 à 15:13, Romain Manni-Bucau a écrit :
>>> Guess we should stick to what we are used to.
>>> The most visible part is likely the release so I'm tempted to say we do one 
>>> repo per atomic release.
>>> For specs it likely means one repo per spec (but we can automate it or work 
>>> with infra to bulk migrate it).
>>> Will maybe hurt a bit right now but will:
>>> 
>>> 1. enable PR on github (today it is a mess for external users)
>>> 2. make releases easier (monorepo failed, happy we never moved to that ;))
>>> 
>>> 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. 11 mai 2021 à 14:00, Jean-Baptiste Onofre >> <mailto:j...@nanthrax.net>> a écrit :
>>> Hi Mark,
>>> 
>>> I guess you mean for the release ? 
>>> 
>>> If we agree to have bunch of tag, we can have spec in a single repo (it’s 
>>> what I’m doing at ServiceMix).
>>> 
>>> But I guess it would be cleaner to have a dedicated repo per spec (less 
>>> convenient anyway).
>>> 
>>> Regards
>>> JB
>>> 
>>> > Le 11 mai 2021 à 13:56, Mark Struberg >> > <mailto:strub...@yahoo.de>> a écrit :
>>> > 
>>> > specs could be tricky. We'd need to do every single spec as own git repo, 
>>> > isn't?
>>> > 
>>> > LieGrue,
>>> > strub
>>> > 
>>> > 
>>> >> Am 11.05.2021 um 05:39 schrieb fpa...@apache.org 
>>> >> <mailto:fpa...@apache.org>:
>>> >> 
>>> >> Hi,
>>> >> 
>>> >> I would like to start a discussion about moving some of our project
>>> >> repositories from svn to gitbox.
>>> >> 
>>> >> 
>>> >> I think we can start with this projects:
>>> >> 
>>> >> - http://svn.apache.org/repos/asf/geronimo/xbean/ 
>>> >> <http://svn.apache.org/repos/asf/geronimo/xbean/>
>>> >> 
>>> >> - http://svn.apache.org/repos/asf/geronimo/javamail/ 
>>> >> <http://svn.apache.org/repos/asf/geronimo/javamail/>
>>> >> 
>>> >> - http://svn.apache.org/repos/asf/geronimo/components/txmanager/ 
>>> >> <http://svn.apache.org/repos/asf/geronimo/components/txmanager/>
>>> >> 
>>> >> - http://svn.apache.org/repos/asf/geronimo/specs/ 
>>> >> <http://svn.apache.org/repos/asf/geronimo/specs/>
>>> >> 
>>> >> 
>>> >> Here are the current Geronimo gitbox projects:
>>> >> 
>>> >> https://gitbox.apache.org/repos/asf#geronimo 
>>> >> <https://gitbox.apache.org/repos/asf#geronimo>
>>> >> 
>>> >> 
>>> >> Any objection? Don't hesitate to add other project you want to move.
>>> >> 
>>> >> regards,
>>> >> 
>>> >> -- 
>>> >> François
>>> >> fpa...@apache.org <mailto:fpa...@apache.org>
>>> >> 
>>> > 
>>> 

Re: [DISCUSS] - SVN to Gitbox

[Mark Struberg]

specs could be tricky. We'd need to do every single spec as own git repo, isn't?

LieGrue,
strub


> Am 11.05.2021 um 05:39 schrieb fpa...@apache.org:
> 
> Hi,
> 
> I would like to start a discussion about moving some of our project
> repositories from svn to gitbox.
> 
> 
> I think we can start with this projects:
> 
> - http://svn.apache.org/repos/asf/geronimo/xbean/
> 
> - http://svn.apache.org/repos/asf/geronimo/javamail/
> 
> - http://svn.apache.org/repos/asf/geronimo/components/txmanager/
> 
> - http://svn.apache.org/repos/asf/geronimo/specs/
> 
> 
> Here are the current Geronimo gitbox projects:
> 
> https://gitbox.apache.org/repos/asf#geronimo
> 
> 
> Any objection? Don't hesitate to add other project you want to move.
> 
> regards,
> 
> -- 
> François
> fpa...@apache.org
> 

Re: [VOTE] [RESULT] Release Apache BatchEE 1.0.0

[Mark Struberg]

Hi!

The VOTE did succeed with 

+1: JBO, Romain, Ray, Francois, Mark, Reinhard, Cesar

no -1 nor 0

txs 2 all who reviewed and voted!
Gonna go on with the release.

LieGrue,
strub


> Am 08.05.2021 um 09:51 schrieb Mark Struberg :
> 
> hi lords and ladies!
> 
> I want to call a VOTE on releasing Apache BatchEE 1.0.0
> This is mainly an update to JavaEE8 and a few bug fixes.
> 
> We fixed the following tickets.
> 
> Bug
> 
> [BATCHEE-126 <https://issues.apache.org/jira/browse/BATCHEE-126>] - upgrade 
> to tomee-8.0.6
> [BATCHEE-149 <https://issues.apache.org/jira/browse/BATCHEE-149>] - 
> BatchCDIInjectionExtension should only use CDI.current() if container is 
> really started
> [BATCHEE-150 <https://issues.apache.org/jira/browse/BATCHEE-150>] - 
> JDBCDictionary deleteStepExecution did contain invalid SQL
> [BATCHEE-151 <https://issues.apache.org/jira/browse/BATCHEE-151>] - starting 
> batchee-cli in parallel might cause race conditions when unpacking WARs
> New Feature
> 
> [BATCHEE-148 <https://issues.apache.org/jira/browse/BATCHEE-148>] - Upgrade 
> BatchEE-1.0.0 to EE8
> Task
> 
> [BATCHEE-147 <https://issues.apache.org/jira/browse/BATCHEE-147>] - upgrade 
> to latest apache parent
> 
> 
> The staging repository is hosted here: 
> https://repository.apache.org/content/repositories/orgapachebatchee-1007/ 
> <https://repository.apache.org/content/repositories/orgapachebatchee-1007/>
> 
> The source zip can be found here:
> https://repository.apache.org/content/repositories/orgapachebatchee-1007/org/apache/batchee/batchee/1.0.0/
>  
> <https://repository.apache.org/content/repositories/orgapachebatchee-1007/org/apache/batchee/batchee/1.0.0/>
> sha1 is da2990a42caaa639a50df03de3eaec4f6548a8bc
> 
> Please VOTE
> 
> [+1] ship it!
> [+0] don't care
> [-1] stop, there's a ${showstopper}
> 
> The VOTE is open for 72h
> 
> LieGrue,
> strub
> 

Re: [VOTE][RESULT] Release Apache xBean-4.20

[Mark Struberg]

Hi!

The VOTE did pass with the following:

+1: JBO, Romain, Mark, Francois

Will continue with the release steps.

txs and LieGrue,
strub


> Am 08.05.2021 um 07:14 schrieb Francois Papon :
> 
> +1 (binding)
> 
> regards,
> 
> François
> fpa...@apache.org <mailto:fpa...@apache.org>
> 
> Le 07/05/2021 à 10:22, Mark Struberg a écrit :
>> hiho!
>> 
>> I'd like to call a VOTE on releasing xbean-4.20.
>> 
>> The only change is to switch back to a dependency-reduced pom.
>> 4.18 und 4.19 did leak the shaded ASM dependencies down to consumers.
>> This defeats the shading.
>> Downstream projects can of course use exclude lists, but since the
>> artifactId changes rather quickly it would be great to not leak those
>> artifacts.
>> 
>> 
>> The staging repository is here:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1139
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139>>
>> 
>> The source zip can be found here:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/
>>  
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/>
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/
>>  
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/>>
>> sha1 is 9813469618230d15bf17763ca7f989e414608a0f
>> 
>> Please VOTE
>> 
>> [+1] let's ship it!
>> [+0] don't care
>> [-1] stop there is a ${showstopper}
>> 
>> 
>> The VOTE is open for 72h.
>> 
>> txs and LieGrue,
>> strub

Re: [VOTE] Release Apache BatchEE 1.0.0

[Mark Struberg]

My own

+1

LieGrue,
strub



> Am 08.05.2021 um 09:51 schrieb Mark Struberg :
> 
> hi lords and ladies!
> 
> I want to call a VOTE on releasing Apache BatchEE 1.0.0
> This is mainly an update to JavaEE8 and a few bug fixes.
> 
> We fixed the following tickets.
> 
> Bug
> 
> [BATCHEE-126 <https://issues.apache.org/jira/browse/BATCHEE-126>] - upgrade 
> to tomee-8.0.6
> [BATCHEE-149 <https://issues.apache.org/jira/browse/BATCHEE-149>] - 
> BatchCDIInjectionExtension should only use CDI.current() if container is 
> really started
> [BATCHEE-150 <https://issues.apache.org/jira/browse/BATCHEE-150>] - 
> JDBCDictionary deleteStepExecution did contain invalid SQL
> [BATCHEE-151 <https://issues.apache.org/jira/browse/BATCHEE-151>] - starting 
> batchee-cli in parallel might cause race conditions when unpacking WARs
> New Feature
> 
> [BATCHEE-148 <https://issues.apache.org/jira/browse/BATCHEE-148>] - Upgrade 
> BatchEE-1.0.0 to EE8
> Task
> 
> [BATCHEE-147 <https://issues.apache.org/jira/browse/BATCHEE-147>] - upgrade 
> to latest apache parent
> 
> 
> The staging repository is hosted here: 
> https://repository.apache.org/content/repositories/orgapachebatchee-1007/ 
> <https://repository.apache.org/content/repositories/orgapachebatchee-1007/>
> 
> The source zip can be found here:
> https://repository.apache.org/content/repositories/orgapachebatchee-1007/org/apache/batchee/batchee/1.0.0/
>  
> <https://repository.apache.org/content/repositories/orgapachebatchee-1007/org/apache/batchee/batchee/1.0.0/>
> sha1 is da2990a42caaa639a50df03de3eaec4f6548a8bc
> 
> Please VOTE
> 
> [+1] ship it!
> [+0] don't care
> [-1] stop, there's a ${showstopper}
> 
> The VOTE is open for 72h
> 
> LieGrue,
> strub
> 

[VOTE] Release Apache BatchEE 1.0.0

[Mark Struberg]

hi lords and ladies!

I want to call a VOTE on releasing Apache BatchEE 1.0.0
This is mainly an update to JavaEE8 and a few bug fixes.

We fixed the following tickets.

Bug

[BATCHEE-126 ] - upgrade to 
tomee-8.0.6
[BATCHEE-149 ] - 
BatchCDIInjectionExtension should only use CDI.current() if container is really 
started
[BATCHEE-150 ] - 
JDBCDictionary deleteStepExecution did contain invalid SQL
[BATCHEE-151 ] - starting 
batchee-cli in parallel might cause race conditions when unpacking WARs
New Feature

[BATCHEE-148 ] - Upgrade 
BatchEE-1.0.0 to EE8
Task

[BATCHEE-147 ] - upgrade to 
latest apache parent


The staging repository is hosted here: 
https://repository.apache.org/content/repositories/orgapachebatchee-1007/ 


The source zip can be found here:
https://repository.apache.org/content/repositories/orgapachebatchee-1007/org/apache/batchee/batchee/1.0.0/
 

sha1 is da2990a42caaa639a50df03de3eaec4f6548a8bc

Please VOTE

[+1] ship it!
[+0] don't care
[-1] stop, there's a ${showstopper}

The VOTE is open for 72h

LieGrue,
strub

Re: [VOTE] Release Apache xBean-4.20

[Mark Struberg]

my own +1

LieGrue,
strub


> Am 07.05.2021 um 10:22 schrieb Mark Struberg :
> 
> hiho!
> 
> I'd like to call a VOTE on releasing xbean-4.20.
> 
> The only change is to switch back to a dependency-reduced pom.
> 4.18 und 4.19 did leak the shaded ASM dependencies down to consumers. This 
> defeats the shading.
> Downstream projects can of course use exclude lists, but since the artifactId 
> changes rather quickly it would be great to not leak those artifacts.
> 
> 
> The staging repository is here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1139 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139>
> 
> The source zip can be found here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/>
> sha1 is 9813469618230d15bf17763ca7f989e414608a0f
> 
> Please VOTE
> 
> [+1] let's ship it!
> [+0] don't care
> [-1] stop there is a ${showstopper}
> 
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub
> 
> 

Re: [VOTE] Release Apache xBean-4.20

[Mark Struberg]

Yes indeed, sorry was an oversight on my side.

LieGrue,
strub

> Am 07.05.2021 um 15:41 schrieb Romain Manni-Bucau :
> 
> Hmm, think we miss a .gitignore since we are used on git as well.
> Can be fine with that since svn should be ok now.
> 
> 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 ven. 7 mai 2021 à 11:35, Mark Struberg  <mailto:strub...@yahoo.de>> a écrit :
> That's the reason I also added it to svn:ignore.
> That way it doesn't pollute our repo at least.
> 
> Happy to go for an even better solution!
> 
> It can be easily verified if it works. Just do 
> $> mvn clean install && less 
> ~/.m2/reposiory/org/apache/xbean/xbean-asm9-shaded/2.21-SNAPSHOT/*.pom
> 
> This must not contain any ow2 dependencies.
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 07.05.2021 um 10:48 schrieb Romain Manni-Bucau >:
>> 
>> Hi Mark,
>> 
>> was set to false to avoid it to mess up the working dir so I guess this 
>> fixes the pom by breaking the project setup so guess we should make it 
>> generated in target (but generated) as a fix for both at once as mentionned 
>> on slack, no?
>> 
>> Romain Manni-Bucau
>> @rmannibucau <> |  Blog <> | Old Blog <> | Github <> | LinkedIn <> | Book <>
>> 
>> Le ven. 7 mai 2021 à 10:27, Jean-Baptiste Onofre > a 
>> écrit :
>> +1 (binding)
>> 
>> Thanks Mark !
>> 
>> Regards
>> JB
>> 
>>> Le 7 mai 2021 à 10:22, Mark Struberg > a écrit :
>>> 
>>> hiho!
>>> 
>>> I'd like to call a VOTE on releasing xbean-4.20.
>>> 
>>> The only change is to switch back to a dependency-reduced pom.
>>> 4.18 und 4.19 did leak the shaded ASM dependencies down to consumers. This 
>>> defeats the shading.
>>> Downstream projects can of course use exclude lists, but since the 
>>> artifactId changes rather quickly it would be great to not leak those 
>>> artifacts.
>>> 
>>> 
>>> The staging repository is here:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1139 <>
>>> 
>>> The source zip can be found here:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/
>>>  <>
>>> sha1 is 9813469618230d15bf17763ca7f989e414608a0f
>>> 
>>> Please VOTE
>>> 
>>> [+1] let's ship it!
>>> [+0] don't care
>>> [-1] stop there is a ${showstopper}
>>> 
>>> 
>>> The VOTE is open for 72h.
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>>> 
>> 
> 

Re: [VOTE] Release Apache xBean-4.20

[Mark Struberg]

That's the reason I also added it to svn:ignore.
That way it doesn't pollute our repo at least.

Happy to go for an even better solution!

It can be easily verified if it works. Just do 
$> mvn clean install && less 
~/.m2/reposiory/org/apache/xbean/xbean-asm9-shaded/2.21-SNAPSHOT/*.pom

This must not contain any ow2 dependencies.

LieGrue,
strub



> Am 07.05.2021 um 10:48 schrieb Romain Manni-Bucau :
> 
> Hi Mark,
> 
> was set to false to avoid it to mess up the working dir so I guess this fixes 
> the pom by breaking the project setup so guess we should make it generated in 
> target (but generated) as a fix for both at once as mentionned on slack, no?
> 
> 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 ven. 7 mai 2021 à 10:27, Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> a écrit :
> +1 (binding)
> 
> Thanks Mark !
> 
> Regards
> JB
> 
>> Le 7 mai 2021 à 10:22, Mark Struberg > <mailto:strub...@yahoo.de>> a écrit :
>> 
>> hiho!
>> 
>> I'd like to call a VOTE on releasing xbean-4.20.
>> 
>> The only change is to switch back to a dependency-reduced pom.
>> 4.18 und 4.19 did leak the shaded ASM dependencies down to consumers. This 
>> defeats the shading.
>> Downstream projects can of course use exclude lists, but since the 
>> artifactId changes rather quickly it would be great to not leak those 
>> artifacts.
>> 
>> 
>> The staging repository is here:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1139 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139>
>> 
>> The source zip can be found here:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/
>>  
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/>
>> sha1 is 9813469618230d15bf17763ca7f989e414608a0f
>> 
>> Please VOTE
>> 
>> [+1] let's ship it!
>> [+0] don't care
>> [-1] stop there is a ${showstopper}
>> 
>> 
>> The VOTE is open for 72h.
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
> 

[VOTE] Release Apache xBean-4.20

[Mark Struberg]

hiho!

I'd like to call a VOTE on releasing xbean-4.20.

The only change is to switch back to a dependency-reduced pom.
4.18 und 4.19 did leak the shaded ASM dependencies down to consumers. This 
defeats the shading.
Downstream projects can of course use exclude lists, but since the artifactId 
changes rather quickly it would be great to not leak those artifacts.


The staging repository is here:
https://repository.apache.org/content/repositories/orgapachegeronimo-1139 


The source zip can be found here:
https://repository.apache.org/content/repositories/orgapachegeronimo-1139/org/apache/xbean/xbean/4.20/
 

sha1 is 9813469618230d15bf17763ca7f989e414608a0f

Please VOTE

[+1] let's ship it!
[+0] don't care
[-1] stop there is a ${showstopper}


The VOTE is open for 72h.

txs and LieGrue,
strub

Re: BATCHEE release?

[Mark Struberg]

 while coming along, I'd also update BATCHEE to fit EE8 and update to 
1.0.0-SNAPSHOT.Any objections?
LieGrue,strub

On Wednesday, 28 April 2021, 08:44:08 CEST, Francois Papon 
 wrote:  
 
 Hi Mark,

Sounds good to me :)

Thanks!

regards,

François
fpa...@apache.org

Le 28/04/2021 à 07:13, Mark Struberg a écrit :
> hi folks!
>
> I'd like to do a BATCHEE release soon. 
> Anything you want to work on then ping me.
>
> txs and LieGrue,
> strub
>
  

BATCHEE release?

[Mark Struberg]

hi folks!

I'd like to do a BATCHEE release soon. 
Anything you want to work on then ping me.

txs and LieGrue,
strub

Re: [VOTE] Release Geronimo Arthur 1.0.2

[Mark Struberg]

+1

LieGrue,
strub


> Am 11.02.2021 um 12:16 schrieb Romain Manni-Bucau :
> 
> Hi all,
> 
> I'd like to release Arthur 1.0.2 as mentionned on the list.
> It is only about ensuring our maven plugin resolves knights properly:
> 
> GERONIMO-6803    Knight 
> not properly downloaded by maven plugin 
> 
> 
> Staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1137/ 
> 
> Sources: https://dist.apache.org/repos/dist/dev/geronimo/arthur/ 
> 
> Tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git;a=commit;h=8c1622696e62d99d95e8942f8f2f1d85ab05d34f
>  
> 
> My key is the same than for last releases.
> 
> Please vote:
> 
> [ ] +1 release it
> [ ] -1 don't release it cause ${blocker}
> 
> Vote will be opened as usual for 3 days or as needed.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Release Apache Geronimo BatchEE 0.6

[Mark Struberg]

yesss,

+1

LieGrue,
strub

> Am 12.11.2020 um 12:39 schrieb Romain Manni-Bucau :
> 
> Hi all,
> 
> Here is the vote for batchee 0.6.
> Here is the changelog: 
> 
> 1–14 of 14View in Issue Navigator 
> <https://issues.apache.org/jira/issues/?jql=project%20=%2012314924%20AND%20fixVersion%20=%2012342264%20ORDER%20BY%20priority%20DESC,%20key%20ASC>
> P T   Key Summary AssigneeStatus
>   BATCHEE-135 <https://issues.apache.org/jira/browse/BATCHEE-135> 
> Command "Names" not working 
> <https://issues.apache.org/jira/browse/BATCHEE-135> Reinhard Sandtner 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=rsandtner>   
> RESOLVED
>   BATCHEE-108 <https://issues.apache.org/jira/browse/BATCHEE-108> 
> Job entities don't support optimistic locking 
> <https://issues.apache.org/jira/browse/BATCHEE-108>   Unassigned  OPEN
>   BATCHEE-126 <https://issues.apache.org/jira/browse/BATCHEE-126> 
> upgrade to tomee-7.0.4 <https://issues.apache.org/jira/browse/BATCHEE-126>
>   Mark Struberg 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>OPEN
>   BATCHEE-131 <https://issues.apache.org/jira/browse/BATCHEE-131> 
> JBatchController Service does not stop JBatch on shutdown 
> <https://issues.apache.org/jira/browse/BATCHEE-131>   Mark Struberg 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>OPEN
>   BATCHEE-132 <https://issues.apache.org/jira/browse/BATCHEE-132> 
> Ensure ServicesManager has a lifecycle (= adds close()) 
> <https://issues.apache.org/jira/browse/BATCHEE-132> Romain Manni-Bucau 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
>  RESOLVED
>   BATCHEE-133 <https://issues.apache.org/jira/browse/BATCHEE-133> 
> remote stop dosen't work with BatchEE-CLI 
> <https://issues.apache.org/jira/browse/BATCHEE-133>   Mark Struberg 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>
> RESOLVED
>   BATCHEE-134 <https://issues.apache.org/jira/browse/BATCHEE-134> 
> EJB Timer not working in CLI Runner 
> <https://issues.apache.org/jira/browse/BATCHEE-134> Unassigned  RESOLVED
>   BATCHEE-136 <https://issues.apache.org/jira/browse/BATCHEE-136> 
> Errors thrown in JobListeners aren't printed at all 
> <https://issues.apache.org/jira/browse/BATCHEE-136> Romain Manni-Bucau 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
>  RESOLVED
>   BATCHEE-141 <https://issues.apache.org/jira/browse/BATCHEE-141> 
> Upgrade TomEE <https://issues.apache.org/jira/browse/BATCHEE-141>   
> Romain Manni-Bucau 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
>  RESOLVED
>   BATCHEE-142 <https://issues.apache.org/jira/browse/BATCHEE-142> 
> Add CDI SE lifecycle (cli) 
> <https://issues.apache.org/jira/browse/BATCHEE-142>  Romain Manni-Bucau 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
>  RESOLVED
>   BATCHEE-143 <https://issues.apache.org/jira/browse/BATCHEE-143> 
> Add jakarta module for jbatch impl 
> <https://issues.apache.org/jira/browse/BATCHEE-143>  Romain Manni-Bucau 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
>  RESOLVED
>   BATCHEE-138 <https://issues.apache.org/jira/browse/BATCHEE-138> 
> Failure in Read-Process-Write Loop: Somehow one of the metrics was zero 
> <https://issues.apache.org/jira/browse/BATCHEE-138> Romain Manni-Bucau 
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=romain.manni-bucau>
>  RESOLVED
>   BATCHEE-139 <https://issues.apache.org/jira/browse/BATCHEE-139> 
> JPAPersistenceManagerService throws a Nullpointer in case an invalid 
> execution id is passed to getJobExecution 
> <https://issues.apache.org/jira/browse/BATCHEE-139>  Unassigned  
> RESOLVED
>   BATCHEE-140 <https://issues.apache.org/jira/browse/BATCHEE-140> 
> Propagate JobOperatorImpl instance to SimpleJobExecutionCallbackService 
> properly <https://issues.apache.org/jira/browse/BATCHEE-140>Unassigned
>   RESOLVED
> 1–14 of 14
> 
> Tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-batchee.git;a=tag;h=b8f6a9427014a2c512de84c0cf074e143ddf82e8
>  
> <https://gitbox.apache.org/repos/asf?p=geronimo-batchee.git;a=tag;h=b8f6a9427014a2c512de84c0c

Re: [VOTE] Release Apache Geronimo JWT Auth 1.0.4

[Mark Struberg]

+1

LieGrue,
strub


> Am 11.11.2020 um 21:53 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> Here is the vote for our JWT Auth implementation v 1.0.4.
> 
> The issues are:
> 
> GERONIMO-6757 Changes to 
> make geronimo-jwt-auth work with Aries CDI 
> UnassignedOPENGERONIMO-6765
>  Add basic OSGi support 
> to germino-jwt-auth 
> Raymond Augé 
> OPEN
> 
> Tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-jwt-auth.git;a=tag;h=6e10f2d71f9786e77b46466e99cbe3f7db18e12d
>  
> 
> Dist area: https://dist.apache.org/repos/dist/dev/geronimo/jwt-auth/ 
> 
> Staging: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1134/ 
> 
> My key is the same than for last votes.
> 
> Please vote:
> 
> [ ] +1 release
> [ ] -1 don't release ${cause}
> 
> Vote will be open as usual for 3 full days or until we get enough binding 
> votes.
> 
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Release Apache Geronimo Simple JCache 1.0.5

[Mark Struberg]

 +1
LieGrue,strub

On Tuesday, 10 November 2020, 18:29:23 CET, Jean-Baptiste Onofre 
 wrote:  
 
 +1 (binding)
ThanksRegardsJB


Le 10 nov. 2020 à 18:10, Francois Papon  a écrit :
 

+1 (non-binding)

thanks!

regards,
 
 François
fpa...@apache.org Le 10/11/2020 à 15:36, Romain Manni-Bucau a écrit :
  
 
Hi everyone, 
  Here is the vote for our JCache implementation. The only issue it fixes is: 
   
|  |  | GERONIMO-6789 | Simple JCache extension does not work well with cdi 
(cdi helper not found) | Romain Manni-Bucau | RESOLVED |


  Tag: 
https://gitbox.apache.org/repos/asf?p=geronimo-jcache-simple.git;a=commit;h=0f80de0706534d19d9bca0f4aa22b6b330996971
 Dist area: https://dist.apache.org/repos/dist/dev/geronimo/simple-jcache/ 
Staging: 
https://repository.apache.org/content/repositories/orgapachegeronimo-1133/ My 
key is the same than for last votes. 
  Please vote: 
  [ ] +1 release [ ] -1 don't release ${cause} 
  Vote will be open as usual for 3 full days or until we get enough binding 
votes. 
 Romain Manni-Bucau
 @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book 
 
  

Re: [VOTE] [RESULT] Release geronimo-openapi-1.0.13

[Mark Struberg]

Hi!

The VOTE did pass with the following:

+1: Ray, Romain, Francois, Daniel, Jean-Baptiste, Jean-Louis, Mark
No -1 nor 0

txs for voting and LieGrue,
strub


> Am 16.10.2020 um 15:20 schrieb Mark Struberg :
> 
> 
> 
> Hi!
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/ 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1132/>
> 
> 
> 
> source jars can be found at
> https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/>
> sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> Here is my own one for the start.
> +1
> 
> txs and LieGrue,
> strub

Re: [VOTE] [RESULT] geronimo jsonp, jsonb, security, validation releases

[Mark Struberg]

hi!

The VOTE did pass with the following:

+1 Ray, Daniel, JBO, Romain, Francois, Mark
No -1 nor 0

txs to all who voted!
I'll gonna publish the artifacts.

LieGrue,
strub


> Am 15.10.2020 um 22:38 schrieb Mark Struberg :
> 
> Hi!
> 
> I want to call a VOTE on releasing 
> 
> 
> geronimo-json_1.1_spec-1.5
> geronimo-jsonb_1.0_spec-1.4
> geronimo-security_1.0_spec-1.1
> geronimo-validation_2.0_spec-1.1
> 
> The only difference to the previous releases is the addition of jpms module 
> names via manifest by updating to genesis-flava8-2.4.
> I did run the release with Java8. Have fun!
> 
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1131/ 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1131/>
> 
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> Here is my own one for the start.
> +1
> 
> txs and LieGrue,
> strub

Re: [VOTE] [RESULT] Release geronimo-jcdi_2.0 spec api version 1.3

[Mark Struberg]

hi!

The VOTE did pass with the following:

+1 Ray, Romain, Daniel, JBO, Francois, Mark
No -1 nor 0

txs to all who voted!
I'll gonna publish the artifacts.

LieGrue,
strub


> Am 15.10.2020 um 19:40 schrieb Mark Struberg :
> 
> Hi!
> 
> I want to call a VOTE on releasing 
> geronimo-jcdi_2.0 1.3
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1130/ 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1130/>
> 
> source jars can be found
> https://repository.apache.org/content/repositories/orgapachegeronimo-1130/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.3/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1130/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.3/>
> sha1 3b12c73bef67722578fa68874074879fd0473748
> 
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> Here is my own one for the start.
> +1
> 
> txs and LieGrue,
> strub
> 

Re: [VOTE] [RESULT] Release geronimo-jcdi_1.0 and 1.1 spec jars

[Mark Struberg]

hi!

The VOTE did pass with the following:

+1 Ray, Romain, Daniel, JBO, Francois, Mark
No -1 nor 0

txs to all who voted!
I'll gonna publish the artifacts.

LieGrue,
strub


> Am 15.10.2020 um 19:37 schrieb Mark Struberg :
> 
> Hi!
> 
> I want to call a VOTE on releasing 
> geronimo-jcdi_1.0-1.1 and
> geronimo-jcdi_1.1-1.1
> 
> The staging repo is:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1129/ 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1129/>
> 
> source jars can be found
> https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.0_spec/1.1/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.0_spec/1.1/>
> sha1 54f20c989d20cb56363c88b9884376821b6b0a4e
> 
> and 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.1_spec/1.1/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.1_spec/1.1/>
> sha1 8ef821f792a6d1286edf719774e8ea32ded145b6
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
> 
> The VOTE is open for 72h
> 
> Here is my own one for the start.
> +1
> 
> txs and LieGrue,
> strub
> 
> 

[VOTE] Release geronimo-openapi-1.0.13

[Mark Struberg]

Hi!

Here is the staging repo
https://repository.apache.org/content/repositories/orgapachegeronimo-1132/ 




source jars can be found at
https://repository.apache.org/content/repositories/orgapachegeronimo-1132/org/apache/geronimo/geronimo-openapi/1.0.13/
 

sha1 074ecb59b23e5a8550126e360dc244c75bd5dc6d

Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop, there is a ${showstopper}

The VOTE is open for 72h

Here is my own one for the start.
+1

txs and LieGrue,
strub

Re: jira ticket mess

[Mark Struberg]

sounds like a plan!


> Am 16.10.2020 um 13:49 schrieb Romain Manni-Bucau :
> 
> Hi Mark,
> 
> We put the project in the version, works not back and enables filtering as 
> well as we would have subprojects. It also avoids to have to request new 
> component each time we add a project so think it is a good compromise for us.
> 
> 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 ven. 16 oct. 2020 à 13:39, Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> a écrit :
> Hi,
> 
> What about generalizing use of fix version containing the "target" project 
> (and we do for openapi or metrics) ?
> 
> I think both component + fix version would be enough to clearly identify 
> release content/release notes.
> 
> Regards
> JB
> 
> 
> > Le 16 oct. 2020 à 13:34, Mark Struberg  > <mailto:strub...@yahoo.de>> a écrit :
> > 
> > hi folks!
> > 
> > Geronimo is an umbrella project. We have tons of tickets, but we actually 
> > cannot make much sense of it tracking wise as the versions in JIRA is per 
> > project and not per module.
> > 
> > That means if we do a release, we do not really have a clean track about 
> > what actually got fixed, right?
> > 
> > Otoh if we would do a distinct JIRA project per actual release artifact, 
> > then we would have 100++ different jira projecs? Just think about all the 
> > many dozen geronimo-spec jars.
> > 
> > How do we want to cope with this in the future? Does anyone have an idea 
> > how this can be improved?
> > 
> > txs and LieGrue,
> > strub
> > 
> 

jira ticket mess

[Mark Struberg]

hi folks!

Geronimo is an umbrella project. We have tons of tickets, but we actually 
cannot make much sense of it tracking wise as the versions in JIRA is per 
project and not per module.

That means if we do a release, we do not really have a clean track about what 
actually got fixed, right?

Otoh if we would do a distinct JIRA project per actual release artifact, then 
we would have 100++ different jira projecs? Just think about all the many dozen 
geronimo-spec jars.

How do we want to cope with this in the future? Does anyone have an idea how 
this can be improved?

txs and LieGrue,
strub

[VOTE] geronimo jsonp, jsonb, security, validation releases

[Mark Struberg]

Hi!

I want to call a VOTE on releasing 


geronimo-json_1.1_spec-1.5
geronimo-jsonb_1.0_spec-1.4
geronimo-security_1.0_spec-1.1
geronimo-validation_2.0_spec-1.1

The only difference to the previous releases is the addition of jpms module 
names via manifest by updating to genesis-flava8-2.4.
I did run the release with Java8. Have fun!


The staging repo is:
https://repository.apache.org/content/repositories/orgapachegeronimo-1131/ 



Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop, there is a ${showstopper}

The VOTE is open for 72h

Here is my own one for the start.
+1

txs and LieGrue,
strub

[jira] [Resolved] (GERONIMO-6784) ClassCastException in javax.enterprise.util.AnnotationLiteral#hashCode

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg resolved GERONIMO-6784.
-
Resolution: Fixed

Thank you Arne, applied and release is under vote!

> ClassCastException in javax.enterprise.util.AnnotationLiteral#hashCode
> --
>
> Key: GERONIMO-6784
> URL: https://issues.apache.org/jira/browse/GERONIMO-6784
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Arne Limburg
>    Assignee: Mark Struberg
>Priority: Major
>
> In jcdi-spec in javax.enterprise.util.AnnotationLiteral#hashCode the type is 
> checked for boolean[] and then casted to long[]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[VOTE] Release geronimo-jcdi_2.0 spec api version 1.3

[Mark Struberg]

Hi!

I want to call a VOTE on releasing 
geronimo-jcdi_2.0 1.3

The staging repo is:
https://repository.apache.org/content/repositories/orgapachegeronimo-1130/

source jars can be found
https://repository.apache.org/content/repositories/orgapachegeronimo-1130/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.3/
 

sha1 3b12c73bef67722578fa68874074879fd0473748


Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop, there is a ${showstopper}

The VOTE is open for 72h

Here is my own one for the start.
+1

txs and LieGrue,
strub

[VOTE] Release geronimo-jcdi_1.0 and 1.1 spec jars

[Mark Struberg]

Hi!

I want to call a VOTE on releasing 
geronimo-jcdi_1.0-1.1 and
geronimo-jcdi_1.1-1.1

The staging repo is:
https://repository.apache.org/content/repositories/orgapachegeronimo-1129/ 


source jars can be found
https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.0_spec/1.1/
 

sha1 54f20c989d20cb56363c88b9884376821b6b0a4e

and 
https://repository.apache.org/content/repositories/orgapachegeronimo-1129/org/apache/geronimo/specs/geronimo-jcdi_1.1_spec/1.1/
 

sha1 8ef821f792a6d1286edf719774e8ea32ded145b6

Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop, there is a ${showstopper}

The VOTE is open for 72h

Here is my own one for the start.
+1

txs and LieGrue,
strub

[DISCUSS] release a few specs

[Mark Struberg]

hi!

I'd love to release a few specs today. They do not have any API changes but are 
important nonetheless:

The following 3 specs did get an important fix against a ClassCastException
https://issues.apache.org/jira/browse/GERONIMO-6784 


Txs to Arne Limburg for this fix!

This affects 3 spec artifacts:
*   geronimo-jcdi_1.0_spec
*   geronimo-jcdi_1.1_spec
*   geronimo-jcdi_2.0_spec


The other category of specs I'd love to release fall into the Java9 Module 
updates I prepared with genesis java8-flava:
*   geronimo-jcdi_2.0_spec
*   geronimo-json_1.1_spec
*   geronimo-jsonb_1.0_spec
*   geronimo-security_1.0_spec
*   geronimo-validation_2.0_spec

Gonna start rolling those releases soon.
So cry up now ;)

txs and LieGrue,
strub

[jira] [Assigned] (GERONIMO-6784) ClassCastException in javax.enterprise.util.AnnotationLiteral#hashCode

[Mark Struberg (Jira)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Struberg reassigned GERONIMO-6784:
---

Assignee: Mark Struberg

> ClassCastException in javax.enterprise.util.AnnotationLiteral#hashCode
> --
>
> Key: GERONIMO-6784
> URL: https://issues.apache.org/jira/browse/GERONIMO-6784
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Arne Limburg
>    Assignee: Mark Struberg
>Priority: Major
>
> In jcdi-spec in javax.enterprise.util.AnnotationLiteral#hashCode the type is 
> checked for boolean[] and then casted to long[]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] geronimo-javamail_1.6_spec 1.0.0

[Mark Struberg]

+1

LieGrue,
strub


> Am 13.10.2020 um 16:59 schrieb Jean-Louis MONTEIRO :
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-javamail_1.6_spec 1.0.0 
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1127 
> 
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1127/org/apache/geronimo/specs/geronimo-javamail_1.6_spec/1.0.0/geronimo-javamail_1.6_spec-1.0.0-source-release.zip
>  
> 
> 
> SVN tag
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-javamail_1.6_spec-1.0.0/
>  
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> -- 
> Jean-Louis

Re: [VOTE] Geronimo JavaMail Impl and Provider 1.0.0 for javamail spec 1.6

[Mark Struberg]

+1

LieGrue,
strub


> Am 13.10.2020 um 17:04 schrieb Jean-Louis MONTEIRO :
> 
> Hi!
> 
> I’d like to call a VOTE on the Geronimo JavaMail Impl and Provider for 
> javamail spec 1.6
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1128 
> 
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-1128/org/apache/geronimo/javamail/geronimo-javamail_1.6/1.0.0/geronimo-javamail_1.6-1.0.0-source-release.zip
>  
> 
> 
> SVN tag
> https://svn.apache.org/repos/asf/geronimo/javamail/tags/geronimo-javamail_1.6-1.0.0/
>  
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> -- 
> Jean-Louis

[DISCUSS] release g-openapi?

[Mark Struberg]

hi folks!

Got asked for a geronimo-openapi release.
There seems to be a nasty encoding issue which already got fixed it seems

https://github.com/apache/geronimo-openapi/commit/73e531169da27c6939eea5d944e0bf04c5173190
 


I can roll a release if you want.

txs and LieGrue,
strub

Re: [VOTE] Apache Geronimo XBean 4.18

[Mark Struberg]

+1

LieGrue,
strub


> Am 21.09.2020 um 08:21 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> Here is the vote for xbean 4.18 which provides asm9 shade.
> 
> Here is the tag: 
> http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.18/ 
>  (rev 
> 1881880)
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1126/ 
> 
> Here is the dist area:  
> https://dist.apache.org/repos/dist/dev/geronimo/xbean/ 
> 
> My Key is the same as last time.
> 
> Please vote:
> 
> [ ] +1 release it
> [ ] -1 cause ${reason}
> 
> Vote will be open for 3 days or until we get enough bindings as usual.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Release Geronimo Health v2.0.0 and Geronimo Metrics 1.0.5

[Mark Struberg]

+1

LieGrue,
strub


> Am 15.09.2020 um 14:31 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> I'd like to release our microprofile Health implementation in v2.0.0 and 
> Metrics implementation in v1.0.5.
> 
> Main change is to support the new health spec (3.0.0-RC3) which drops @Health 
> and new metrics spec version (3.0.0-RC2) which reworked global tag handling.
> 
> Tags are here:
> - health: 
> https://gitbox.apache.org/repos/asf?p=geronimo-health.git;a=commit;h=97b8a288b17686ae5ea8ee56087b7fe026743030
>  
> 
> - metrics:
> Staging repos are there: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1125/ 
> 
> - health: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1125/org/apache/geronimo/geronimo-health-parent/2.0.0/
>  
> 
> - metrics: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1125/org/apache/geronimo/geronimo-metrics-parent/1.0.5/
>  
> 
> Sources are there:
> - health: https://dist.apache.org/repos/dist/dev/geronimo/health/ 
> 
> - metrics: https://dist.apache.org/repos/dist/dev/geronimo/metrics/ 
> 
> 
> And my key is still the same.
> 
> Please vote:
> 
> [ ] +1 let it go out
> [ ] -1 ${because X}
> 
> Vote will stay open for 3 days or we get 3 +1 bindings vote as usual.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Apache Geronimo Specs JCDI_2.0 1.2, Annotation_1.3 1.3, AtInject_1.0 1.2, Interceptor_1.2 1.2, JSONP_1.1 1.4, JSONB_1.0 1.3

[Mark Struberg]

+1 because it allows us to more forward quickly.

Over the mid- and long-term we will need a separate branch/project I fear. 
There are already slight differences in e.g. EJB, and a few other specs.
But for now this is sufficient enough for people to start playing with. 
Just keep in mind that we will finally change artifact coordinates!

LieGrue,
strub


> Am 28.04.2020 um 19:28 schrieb Romain Manni-Bucau :
> 
> 
> 
> Le mar. 28 avr. 2020 à 18:25, Mark Struberg  <mailto:strub...@yahoo.de>> a écrit :
> As explained in the other thread:
> 
> What is the difference between the various specs and their previous versions?
> Afaict the only difference is jakartaEE, and we WILL  NOT MANAGE to do all 
> via simple replacement. This is an absolute dead end. 
> 
> Mark, you keep saying that but each time I ask for a proof of that you never 
> answer.
> Most of the spec are 1-1 (it was the deal of jakartaee8 and some spec had 
> been forbidden to replace/remove anything).
> So please list the diff to let us fix that point if accurate.
>  
> There have been plenty of smallish methods removed in e.g. EJB and servlet. 
> But also in other specs. So we WILL need to go full scale. And I also expect 
> more changes to come for JakartaEE9.
> 
> 
> Ok, think it is your method removal ;).
> It is not that accurate for this vote, both jars are not in the scope of this 
> vote.
> 
> I agree on EE9 point and here we will just create the jar from scratch as 
> usual, with the right package directly, no ambiguity or discussion IMHO.
>  
> 
> EE8 is FINISHED. There is NO change!
> 
> Does not mean we don't need to release the jar, please just have a look to 
> the versions of this thread (which is <1/6  of all specs), spec were finished 
> when we did 1.0 but we are at 1.4 for some jars so not a point for me.
>  
> 
> All which happens is done in JakartaEE. And we have all the work done since a 
> year?
> I could do a release of those jars today.
> 
> If you can do all jakarta jars I'm happy to cancel this vote as mentionned 
> already, my goal was just to get jakarta artifacts for free (and this is what 
> this vote does) to enable the CDI-SE/JSON-B case which starts to get pressure 
> to be useable in jakarta namespace more than others.
>  
> Also your list of specs is not final. There is quite a few missing.
> 
> Not sure what you mean, I released the ones I announce for CDI SE + JSON-B 
> stacks.
>  
> 
> So why not release from here?
> http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 
> <http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/>
> 
> Not sure what would be the point to create another branch, we can keep specs/ 
> still it is specs, no?
> 
> However, I'm -1 to change the artifact id to contain jakarta. Worse case we 
> could do geronimo--api to try to simplify the naming, avoid a 
> 2-versions based convention and be less rude to end user + use a jpms 
> friendly default name (even if we put an automatic name it avoids issues in 
> some envs/ide).
>  
> 
> Actually I'd move this to 
> 
> http://svn.apache.org/repos/asf/geronimo/jakarta-specs/trunk 
> <http://svn.apache.org/repos/asf/geronimo/jakarta-specs/trunk>
> 
> If we would move anything I would try to use gitbox but can wait after the 
> first release which is, IMHO, the most urgent.
>  
> 
> and then do the release. 
> 
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 28.04.2020 um 07:59 schrieb Romain Manni-Bucau > <mailto:rmannibu...@gmail.com>>:
>> 
>> Hi everyone,
>> 
>> Here is the vote for some of our spec with jakarta shades.
>> 
>> Tags:
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.2/
>>  
>> <http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.2/>
>>  (rev 1877103)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.3_spec-1.3/
>>  
>> <http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.3_spec-1.3/>
>>  (rev 1877106)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.2/
>>  
>> <http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.2/>
>>  (rev 1877109)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.2_spec-1.2/
>>  
>> <http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.2_spec-1.2/>
>>  (rev 1877112)
>> - 
>> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-json_1.1_spec-1.4/
>>  
>>

Re: [VOTE] Apache Geronimo Specs JCDI_2.0 1.2, Annotation_1.3 1.3, AtInject_1.0 1.2, Interceptor_1.2 1.2, JSONP_1.1 1.4, JSONB_1.0 1.3

[Mark Struberg]

As explained in the other thread:

What is the difference between the various specs and their previous versions?
Afaict the only difference is jakartaEE, and we WILL  NOT MANAGE to do all via 
simple replacement. This is an absolute dead end. 
There have been plenty of smallish methods removed in e.g. EJB and servlet. But 
also in other specs. So we WILL need to go full scale. And I also expect more 
changes to come for JakartaEE9.

EE8 is FINISHED. There is NO change!

All which happens is done in JakartaEE. And we have all the work done since a 
year?
I could do a release of those jars today.
Also your list of specs is not final. There is quite a few missing.

So why not release from here?
http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ 


Actually I'd move this to 

http://svn.apache.org/repos/asf/geronimo/jakarta-specs/trunk 


and then do the release.


LieGrue,
strub



> Am 28.04.2020 um 07:59 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> Here is the vote for some of our spec with jakarta shades.
> 
> Tags:
> - 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.2/
>  
> 
>  (rev 1877103)
> - 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-annotation_1.3_spec-1.3/
>  
> 
>  (rev 1877106)
> - 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-atinject_1.0_spec-1.2/
>  
> 
>  (rev 1877109)
> - 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-interceptor_1.2_spec-1.2/
>  
> 
>  (rev 1877112)
> - 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-json_1.1_spec-1.4/
>  
> 
>  (rev 1877115)
> - 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsonb_1.0_spec-1.3/
>  
> 
>  (rev 1877118)
> Dist area: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1124 
> 
> Staging repo: https://dist.apache.org/repos/dist/dev/geronimo/specs/ 
> 
> My key is still the same.
> 
> Please vote:
> 
> [ ] +1 release it
> [ ] -1 dont' release it ${cause}
> 
> Vote is open for 3 days or until we get enough bindings as usual.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: Jakarta artifacts?

[Mark Struberg]

Why is there any pain?
There is _nothing_ which we will change for the current specs. They are binary 
verified and frozen.
The only thing we changed in the last 2 years has been the java9 module name, 
but that is different in jakartaee anyway plus it's no code change but just a 
maven thingy.

LieGrue,
strub


> Am 28.04.2020 um 10:38 schrieb Romain Manni-Bucau :
> 
> Clearly the shade option is easier today because it does not require to 
> maintain 2 branches.
> 
> Do you have pointers on the removed methods? Most specs I reviewed were just 
> 1-1.
> Anyway, it is a first step for us to enable people to play with jakarta 
> package, we can still adjust things and if the fork is too big we would have 
> to use jakarta branch but it would be a pain for no gain IMHO.
> If it is just about dropping a few methods we can add a shade transformer to 
> do it IMHO.
> 
> 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. 28 avr. 2020 à 10:30, Mark Struberg  <mailto:strub...@yahoo.de>> a écrit :
> We also have a branch for jakartaee already.
> 
> The question is which one is easier. There are btw slight differences. It is 
> NOT 1:1! Some methods got removed!
> So I'd rather go the branch way.
> 
> LieGrue,
> strub
> 
>> Am 28.04.2020 um 07:37 schrieb Romain Manni-Bucau > <mailto:rmannibu...@gmail.com>>:
>> 
>> Hi everyone,
>> 
>> Should we release jakarta artifacts?
>> Short term I'm just expecting a shade added to the default artifact since 
>> for now it is 1-1 and for jakarta9 we would do the new bundle/artifact as 
>> usual probably (seems the less costly compromise to me).
>> 
>> If so (we do it now) I can take CDI SE stack + JSONB stack at my charge.
>> Happy to get help if anyone is interested.
>> 
>> 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>

Re: Jakarta artifacts?

[Mark Struberg]

We also have a branch for jakartaee already.

The question is which one is easier. There are btw slight differences. It is 
NOT 1:1! Some methods got removed!
So I'd rather go the branch way.

LieGrue,
strub

> Am 28.04.2020 um 07:37 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> Should we release jakarta artifacts?
> Short term I'm just expecting a shade added to the default artifact since for 
> now it is 1-1 and for jakarta9 we would do the new bundle/artifact as usual 
> probably (seems the less costly compromise to me).
> 
> If so (we do it now) I can take CDI SE stack + JSONB stack at my charge.
> Happy to get help if anyone is interested.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Apache Geronimo XBean 4.17

[Mark Struberg]

+1LieGrue,strubAm 27.04.2020 um 16:47 schrieb Romain Manni-Bucau :Hi everyone,Here is the vote for xbean 4.17 which provides asm8 shade.Here is the tag: http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.17/ (rev 1877082)Here is the staging repo: https://repository.apache.org/content/repositories/orgapachegeronimo-1123Here is the dist area: https://dist.apache.org/repos/dist/dev/geronimo/xbean/My Key is the same than last time.Please vote:[ ] +1 release it[ ] -1 cause ${blocker}Vote will be opened for 3 days or until we get enough bindings as usual.Romain Manni-Bucau@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

[DISCUSS] JakartaEE - continue rolling our own API jars vs use official ones?

[Mark Struberg]

Hi folks!

JakartaEE moved to the Eclipse Foundation and all the APIs are now available 
without much restrictions.
There are 4 potentially problematic issues with the 'official' spec APIs:

1.) Most of them are EPLv2 licensed. This is a catB license [1] and 
weak-copyleft. That means we MUST add attribution and MUST provide a source 
code download. And of course not only we need to do this, but reciprocallly 
also all the downstream consumers and users. 

2.) Our very own geronimo spec APIs used to have really great OSGi integration. 
The official API jars not so much. Some of them have no OSGi support at all. 
Did anyone look at the new official spec APIs? Can they be used in OSGi 
environments? I'm  not an OSGi person myself, so I need others to join into 
this discussion.

3.) Java8 support. Our own spec APIs mostly do not have module information. I 
just recently added this via MANIFEST.MF. The official spec API jars mostly use 
a module-info.class file. While this is technically preferable, it often bombs 
up with older low level bytecode manipulation libraries. The cause is that 
module-info.class must at least be a Java9 class file. So it's not really 
compatible with Java8. This doesn't happen that often - but I saw it happening. 
Is this really a problem? Or should we move to Java11 with JakartaEE anyway?

4.) When developing a new spec we cannot easily take the EPLv2 licensed sources 
over and modify them ourselves. We are bound to whatever Eclipse publishes as 
snapshot. Something to consider... 

Of course the upside of using the official API jars are:
* we do not need to do any bytecode compat signature checks anymore.
* the JavaDoc is MUCH better obviously

Anything I missed?

LieGrue,
strub

Re: Thinking to release geronimo-config-1.2.3

[Mark Struberg]

no, go on!

Anything missing?

LieGrue,
strub


> Am 12.04.2020 um 21:23 schrieb Raymond Auge :
> 
> This would be 1.2.3 with support for MP-Config 1.4 final.
> 
> Any objections?
> -- 
> Raymond Augé  (@rotty3000)
> Senior Software Architect Liferay, Inc.  (@Liferay)

Re: [VOTE] Release Apache Geronimo Metrics 3.0-M2

[Mark Struberg]

and mine as well

+1

LieGrue,
strub

> Am 13.04.2020 um 17:22 schrieb Romain Manni-Bucau :
> 
> Hi all,
> 
> Here is the vote for our Microprofile Metrics implementation.
> It brings our compliance to v3.0-M2 spec and also provides jars without jaxrs 
> part of the impl.
> 
> Tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-metrics.git;a=commit;h=b870aff24346cde82415d808138239d8283f2fd7
>  
> 
> Dist area: https://dist.apache.org/repos/dist/dev/geronimo/metrics/ 
> 
> Staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1122 
> 
> 
> Please vote:
> 
> [ ]+1
> [ ] -1 ${cause}
> 
> Vote will be opened as usual for 3 days or until we get enough binding votes.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] [RESULT] release Apache JPA-2.2 spec v1.1

[Mark Struberg]

Hi!

The VOTE did pass with the following:

+1: Jean-Baptiste, Romain, Raymond, Mark

No -1 nor 0

txs and LieGrue,
strub


> Am 16.03.2020 um 15:34 schrieb Raymond Auge :
> 
> +1
> 
> (I didn't see this email previously for some reason)
> 
> - Ray
> 
> On Sun, Mar 15, 2020 at 8:24 AM Mark Struberg  <mailto:strub...@yahoo.de>> wrote:
> my own +1
> 
> LieGrue,
> strub
> 
>> Am 14.03.2020 um 12:52 schrieb Romain Manni-Bucau > <mailto:rmannibu...@gmail.com>>:
>> 
>> +1
>> 
>> Le sam. 14 mars 2020 à 11:09, Jean-Baptiste Onofre > <mailto:j...@nanthrax.net>> a écrit :
>> +1 (non binding)
>> 
>> Regards
>> JB
>> 
>>> Le 14 mars 2020 à 08:53, Mark Struberg >> <mailto:strub...@yahoo.de>> a écrit :
>>> 
>>> Good morning!
>>> 
>>> I'd like to call a VOTE on releasing Apache Geronimo JPA-2.2 spec API in 
>>> version 1.1.
>>> This is a maintenance release with just the automatic module name added in 
>>> the manifest file.
>>> 
>>> The staging repo is here:
>>> 
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1121 
>>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1121>
>>> 
>>> Sources are in 
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1121/org/apache/geronimo/specs/geronimo-jpa_2.2_spec/1.1/
>>>  
>>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1121/org/apache/geronimo/specs/geronimo-jpa_2.2_spec/1.1/>
>>> sha1 is 270c2f063683fc394b9ec37ab2ffeaaaec086ef3
>>> 
>>> Note: This release requires geronimo-genesis 2.4 which is currently up for 
>>> vote in another thread.
>>> The staging repo for it is 
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1120 
>>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1120>
>>> 
>>> 
>>> Please VOTE
>>> 
>>> [+1] yup, ship it
>>> [+0] meh, I don't care
>>> [-1] stop, there is a ${problem}
>>> 
>>> The VOTE is open for 72h.
>>> 
>>> txs and LieGrue,
>>> strub
>>> 
>> 
> 
> 
> 
> -- 
> Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
> Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay)

Re: [VOTE] [RESULT] release Apache Geronimo Genesis 2.4

[Mark Struberg]

Hi!

The VOTE did pass with the following:

+1: Romain, Raymond, Mark

No -1 nor 0

txs and LieGrue,
strub

> Am 13.03.2020 um 19:20 schrieb Mark Struberg :
> 
> hi folks!
> 
> I'd like to call a VOTE for Geronimo Genesis 2.4
> 
> I've upgraded apache-parent to the latest one (23) and also added handling to 
> generate Automatic-Module-Name entries in MANIFEST.MF.
> The default is the artifactId, but I suggest to set the property 
> 
> to the desired value, e.g. javax.persistence for JPA.
> 
> The staging repo is:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1120 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1120>
> 
> The source repo is 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1120/org/apache/geronimo/genesis/genesis/2.4/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1120/org/apache/geronimo/genesis/genesis/2.4/>
> sha1 is 8aa0f4efc7f2aabd1e021a7596e50257ba80f5b9
> 
> Please VOTE
> 
> [+1] yup, ship it
> [+0] meh, I don't care
> [-1] stop, there is a ${problem}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub
> 
> PS: next up will be jpa-2.2 and validation-2.0 which require this change for 
> OpenJPA. If you need anything else, then just tell me.

Re: [VOTE] release Apache JPA-2.2 spec v1.1

[Mark Struberg]

my own +1

LieGrue,
strub

> Am 14.03.2020 um 12:52 schrieb Romain Manni-Bucau :
> 
> +1
> 
> Le sam. 14 mars 2020 à 11:09, Jean-Baptiste Onofre  <mailto:j...@nanthrax.net>> a écrit :
> +1 (non binding)
> 
> Regards
> JB
> 
>> Le 14 mars 2020 à 08:53, Mark Struberg > <mailto:strub...@yahoo.de>> a écrit :
>> 
>> Good morning!
>> 
>> I'd like to call a VOTE on releasing Apache Geronimo JPA-2.2 spec API in 
>> version 1.1.
>> This is a maintenance release with just the automatic module name added in 
>> the manifest file.
>> 
>> The staging repo is here:
>> 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1121 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1121>
>> 
>> Sources are in 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1121/org/apache/geronimo/specs/geronimo-jpa_2.2_spec/1.1/
>>  
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1121/org/apache/geronimo/specs/geronimo-jpa_2.2_spec/1.1/>
>> sha1 is 270c2f063683fc394b9ec37ab2ffeaaaec086ef3
>> 
>> Note: This release requires geronimo-genesis 2.4 which is currently up for 
>> vote in another thread.
>> The staging repo for it is 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1120 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1120>
>> 
>> 
>> Please VOTE
>> 
>> [+1] yup, ship it
>> [+0] meh, I don't care
>> [-1] stop, there is a ${problem}
>> 
>> The VOTE is open for 72h.
>> 
>> txs and LieGrue,
>> strub
>> 
> 

Re: [VOTE] release Apache Geronimo Genesis 2.4

[Mark Struberg]

my own +1

LieGrue,
strub

> Am 13.03.2020 um 19:20 schrieb Mark Struberg :
> 
> hi folks!
> 
> I'd like to call a VOTE for Geronimo Genesis 2.4
> 
> I've upgraded apache-parent to the latest one (23) and also added handling to 
> generate Automatic-Module-Name entries in MANIFEST.MF.
> The default is the artifactId, but I suggest to set the property 
> 
> to the desired value, e.g. javax.persistence for JPA.
> 
> The staging repo is:
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1120 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1120>
> 
> The source repo is 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1120/org/apache/geronimo/genesis/genesis/2.4/
>  
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1120/org/apache/geronimo/genesis/genesis/2.4/>
> sha1 is 8aa0f4efc7f2aabd1e021a7596e50257ba80f5b9
> 
> Please VOTE
> 
> [+1] yup, ship it
> [+0] meh, I don't care
> [-1] stop, there is a ${problem}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub
> 
> PS: next up will be jpa-2.2 and validation-2.0 which require this change for 
> OpenJPA. If you need anything else, then just tell me.

[VOTE] release Apache JPA-2.2 spec v1.1

[Mark Struberg]

Good morning!

I'd like to call a VOTE on releasing Apache Geronimo JPA-2.2 spec API in 
version 1.1.
This is a maintenance release with just the automatic module name added in the 
manifest file.

The staging repo is here:

https://repository.apache.org/content/repositories/orgapachegeronimo-1121 


Sources are in 
https://repository.apache.org/content/repositories/orgapachegeronimo-1121/org/apache/geronimo/specs/geronimo-jpa_2.2_spec/1.1/
 

sha1 is 270c2f063683fc394b9ec37ab2ffeaaaec086ef3

Note: This release requires geronimo-genesis 2.4 which is currently up for vote 
in another thread.
The staging repo for it is 
https://repository.apache.org/content/repositories/orgapachegeronimo-1120 



Please VOTE

[+1] yup, ship it
[+0] meh, I don't care
[-1] stop, there is a ${problem}

The VOTE is open for 72h.

txs and LieGrue,
strub

[VOTE] release Apache Geronimo Genesis 2.4

[Mark Struberg]

hi folks!

I'd like to call a VOTE for Geronimo Genesis 2.4

I've upgraded apache-parent to the latest one (23) and also added handling to 
generate Automatic-Module-Name entries in MANIFEST.MF.
The default is the artifactId, but I suggest to set the property 

to the desired value, e.g. javax.persistence for JPA.

The staging repo is:

https://repository.apache.org/content/repositories/orgapachegeronimo-1120 


The source repo is 
https://repository.apache.org/content/repositories/orgapachegeronimo-1120/org/apache/geronimo/genesis/genesis/2.4/
 

sha1 is 8aa0f4efc7f2aabd1e021a7596e50257ba80f5b9

Please VOTE

[+1] yup, ship it
[+0] meh, I don't care
[-1] stop, there is a ${problem}

The VOTE is open for 72h.

txs and LieGrue,
strub

PS: next up will be jpa-2.2 and validation-2.0 which require this change for 
OpenJPA. If you need anything else, then just tell me.

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

[Mark Struberg]

Well, it's better than nothing and we are fine off. Btw, even in java14 you can 
run without it. Just disable jpms via flag.
That's the default in most companies anyway.

With having the automatic module name set we get most benefits without trashing 
Java8 projects.
Gonna release this now. Please shout if something is still missing/wrong!

LieGrue,
strub


> Am 13.03.2020 um 15:02 schrieb Romain Manni-Bucau :
> 
> Don't think there is any official name yet - means we'll probably break any 
> user of the names later. I saw a proposal to use java.cdi but was before 
> jakarta move so not sure today.
> 
> Side note: even if I agree jpms is a failure, it will soon be the only way to 
> compile at java rhythm so we should be compliant with it anyway. I'm also 
> thinking to small specs like json*, cdi where doing a jimage can make sense 
> to distribute standalone apps (i'm not speaking of server apps there).
> 
> 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 ven. 13 mars 2020 à 12:48, Mark Struberg  <mailto:strub...@yahoo.de>> a écrit :
> Btw, anyone has a clue what the module name for the cdi-2.0 api is?
> 
> Did not find anything in the published official jar...
> Am I just blind?
> 
> LieGrue,
> strub
> 
>> Am 13.03.2020 um 12:31 schrieb Mark Struberg > <mailto:strub...@yahoo.de>>:
>> 
>> I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.
>> 
>> JPMS has completely failed imo. The adoption rate in the industry is near 
>> zero.
>> Companies who need a module system use OSGi. The others use flat classpath. 
>> The isolation is a joke. Security wise it's useless.
>> So the only real benefit we'd have is out-of-the-box compilation with java14.
>> And for that the MANIFEST.MF entry is enough afaiu.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> 
>>> Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau >> <mailto:rmannibu...@gmail.com>>:
>>> 
>>> There are a few things to take into account I think:
>>> 
>>> 1. Maybe let's drop genesis completely
>>> 2. Module info is a pain but still the only way to be jlink compatible, 
>>> automatic name just enables compilation
>>> 
>>> I'd be to have a classified artifact with module info if we can otherwise 
>>> automatic name is ok.
>>> 
>>> Le ven. 13 mars 2020 à 11:26, Mark Struberg >> <mailto:strub...@yahoo.de>> a écrit :
>>> hi!
>>> 
>>> I think half-loud about enhancing flava8 to use the maven-jar plugin to 
>>> automatically provide a module name.
>>> It defaults to the artifact-id but can be tweaked by each module to include 
>>> a Automatic-Module-Name: entry in manifest.mf.
>>> 
>>> The reason why I do not like the module-info.class is that this often 
>>> breaks backward compat with many java8 projects. And there are still WAY 
>>> many companies using java8 only...
>>> 
>>> wdyt?
>>> 
>>> LieGrue,
>>> strub
>>> 
>> 
> 

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

[Mark Struberg]

Btw, anyone has a clue what the module name for the cdi-2.0 api is?

Did not find anything in the published official jar...
Am I just blind?

LieGrue,
strub

> Am 13.03.2020 um 12:31 schrieb Mark Struberg :
> 
> I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.
> 
> JPMS has completely failed imo. The adoption rate in the industry is near 
> zero.
> Companies who need a module system use OSGi. The others use flat classpath. 
> The isolation is a joke. Security wise it's useless.
> So the only real benefit we'd have is out-of-the-box compilation with java14.
> And for that the MANIFEST.MF entry is enough afaiu.
> 
> LieGrue,
> strub
> 
> 
> 
>> Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau > <mailto:rmannibu...@gmail.com>>:
>> 
>> There are a few things to take into account I think:
>> 
>> 1. Maybe let's drop genesis completely
>> 2. Module info is a pain but still the only way to be jlink compatible, 
>> automatic name just enables compilation
>> 
>> I'd be to have a classified artifact with module info if we can otherwise 
>> automatic name is ok.
>> 
>> Le ven. 13 mars 2020 à 11:26, Mark Struberg > <mailto:strub...@yahoo.de>> a écrit :
>> hi!
>> 
>> I think half-loud about enhancing flava8 to use the maven-jar plugin to 
>> automatically provide a module name.
>> It defaults to the artifact-id but can be tweaked by each module to include 
>> a Automatic-Module-Name: entry in manifest.mf.
>> 
>> The reason why I do not like the module-info.class is that this often breaks 
>> backward compat with many java8 projects. And there are still WAY many 
>> companies using java8 only...
>> 
>> wdyt?
>> 
>> LieGrue,
>> strub
>> 
> 

Re: enhance genesis-flava8 to use Automatic-Module-Name ?

[Mark Struberg]

I'd leave genesis-flava for now. We can get rid of it for jakarta.* maybe.

JPMS has completely failed imo. The adoption rate in the industry is near zero.
Companies who need a module system use OSGi. The others use flat classpath. The 
isolation is a joke. Security wise it's useless.
So the only real benefit we'd have is out-of-the-box compilation with java14.
And for that the MANIFEST.MF entry is enough afaiu.

LieGrue,
strub



> Am 13.03.2020 um 11:50 schrieb Romain Manni-Bucau :
> 
> There are a few things to take into account I think:
> 
> 1. Maybe let's drop genesis completely
> 2. Module info is a pain but still the only way to be jlink compatible, 
> automatic name just enables compilation
> 
> I'd be to have a classified artifact with module info if we can otherwise 
> automatic name is ok.
> 
> Le ven. 13 mars 2020 à 11:26, Mark Struberg  <mailto:strub...@yahoo.de>> a écrit :
> hi!
> 
> I think half-loud about enhancing flava8 to use the maven-jar plugin to 
> automatically provide a module name.
> It defaults to the artifact-id but can be tweaked by each module to include a 
> Automatic-Module-Name: entry in manifest.mf.
> 
> The reason why I do not like the module-info.class is that this often breaks 
> backward compat with many java8 projects. And there are still WAY many 
> companies using java8 only...
> 
> wdyt?
> 
> LieGrue,
> strub
> 

enhance genesis-flava8 to use Automatic-Module-Name ?

[Mark Struberg]

hi!

I think half-loud about enhancing flava8 to use the maven-jar plugin to 
automatically provide a module name.
It defaults to the artifact-id but can be tweaked by each module to include a 
Automatic-Module-Name: entry in manifest.mf.

The reason why I do not like the module-info.class is that this often breaks 
backward compat with many java8 projects. And there are still WAY many 
companies using java8 only...

wdyt?

LieGrue,
strub

Re: [VOTE] Release Geronimo JCache Simple 1.0.4

[Mark Struberg]

+1

LieGrue,
strub

> Am 17.02.2020 um 10:35 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> As mentionned on the list, here is the vote for our jcache implementation 
> fixing OSGi-CDI metadata.
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1119/ 
> 
> Here is the dev dist area: 
> https://dist.apache.org/repos/dist/dev/geronimo/simple-jcache/ 
> 
> Here is the tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-jcache-simple.git;a=tag;h=1de835fc912962b27efe0b10bfedafcab4fd4008
>  
> 
> My keys is still available in http://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> Please vote:
> 
>  [ ] +1 let's relese it
>  [ ] -1 cancel it because ${reason}
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Release Geronimo JCache Simple 1.0.3

[Mark Struberg]

+1 txs!

LieGrue,
strub

> Am 16.02.2020 um 18:48 schrieb Jean-Baptiste Onofré :
> 
> I maintain my +1. We will fix in next release. 
> 
> Regards 
> JB
> 
> Le dim. 16 f?vr. 2020 ? 18:33, Romain Manni-Bucau  <mailto:rmannibu...@gmail.com>> a ?crit :
> Hi guys,
> 
> I discovered an error in the default OSGi CDI extension name during the 
> registration (it is "implicit"). I will fix it on master.
> Since this release already enables to use the bundle in OSGi - only the 
> extension registration will be broken which is not yet mainstream I guess - 
> so I guess we can let it go (please don't sing ;)) and do a 1.0.4 tomorrow.
> Please let me know if it is a blocker for you - will commit the fix in the 
> 10mn.
> 
> Therefore here is my +1
> 
> 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 dim. 16 f?vr. 2020 ? 02:06, Cesar Hernandez  <mailto:cesargu...@gmail.com>> a ?crit :
> +1
> 
> El s?b., 15 feb. 2020 a las 14:31, Mark Struberg ( <mailto:strub...@yahoo.de>>) escribi?:
> +1
> 
> LieGrue,
> strub
> 
> Am 14.02.2020 um 09:22 schrieb Romain Manni-Bucau  <mailto:rmannibu...@gmail.com>>:
> 
> Hi everyone,
> 
> As mentionned on the list, here is our jcache implementation release vote.
> Main change is to enable to deploy it in OSGi adding the required metadata.
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1118 
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1118>
> Here is the dev dist area: 
> https://dist.apache.org/repos/dist/dev/geronimo/simple-jcache/ 
> <https://dist.apache.org/repos/dist/dev/geronimo/simple-jcache/>
> Here is the tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-jcache-simple.git;a=commit;h=67d00ea1d9d1775a549ce972ecb0856d35d419c7
>  
> <https://gitbox.apache.org/repos/asf?p=geronimo-jcache-simple.git;a=commit;h=67d00ea1d9d1775a549ce972ecb0856d35d419c7>
> My keys is still available in http://svn.apache.org/repos/asf/geronimo/KEYS 
> <http://svn.apache.org/repos/asf/geronimo/KEYS>
> 
> Please vote:
> 
>  [ ] +1 let's relese it
>  [ ] -1 cancel it because ${reason}
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
> 
> 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>
> 
> 
> -- 
> Atentamente:
> C?sar Hern?ndez.

Re: [VOTE] Release Geronimo JCache Simple 1.0.3

[Mark Struberg]

+1

LieGrue,
strub

> Am 14.02.2020 um 09:22 schrieb Romain Manni-Bucau :
> 
> Hi everyone,
> 
> As mentionned on the list, here is our jcache implementation release vote.
> Main change is to enable to deploy it in OSGi adding the required metadata.
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1118 
> 
> Here is the dev dist area: 
> https://dist.apache.org/repos/dist/dev/geronimo/simple-jcache/ 
> 
> Here is the tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-jcache-simple.git;a=commit;h=67d00ea1d9d1775a549ce972ecb0856d35d419c7
>  
> 
> My keys is still available in http://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> Please vote:
> 
>  [ ] +1 let's relese it
>  [ ] -1 cancel it because ${reason}
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Blog 
>  | Github  
> | LinkedIn  | Book 
> 

Re: [VOTE] Release Apache XBean 4.16

[Mark Struberg]

+1

LieGrue,
strub


> Am 31.01.2020 um 16:41 schrieb Romain Manni-Bucau :
> 
> Hi all,
> 
> Here is our asm upgrade release (to v 7.3.1).
> 
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1117
> Tag (rev 1873424): 
> http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.16/
> Dist (rev 37817): https://dist.apache.org/repos/dist/dev/geronimo/xbean/4.16/
> My key is the same than usual.
> 
> Please vote:
> 
>  [ ] +1 let's relese it
>  [ ] -1 cancel it because ${reason}
> 
> This vote is open for 3 days as usual or untll it gets its 3 binding +1s
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Re: [XBean] 4.16 coming?

[Mark Struberg]

no, go for it!

txs and LieGrue,
strub


> Am 29.01.2020 um 09:27 schrieb Romain Manni-Bucau :
> 
> Hi all,
> 
> Any blocker to release xbean 4.16 with asm 7.3.1 upgrade?
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Re: GERONIMO-6759 - Support for MicroProfile Config 1.4

[Mark Struberg]

lgtm, 
Thanks Daniel and also Romain!

LieGrue,
strub


> Am 26.01.2020 um 16:22 schrieb Romain Manni-Bucau :
> 
> FYI I just fixed master code - test was using the proxy fields instead of 
> injected values. Feel free to review and enhance if needed.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le dim. 26 janv. 2020 à 08:28, Romain Manni-Bucau  a 
> écrit :
> Merged, thks a lot Daniel
> 
> Le dim. 26 janv. 2020 à 01:25, Daniel Cunha  a écrit :
> I believe now it's in a good shape.
> 
> 
> Thank you, Romain. 
> 
> 
> --
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
> 
> On Sat, Jan 25, 2020, 17:55 Romain Manni-Bucau  wrote:
> You dont need to parse constants :
> 
> Long.parseLong("0") -> 0L ;)
> 
> 
> Otherwise looks perfect for me
> If nobody shouts, i will merge it tmr or on monday
> 
> Le sam. 25 janv. 2020 à 20:10, Daniel Cunha  a écrit :
> Changes sent! 
> 
> Thank you for your review Romain. 
> 
> Em sáb., 25 de jan. de 2020 às 15:05, Romain Manni-Bucau 
>  escreveu:
> Proxy supports primitives so default is not always null compared to 
> injections, no? Once this point materialized by a test - and maybe imports 
> reorganized to minimize the diff? - i guess we are good to merge.
> 
> Le sam. 25 janv. 2020 à 18:37, Daniel Cunha  a écrit :
> I updated the PR. Hope it is in a good shape now!
> 
> Thank you.
> 
> Em sáb., 25 de jan. de 2020 às 13:08, Romain Manni-Bucau 
>  escreveu:
> Except a small import issue (*) i guess it just needs the proxy handling (in 
> our invocation handler)of default value and some test(s) then it looks pretty 
> good to me.
> 
> Le sam. 25 janv. 2020 à 17:01, Daniel Cunha  a écrit :
> Hi Folks,
> 
> https://github.com/apache/geronimo-config/pull/6
> 
> That is the PR with changes to cover MicroProfile 1.4-RC on Geronimo Config.
> I really appreciate if someone could put the eyes on it. 
> 
> Thank you.
> 
> -- 
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
> 
> 
> -- 
> Daniel "soro" Cunha
> https://twitter.com/dvlc_
> 
> 
> -- 
> Daniel "soro" Cunha
> https://twitter.com/dvlc_

Re: [VOTE] [RESULT] release Apache geronimo-openapi 1.0.12

[Mark Struberg]

Good morning!

The VOTE did pass with the following

+1: Mark, Cesar, Raymond, Romain

txs to all who reviewed and voted!

Gonna continue with the release steps.

LieGrue,
strub


> Am 11.12.2019 um 20:18 schrieb Raymond Auge :
> 
> +1
> 
> - Ray
> 
> On Tue, Dec 10, 2019 at 11:52 PM Cesar Hernandez  wrote:
> +1. Thanks Mark.
> 
> El mar., 10 dic. 2019 a las 16:25, Mark Struberg () 
> escribió:
> hi folks!
> 
> I did run the steps for the openapi-1.0.12 release
> 
> The staging repo can be found here
> https://repository.apache.org/content/repositories/orgapachegeronimo-1115
> 
> The sources are here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1115/org/apache/geronimo/geronimo-openapi/1.0.12/
> sha1 90b2cfb57b9de11a9fba9af84dcdfb70eb295af0
> 
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub
> 
> 
> 
> -- 
> Atentamente:
> César Hernández.
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)

Re: [VOTE] release Apache geronimo-openapi 1.0.12

[Mark Struberg]

Of course my own +1

LieGrue,
strub


> Am 11.12.2019 um 20:18 schrieb Raymond Auge :
> 
> +1
> 
> - Ray
> 
> On Tue, Dec 10, 2019 at 11:52 PM Cesar Hernandez  wrote:
> +1. Thanks Mark.
> 
> El mar., 10 dic. 2019 a las 16:25, Mark Struberg () 
> escribió:
> hi folks!
> 
> I did run the steps for the openapi-1.0.12 release
> 
> The staging repo can be found here
> https://repository.apache.org/content/repositories/orgapachegeronimo-1115
> 
> The sources are here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1115/org/apache/geronimo/geronimo-openapi/1.0.12/
> sha1 90b2cfb57b9de11a9fba9af84dcdfb70eb295af0
> 
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> txs and LieGrue,
> strub
> 
> 
> 
> -- 
> Atentamente:
> César Hernández.
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)

Re: [VOTE] Release geronimo-jwt-auth-1.0.4

[Mark Struberg]

Don't worry, I'll keep an eye on it.
And thanks for getting it rolling!

txs and LieGrue,
strub


> Am 11.12.2019 um 20:30 schrieb Raymond Auge :
> 
> Hey all, So I will cancel this vote and start a new one since I messed up the 
> email.
> 
> Also, this should act like a heads up that I want to do a release.
> 
> I can give it a couple of days.
> 
> - Ray
> 
> On Wed, Dec 11, 2019 at 2:22 PM Raymond Auge  wrote:
> Hello All,
> 
> I'd like to call a vote for release of geronimo-jwt-auth-1.0.4
> 
> The staging repo can be found here
> https://repository.apache.org/content/repositories/orgapachegeronimo-1116
> 
> The sources are here:
> https://repository.apache.org/service/local/repositories/orgapachegeronimo-1116/content/org/apache/geronimo/geronimo-jwt-auth/1.0.4/geronimo-jwt-auth-1.0.4-source-release.zip
> https://repository.apache.org/service/local/repositories/orgapachegeronimo-1116/content/org/apache/geronimo/geronimo-jwt-auth/1.0.4/geronimo-jwt-auth-1.0.4-source-release.zip.sha1
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
> 
> The VOTE is open for 72h.
> release
> 
> The staging repo can be found here
> https://repository.apache.org/content/repositories/orgapachegeronimo-1115
> 
> The sources are here:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1115/org/apache/geronimo/geronimo-openapi/1.0.12/
> sha1 90b2cfb57b9de11a9fba9af84dcdfb70eb295af0
> 
> 
> Please VOTE
> 
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop there is a ${showstopper}
> 
> The VOTE is open for 72h.
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)

[VOTE] release Apache geronimo-openapi 1.0.12

[Mark Struberg]

hi folks!

I did run the steps for the openapi-1.0.12 release

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

The sources are here:
https://repository.apache.org/content/repositories/orgapachegeronimo-1115/org/apache/geronimo/geronimo-openapi/1.0.12/
sha1 90b2cfb57b9de11a9fba9af84dcdfb70eb295af0


Please VOTE

[+1] go ship it
[+0] meh, don't care
[-1] stop there is a ${showstopper}

The VOTE is open for 72h.

txs and LieGrue,
strub

[DISCUSS] kickstart a release of geronimo-openapi?

[Mark Struberg]

hi folks!

we got some patches for openapi. 
Would run a release in the afternoon.
Any objections?

txs and LieGrue,
strub

Re: [VOTE] Release Apache Geronimo Arthur 1.0.0

[Mark Struberg]

+1

txs and LieGrue,
strub


> Am 05.12.2019 um 09:48 schrieb Romain Manni-Bucau :
> 
> Hi all,
> 
> I'd like to call a vote for our Geronimo Arthur project.
> As a reminder it is a light preprocessor for GraalVM which enables to build 
> native binaries from java applications (and docker images).
> 
> Here is the staging repository: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1114
> Sources are there: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1114/org/apache/geronimo/arthur/arthur/1.0.0/arthur-1.0.0-source-release.zip
> Here is the tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git;a=tag;h=c5c95af42dde037b383c2cacd488bd42bed1e7cb
> My key is the same than usual.
> 
> Please vote:
> 
> [ ] +1 release it
> [ ] -1 don't release it cause ${blocker}
> 
> Vote will be opened as usual for 3 days or as needed.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Re: Transfer/retirement of BatchEE

[Mark Struberg]

Indeed, +1 for transferring to / graduating under Apache Geronimo!

txs and LieGrue,
strub

 
> Am 19.11.2019 um 21:46 schrieb Romain Manni-Bucau :
> 
> Oki,
> 
> Seems name, IP, grant etc is moving from asf to asf we are good.
> Since batchee pmc agreed on a report thread I guess we just need a final 
> formal vite.
> 
> Anyone willing to drive that last part (propose a ppmc import or not - I can 
> handle geronimo interaction once agreed here) and vote thread ?
> 
> My 2cts/proposal would be to propose to G to import all committers (most of 
> them already being there directly or not) it sounds sane.
> 
> If not launched end of the month I'll try to handle it the first week of 
> december worse case.
> 
> Le mar. 19 nov. 2019 à 20:53, Justin Mclean  a écrit :
> Hi,
> 
> For the transfer you would need to check that a name search has been done, 
> grant completed, IP clearance done and a decision made to how the handle the 
> existing PPMC/committers of the project. A vote would need to be taken on the 
> BatchEE dev list to make sure the PPMC agrees to this move and record the 
> transfer.
> 
> Thanks,
> Justin

Re: [VOTE] Release Apache XBean 4.15

[Mark Struberg]

+1

LieGrue,
strub


> Am 24.10.2019 um 21:41 schrieb Raymond Auge :
> 
> +1
> 
> On Thu, Oct 24, 2019 at 11:01 AM Jean-Louis MONTEIRO  
> wrote:
> +1
> 
> Le jeu. 24 oct. 2019 à 10:13, Francois Papon  a 
> écrit :
> +1 (non-binding)
> 
> Thanks!
> 
> regards,
> 
> François
> 
> fpa...@apache.org
> Le 23/10/2019 à 09:24, Romain Manni-Bucau a écrit :
>> Hi everyone,
>> 
>> As mentionned on the list some weeks ago we upgraded our xbean asm shade to 
>> 7.2.
>> Here is the vote to let it be consumed and it is the only change to the 
>> sources.
>> 
>> Staging repository - with sources: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1113
>> Tag (rev 1868788): 
>> http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-4.15/
>> My key is the same than for last votes.
>> 
>> Please vote:
>> 
>>  [ ] +1 let's relese it
>>  [ ] -1 cancel it because ${reason}
>> 
>> This vote is open for 3 days as usual or untll it gets its 3 binding +1s
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> -- 
> Jean-Louis
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)

Re: [VOTE] geronimo-jsonb_1.0_spec

[Mark Struberg]

+1

LieGrue,
strub


> Am 09.09.2019 um 17:47 schrieb Jean-Louis MONTEIRO :
> 
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-jsonb_1.0_spec
> 
> There is only one ticket for this release
> ** GERONIMO-6745 ensure accumulate logic works in jsonbconfig
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-
> 
> And the source jar which is voted on
> https://repository.apache.org/content/repositories/orgapachegeronimo-/org/apache/geronimo/specs/geronimo-jsonb_1.0_spec/1.2/geronimo-jsonb_1.0_spec-1.2-source-release.zip
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> -- 
> Jean-Louis

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

Yes, that's a sane approach.
EPL just requires us to have it mentioned in every downstream NOTICE iiuc.

From the EPL v2 [1]

3.1 If a Contributor Distributes the Program in any form, then:
• a) the Program must also be made available as Source Code, in 
accordance with section 3.2, and the Contributor must accompany the Program 
with a statement that the Source Code for the Program is available under this 
Agreement, and informs Recipients how to obtain it in a reasonable manner on or 
through a medium customarily used for software exchange; and...


For TomEE we'd need to add it to our NOTICE for example, right [2]?

This is likely not a problem for TomEE, but might be something to know if some 
project has a fat-jar approach. In this case this weak-copyleft semantic also 
spreads over to the customer project. Not a show-stopper, but something to 
consider.

LieGrue,
strub

[1] https://www.eclipse.org/legal/epl-2.0/
[2] https://github.com/apache/tomee/blob/master/NOTICE


> Am 04.09.2019 um 23:51 schrieb David Blevins :
> 
>> On Sep 4, 2019, at 2:10 AM, Romain Manni-Bucau  wrote:
>> 
>> No I guess it was right, "that are" ;) = fork @G only when we need to
>> change some impl/default provider.
> 
> Right.  A few things in my mind at least:
> 
> - Industry health: we (Apache) are the only other implementations of 
> Activation, JavaMail, JACC and similar "impl" specs.  If we give up on the 
> impls we have, the industry collapses down to one impl and then what is the 
> point of a spec?
> 
> - Competitiveness: we have seen performance issues reported against our 
> impls.  I distinctly remember one for JACC several years ago.  Where there 
> are issues, there are also potential advantages.  If we can handle it, let's 
> keep our impls and be competitive.
> 
> Where there is no actual impl I don't see any gain for the effort even if 
> small.
> 
> - Unavoidable EPL dependence: We're not likely to write a new Java compiler 
> any time soon, so we're stuck with the EPL forever.
> 
> - Likelyhood of increased EPL dependence: Given it is the default choice in 
> Jakarta, more things will be created under it we may need.
> 
> - Decreasing helping hands: Projects at Apache are switching over to the EPL 
> libraries, so we will have fewer people willing to type in APIs for 
> already-thin legal reasons.
> 
> 
> -David
> 

Re: [VOTE] Release geronimo-security_1.0_spec API

[Mark Struberg]

+1

LieGrue,
strub


> Am 03.09.2019 um 19:49 schrieb Cesar Hernandez :
> 
> +1
> 
> El mar., 3 sept. 2019 a las 11:43, Romain Manni-Bucau 
> () escribió:
> +1
> 
> Le mar. 3 sept. 2019 à 19:29, Raymond Auge  a écrit 
> :
> +1
> 
> - Ray
> 
> On Tue, Sep 3, 2019 at 11:25 AM Jean-Louis MONTEIRO  
> wrote:
> 
> Hi!
> 
> I’d like to call a VOTE on the geronimo-security_1.0_spec-1.0.jar.
> This is an API which implements the Security API JSR-375 1.0 specification.
> 
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1110
> 
> And the source jar which is voted on
> https://repository.apache.org/service/local/repositories/orgapachegeronimo-1110/content/org/apache/geronimo/specs/geronimo-security_1.0_spec/1.0/geronimo-security_1.0_spec-1.0-source-release.zip
> 
> 
> My key can be found at
> https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> please VOTE
> [+1] all fine, ship it
> [+0] don't care
> [-1] stop, because ${reason}
> 
> The VOTE is open for 72h.
> 
> 
> -- 
> Jean-Louis
> 
> 
> -- 
> Raymond Augé (@rotty3000)
> Senior Software Architect Liferay, Inc. (@Liferay)
> 
> 
> -- 
> Atentamente:
> César Hernández.

[metrics] switching SecurityValidator?

[Mark Struberg]

hi folks!

Right now the SecurityValidator in metrics cannot be switched easily, right?
Wouldn't it be better to simply inject it? Or at least have a protected method 
getSecurityValidator() ?

LieGrue,
strub

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

No, before that it was CDDL+GPL. It just moved to EPL, which is also CatB

LieGrue,
strub

> Am 04.09.2019 um 15:06 schrieb Romain Manni-Bucau :
> 
> @Mark: didn't change with jakarta donation? can you open a ticket on
> jakartee tracker please?
> 
> 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. 4 sept. 2019 à 15:04, Mark Struberg  a écrit :
> 
>> No, this is an intended situation.
>> When one fully passes the TCK then you get the EFSL. This 'removes' the
>> copyleft nature of the EPL.
>> The details are quite nested in the legal papers, but that's it basically.
>> 
>> If we just upgrade our existing API to be binary compat then we have no IP
>> issues.
>> 
>> LieGrue,
>> strub
>> 
>> 
>>> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau >> :
>>> 
>>> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity
>> for us.
>>> That said it is good to reuse the same GAV for end users so we might ask
>> jakarta to double license its api jars?
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>> 
>>> 
>>> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com> a écrit :
>>> Yep that was the point.
>>> So I was asking if we should do the same yes or not.
>>> 
>>> That seems to be your opinion Romain.
>>> Mark on the other end is having some doubts about the license.
>>> --
>>> Jean-Louis Monteiro
>>> http://twitter.com/jlouismonteiro
>>> http://www.tomitribe.com
>>> 
>>> 
>>> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau 
>> wrote:
>>> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro <
>> jlmonte...@tomitribe.com>
>>> a écrit :
>>> 
>>>> Thanks Romain. I'm fine with using Eclipse jars if from a legal point
>> of
>>>> view, it works.
>>>> Otherwise, I'd like to split our spec jars.
>>>> 
>>>> What about MicroProfile?
>>>> 
>>> 
>>> We already agreed to not redo the API and use microprofile jars.
>>> 
>>> 
>>>> It's the same license and we are using them in our MicroProfile
>>>> implementations.
>>>> --
>>>> Jean-Louis Monteiro
>>>> http://twitter.com/jlouismonteiro
>>>> http://www.tomitribe.com
>>>> 
>>>> 
>>>> On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg >> 
>>>> wrote:
>>>> 
>>>>> depends what their license is. EPL is (weak) copyleft. Thus I would
>> like
>>>>> to avoid exposing it downstream as api.
>>>>> 
>>>>> LieGrue,
>>>>> strub
>>>>> 
>>>>> 
>>>>>> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
>>>>> rmannibu...@gmail.com>:
>>>>>> 
>>>>>> If we still can't reuse jakata artifacts (their license is ok and
>> there
>>>>> is
>>>>>> no impl reference inside so we should just use them, right?) it
>> sounds
>>>>>> natural
>>>>>> 
>>>>>> 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. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
>>>>> jlmonte...@tomitribe.com>
>>>>>> a écrit :
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> I was digging into some other specifications and see what would
>> pass
>>>>>>> Jakarta TCK and realized that geronimo-security_1.0_spec content
>>>>> actually
>>>>>>> mixes 2 specifications.
>>>>>>> 
>>>>>>> https://github.com/eclipse-ee4j/security-api
>>>>>>> 
>>>>>>> and
>>>>>>> 
>>>>>>> https://github.com/eclipse-ee4j/jaspic
>>>>>>> 
>>>>>>> I thought the initial intent was to create a specific artifact per
>>>>>>> specification.
>>>>>>> Mixing them is a bit annoying from a certification perspective.
>>>>>>> It's also not clean because in Tomcat for instance, there is
>> already
>>>>>>> jaspic API so it becomes a duplicate.
>>>>>>> 
>>>>>>> Would it be possible to split them up in 2 artifacts?
>>>>>>> 
>>>>>>> --
>>>>>>> Jean-Louis Monteiro
>>>>>>> http://twitter.com/jlouismonteiro
>>>>>>> http://www.tomitribe.com
>>>>>>> 
>>>>> 
>>>>> 
>> 
>> 

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

No, this is an intended situation.
When one fully passes the TCK then you get the EFSL. This 'removes' the 
copyleft nature of the EPL.
The details are quite nested in the legal papers, but that's it basically.

If we just upgrade our existing API to be binary compat then we have no IP 
issues.

LieGrue,
strub


> Am 03.09.2019 um 16:37 schrieb Romain Manni-Bucau :
> 
> MP license is ok (Apache2) but Jakarta is EPLs so keeps the ambiguity for us.
> That said it is good to reuse the same GAV for end users so we might ask 
> jakarta to double license its api jars?
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 16:33, Jean-Louis Monteiro  
> a écrit :
> Yep that was the point.
> So I was asking if we should do the same yes or not. 
> 
> That seems to be your opinion Romain.
> Mark on the other end is having some doubts about the license.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
> 
> 
> On Tue, Sep 3, 2019 at 4:31 PM Romain Manni-Bucau  
> wrote:
> Le mar. 3 sept. 2019 à 16:29, Jean-Louis Monteiro 
> a écrit :
> 
> > Thanks Romain. I'm fine with using Eclipse jars if from a legal point of
> > view, it works.
> > Otherwise, I'd like to split our spec jars.
> >
> > What about MicroProfile?
> >
> 
> We already agreed to not redo the API and use microprofile jars.
> 
> 
> > It's the same license and we are using them in our MicroProfile
> > implementations.
> > --
> > Jean-Louis Monteiro
> > http://twitter.com/jlouismonteiro
> > http://www.tomitribe.com
> >
> >
> > On Tue, Sep 3, 2019 at 4:26 PM Mark Struberg 
> > wrote:
> >
> >> depends what their license is. EPL is (weak) copyleft. Thus I would like
> >> to avoid exposing it downstream as api.
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >> > Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau <
> >> rmannibu...@gmail.com>:
> >> >
> >> > If we still can't reuse jakata artifacts (their license is ok and there
> >> is
> >> > no impl reference inside so we should just use them, right?) it sounds
> >> > natural
> >> >
> >> > 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. 3 sept. 2019 à 16:18, Jean-Louis Monteiro <
> >> jlmonte...@tomitribe.com>
> >> > a écrit :
> >> >
> >> >> Hi all,
> >> >>
> >> >> I was digging into some other specifications and see what would pass
> >> >> Jakarta TCK and realized that geronimo-security_1.0_spec content
> >> actually
> >> >> mixes 2 specifications.
> >> >>
> >> >> https://github.com/eclipse-ee4j/security-api
> >> >>
> >> >> and
> >> >>
> >> >> https://github.com/eclipse-ee4j/jaspic
> >> >>
> >> >> I thought the initial intent was to create a specific artifact per
> >> >> specification.
> >> >> Mixing them is a bit annoying from a certification perspective.
> >> >> It's also not clean because in Tomcat for instance, there is already
> >> >> jaspic API so it becomes a duplicate.
> >> >>
> >> >> Would it be possible to split them up in 2 artifacts?
> >> >>
> >> >> --
> >> >> Jean-Louis Monteiro
> >> >> http://twitter.com/jlouismonteiro
> >> >> http://www.tomitribe.com
> >> >>
> >>
> >>

Re: DISCUSS geronimo-security_1.0_spec content unclear

[Mark Struberg]

depends what their license is. EPL is (weak) copyleft. Thus I would like to 
avoid exposing it downstream as api.

LieGrue,
strub


> Am 03.09.2019 um 16:20 schrieb Romain Manni-Bucau :
> 
> If we still can't reuse jakata artifacts (their license is ok and there is
> no impl reference inside so we should just use them, right?) it sounds
> natural
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
> 
> 
> Le mar. 3 sept. 2019 à 16:18, Jean-Louis Monteiro 
> a écrit :
> 
>> Hi all,
>> 
>> I was digging into some other specifications and see what would pass
>> Jakarta TCK and realized that geronimo-security_1.0_spec content actually
>> mixes 2 specifications.
>> 
>> https://github.com/eclipse-ee4j/security-api
>> 
>> and
>> 
>> https://github.com/eclipse-ee4j/jaspic
>> 
>> I thought the initial intent was to create a specific artifact per
>> specification.
>> Mixing them is a bit annoying from a certification perspective.
>> It's also not clean because in Tomcat for instance, there is already
>> jaspic API so it becomes a duplicate.
>> 
>> Would it be possible to split them up in 2 artifacts?
>> 
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>> 

Re: DISCUSS Release for Geronimo Annotations 1.3

[Mark Struberg]

+1

LieGrue,
strub


> Am 03.09.2019 um 09:45 schrieb Romain Manni-Bucau :
> 
> +1
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 09:44, Jean-Louis MONTEIRO  a 
> écrit :
> Everything is green now
> 
> 
> am I ok to run the release?
> 
> 
> Le mar. 3 sept. 2019 à 09:35, Romain Manni-Bucau  a 
> écrit :
> Oki so let's get it out :)
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 
> Le mar. 3 sept. 2019 à 09:18, Jean-Louis MONTEIRO  a 
> écrit :
> Hi Romain,
> 
> This is the changes I made.
> Nothing big or potentially breaking applications.
> 
> It's the signature part yes.
> Basically @Repeatable was missing on @Resource and @DataSourceDefinition
> 
> See https://svn.apache.org/viewvc?view=revision=1866293
> 
> 
> 
> 
> 
> Le lun. 2 sept. 2019 à 23:29, Romain Manni-Bucau  a 
> écrit :
> Hi JL,
> 
> I didnt find the commits in mail archives, is it a list setup issue? Does it 
> break binary compatibility/class or method signatures?
> 
> Otherwise it sounds good. Can test on a few projects relying on annotation 
> bundle tomorrow.
> 
> Le lun. 2 sept. 2019 à 23:06, Jean-Louis MONTEIRO  a 
> écrit :
> Hi guys,
> 
> I ran the TCK for Annotations 1.3.
> It's simple as it's only signature validation.
> 
> I found 2 issues that I fixed and now I'd like to do the actual release.
> Is that ok?
> 
> -- 
> Jean-Louis
> 
> 
> -- 
> Jean-Louis
> 
> 
> -- 
> Jean-Louis

Re: [VOTE] Release Geronimo OpenAPI 1.0.11

[Mark Struberg]

+1

LieGrue,
strub


Am Mittwoch, den 21.08.2019, 10:21 +0200 schrieb Romain Manni-Bucau:
> oops, editing the subject to ensure we vote for the 1.0.11 and not 1.0.10
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> Le mer. 21 août 2019 à 10:21, Romain Manni-Bucau  a
> écrit :
> > Hi all,
> > As mentionned, due to JSON-B mapping fixes I'd like to release OpenAPI
> > 1.0.11 so here is the vote. Here is the only issue we fixed:
> > 
> > 
> > GERONIMO-6746Better alignment on JSON-B for OpenAPI model
> > 
> > Tag is here: 
> > https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=commit;h=5a9dd6a0fa41976c3314bfb4a3d8e44af70b9492
> > Sources and staging is there: 
> > https://repository.apache.org/content/repositories/orgapachegeronimo-1108
> > And my key is still the same.
> > 
> > Please vote:
> > 
> > [ ] +1 let it go out
> > [ ] -1 ${because X}
> > 
> > Vote will stay open for 3 days or we get 3 +1 bindings vote as usual.
> > 
> > 
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 
> 

Re: Releasing openapi soon?

[Mark Struberg]

sure, go on!

LieGrue,
strub


Am Montag, den 19.08.2019, 09:44 +0200 schrieb Romain Manni-Bucau:
> Hi everyone,
> I recently fixed some JSON-B mapping in our Microprofile openapi impl.
> 
> If there is no objection, I'd like to release it soon but it can need some
> testing from your part if you already rely on it to ensure there is no
> breaking change with your impl or that you can grab an compatible
> implementation - we can assume we will release johnzon 1.2.0 soon here.
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> 

Re: mail tck?

[Mark Struberg]

+1

LieGrue,
strub

> Am 10.08.2019 um 10:25 schrieb Jean-Baptiste Onofré :
> 
> Hi Romain,
> 
> I didn't notice that but I think you are right about the location. I
> think it's worth to try to pass TCK.
> 
> Regards
> JB
> 
> On 10/08/2019 10:23, Romain Manni-Bucau wrote:
>> Hi everyone,
>> 
>> We spoke of releasing our javamail impl,
>> Anyone noticed tck are on github
>> now? https://github.com/eclipse-ee4j/javamail-tck
>> Did we try to pass them? Do we want to setup them in the build - worse
>> case in an optional module doing a git clone + mvn exec?
>> 
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: TomEE 8 / Jakarta EE 8 / JavaMail 1.5

[Mark Struberg]

thanks JL!

LieGrue,
strub


> Am 01.08.2019 um 14:42 schrieb Jean-Louis Monteiro :
> 
> Hey TomEE and Geronimo folks,
> 
> I built and deployed 1.5 SNAPSHOT of JavaMail API and provider.
> I also did the integration in TomEE with the snapshots.
> 
> I am currently running Jakarta EE TCK to see where we are at.
> I'll be pushing setup changes shortly.
> 
> This is related to https://issues.apache.org/jira/browse/TOMEE-2606
> 
> If that looks quite well, I will do a release of both this week if possible
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com

Re: Status of geronimo-javamail_1.5_spec

[Mark Struberg]

+1

LieGrue,
strub

> Am 30.07.2019 um 13:14 schrieb Romain Manni-Bucau :
> 
> Hi JL
> 
> Was thinking the same,some api used by new libs like greenmail utilities are 
> missing in our last bundle so we should definitively catch up.
> 
> +1 to skip beta/milestone stage, always had been considered as snapshot so 
> does not help the project much and most of the implis actually clearly not in 
> beta ;).
> 
> Le mar. 30 juil. 2019 à 12:09, Jean-Louis MONTEIRO  a 
> écrit :
> Hey guys,
> 
> I don't see any release for geronimo-javamail_1.5_spec
> What's the current status?
> Can we release it if it's at least in a beta state?
> 
> -- 
> Jean-Louis

Re: [VOTE] Release Apache Geronimo OpenAPI 1.0.9

[Mark Struberg]

+1

LieGrue,
strub


> Am 05.06.2019 um 10:21 schrieb Romain Manni-Bucau :
> 
> Hello everyone,
> 
> As mentionned here is the vote for Apache Geronimo OpenAPI 1.0.9.
> 
> The changelog is the following one:
> 
> P T   Key Summary AssigneeStatus  Development 
>   GERONIMO-6729   Upgrade API to 1.1  Romain Manni-Bucau  
> RESOLVED
>   GERONIMO-6730   clean up Schema - defaults shouldn't appear in 
> the generated schema Romain Manni-Bucau  RESOLVED
>   GERONIMO-6731   Tags can end up duplicated  Romain 
> Manni-Bucau  RESOLVED
>   GERONIMO-6732   Try to enforce operationId to be unique Romain 
> Manni-Bucau  RESOLVED
> 
> 
> Tag: 
> https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=commit;h=7ac857d21bf2e0425d12191ca1d2a1937ba01fda
> Staging (with sources): 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1104
> My key is still the same.
> 
> Please vote:
> 
> [ ] +1: let's release it
> [ ]  -1 ${cause}
> 
> Vote will be opened as usual for 3 days or until we get 3 +1 (binding).
> 
> Romain Manni-Bucau
> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

[jira] [Commented] (GERONIMO-6726) Create jakarta.* spec APIs

[Mark Struberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-6726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837650#comment-16837650
 ] 

Mark Struberg commented on GERONIMO-6726:
-

Hi [~downdrown]!
It is pretty much 100% fix that the javax.* namespace will not be touched and 
JakartaEE will have to move. 
I guess you've seen my blog post, right?
There will be tools to support downstream users. I guess that NetBeans, Eclipse 
and Idea will have this on board. I expect a timeframe of about 9 months before 
you'll see the first full servers and eco system being migrated. I think 
migrating a user project will be updating dependencies + an hour of work. Given 
all deps are available for jakarta.* then it should be pretty much straight 
forward.

> Create jakarta.* spec APIs
> --
>
> Key: GERONIMO-6726
> URL: https://issues.apache.org/jira/browse/GERONIMO-6726
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: specs
>    Reporter: Mark Struberg
>Priority: Major
>
> Oracle does not allow to evolve the former JavaEE specs under the javax.* 
> package name as they claim to own the full 'Java' trademark.
> While this may or may not be true it might be wise to not pursue a legal 
> battle.
> Thus we will move all the specs to use the jakarta.* package names.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] implement jakarta spec apis

[Mark Struberg]

Btw, found a good example for hierarchic structures: JsonValue. 

And one more question: how to deal with annotations if he javax package is 
essentially sealed?
How can you add a value to an annotation or change some meta annotation like eg 
the Target?

LieGrue,
Strub


> Am 05.05.2019 um 21:03 schrieb Romain Manni-Bucau :
> 
> I see, makes sense.
> 
> Personally i strongly think we dont need a strong toggle and that future 
> compat can rely on javax, this is what javaee was about after all.
> 
> But no issue testing things, we can even use sandbox/ for that.
> 
>> Le dim. 5 mai 2019 à 20:49, Mark Struberg  a écrit :
>> Of course there will be no releases until the EF has a common understanding 
>> how to proceed on their side. After all the main goal is compatibility 
>> amongst vendors.
>> 
>> I'd actually even would avoid to push snapshots to our repository.apache.org 
>> ...
>> 
>> This is mainly for understanding how far we come, what the limits are and 
>> what other options we have.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau :
>> > 
>> > Ok.
>> > 
>> > Can we agree to take this discussion back and hold any release - no issue 
>> > with snaps - until it is clarified?
>> > 
>> > Le dim. 5 mai 2019 à 18:45, Mark Struberg  a écrit :
>> > I'm not even sure whether they yet got all the necessary IP to release 
>> > anything.
>> > 
>> > LieGrue,
>> > strub
>> > 
>> > 
>> > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau 
>> > > :
>> > > 
>> > > 
>> > > 
>> > > Le dim. 5 mai 2019 à 18:30, Mark Struberg  a écrit :
>> > > I'm not mandating jakarta in the groupId, but it should something else 
>> > > than the current one.
>> > > Because otw we would have them completely mixed up in the same folder. 
>> > > That's not nice.
>> > > 
>> > > Depends, that said happy to just replace specs by jakarta if it works 
>> > > for you better (org.apache.geronimo.jakarta). I just dont want 
>> > > jakarta-specs or _spec-xxx as before, always looked fishy and almost 
>> > > wrong even if I get where it comes from.
>> > > 
>> > > Btw, what is our status on having eclipse releasing api under asf2 
>> > > license?
>> > > 
>> > > I dont want us to invest in something we drop like in 2 weeks and sounds 
>> > > it can be for most of specs. Any page tracking that?
>> > > 
>> > > 
>> > > LieGrue
>> > > strub
>> > > 
>> > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau 
>> > > > :
>> > > > 
>> > > > We dont need jakarta in the gav at all.
>> > > > 
>> > > > Why not org.apache.geronimo.spec:servlet:4.0.1?
>> > > > 
>> > > > As a reminder specs means jakarta already and there id jo ambiguity 
>> > > > between jakarta and javaee thanks the version. 
>> > > > 
>> > > > That said if we move to git it id even physically clearer.
>> > > > 
>> > > > Finally servlet is a bad example cause owned at tomcat for apache i 
>> > > > think. We should absolutely stop duplicating them, it pollutes user 
>> > > > land for no gain IMHO.
>> > > > 
>> > > > 
>> > > > 
>> > > > 
>> > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg  a écrit :
>> > > > Eclipse itself probably doesn't yet have all the IP themselves. This 
>> > > > first needs to be clarified. Since all those legal questions have been 
>> > > > dealt with behind closed doors we simply have no idea.
>> > > > 
>> > > > But we do have clean-room implemented APIs under ALv2 over here at 
>> > > > Geronimo.
>> > > > And we can move this ourselves without having to wait for anybody.
>> > > > 
>> > > > LieGrue,
>> > > > strub
>> > > > 
>> > > > 
>> > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels 
>> > > > > :
>> > > > > 
>> > > > > I wonder if you need that going forward for Jakarta Specs, they 
>> > > > > could just be distributed by Eclipse directly? Having said that, if 
>> > > > > this is not the case I 

Re: [DISCUSS] implement jakarta spec apis

[Mark Struberg]

Btw, the limit so far has been hit whenever some internal JDK class did return 
some javax class. It appears that the JDK ships many old EE parts. E.g. old 
common-annotations which still miss @Priority.
Or even worse an ancient javax.transaction package. And then some javax.sql 
classes from the JDK return some transaction stuff :(
Here subclassing would make perfect sense as you noted on Twitter. So we could 
leave the existing javax.* classes and if we need some change then we introduce 
a subclass in a corresponding  jakarta.*. This might work in many cases. But we 
need to check if it als works for hierarchies. You cannot add something in a 
root class in jakarta as the original,classes would not extend you. Need. A bit 
more time to think about that.

LieGrue,
Strub

> Am 05.05.2019 um 21:03 schrieb Romain Manni-Bucau :
> 
> I see, makes sense.
> 
> Personally i strongly think we dont need a strong toggle and that future 
> compat can rely on javax, this is what javaee was about after all.
> 
> But no issue testing things, we can even use sandbox/ for that.
> 
>> Le dim. 5 mai 2019 à 20:49, Mark Struberg  a écrit :
>> Of course there will be no releases until the EF has a common understanding 
>> how to proceed on their side. After all the main goal is compatibility 
>> amongst vendors.
>> 
>> I'd actually even would avoid to push snapshots to our repository.apache.org 
>> ...
>> 
>> This is mainly for understanding how far we come, what the limits are and 
>> what other options we have.
>> 
>> LieGrue,
>> strub
>> 
>> 
>> > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau :
>> > 
>> > Ok.
>> > 
>> > Can we agree to take this discussion back and hold any release - no issue 
>> > with snaps - until it is clarified?
>> > 
>> > Le dim. 5 mai 2019 à 18:45, Mark Struberg  a écrit :
>> > I'm not even sure whether they yet got all the necessary IP to release 
>> > anything.
>> > 
>> > LieGrue,
>> > strub
>> > 
>> > 
>> > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau 
>> > > :
>> > > 
>> > > 
>> > > 
>> > > Le dim. 5 mai 2019 à 18:30, Mark Struberg  a écrit :
>> > > I'm not mandating jakarta in the groupId, but it should something else 
>> > > than the current one.
>> > > Because otw we would have them completely mixed up in the same folder. 
>> > > That's not nice.
>> > > 
>> > > Depends, that said happy to just replace specs by jakarta if it works 
>> > > for you better (org.apache.geronimo.jakarta). I just dont want 
>> > > jakarta-specs or _spec-xxx as before, always looked fishy and almost 
>> > > wrong even if I get where it comes from.
>> > > 
>> > > Btw, what is our status on having eclipse releasing api under asf2 
>> > > license?
>> > > 
>> > > I dont want us to invest in something we drop like in 2 weeks and sounds 
>> > > it can be for most of specs. Any page tracking that?
>> > > 
>> > > 
>> > > LieGrue
>> > > strub
>> > > 
>> > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau 
>> > > > :
>> > > > 
>> > > > We dont need jakarta in the gav at all.
>> > > > 
>> > > > Why not org.apache.geronimo.spec:servlet:4.0.1?
>> > > > 
>> > > > As a reminder specs means jakarta already and there id jo ambiguity 
>> > > > between jakarta and javaee thanks the version. 
>> > > > 
>> > > > That said if we move to git it id even physically clearer.
>> > > > 
>> > > > Finally servlet is a bad example cause owned at tomcat for apache i 
>> > > > think. We should absolutely stop duplicating them, it pollutes user 
>> > > > land for no gain IMHO.
>> > > > 
>> > > > 
>> > > > 
>> > > > 
>> > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg  a écrit :
>> > > > Eclipse itself probably doesn't yet have all the IP themselves. This 
>> > > > first needs to be clarified. Since all those legal questions have been 
>> > > > dealt with behind closed doors we simply have no idea.
>> > > > 
>> > > > But we do have clean-room implemented APIs under ALv2 over here at 
>> > > > Geronimo.
>> > > > And we can move this ourselves without having to wait for anybody.
>>

Re: [DISCUSS] implement jakarta spec apis

[Mark Struberg]

Of course there will be no releases until the EF has a common understanding how 
to proceed on their side. After all the main goal is compatibility amongst 
vendors.

I'd actually even would avoid to push snapshots to our repository.apache.org ...

This is mainly for understanding how far we come, what the limits are and what 
other options we have.

LieGrue,
strub


> Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau :
> 
> Ok.
> 
> Can we agree to take this discussion back and hold any release - no issue 
> with snaps - until it is clarified?
> 
> Le dim. 5 mai 2019 à 18:45, Mark Struberg  a écrit :
> I'm not even sure whether they yet got all the necessary IP to release 
> anything.
> 
> LieGrue,
> strub
> 
> 
> > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau :
> > 
> > 
> > 
> > Le dim. 5 mai 2019 à 18:30, Mark Struberg  a écrit :
> > I'm not mandating jakarta in the groupId, but it should something else than 
> > the current one.
> > Because otw we would have them completely mixed up in the same folder. 
> > That's not nice.
> > 
> > Depends, that said happy to just replace specs by jakarta if it works for 
> > you better (org.apache.geronimo.jakarta). I just dont want jakarta-specs or 
> > _spec-xxx as before, always looked fishy and almost wrong even if I get 
> > where it comes from.
> > 
> > Btw, what is our status on having eclipse releasing api under asf2 license?
> > 
> > I dont want us to invest in something we drop like in 2 weeks and sounds it 
> > can be for most of specs. Any page tracking that?
> > 
> > 
> > LieGrue
> > strub
> > 
> > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau :
> > > 
> > > We dont need jakarta in the gav at all.
> > > 
> > > Why not org.apache.geronimo.spec:servlet:4.0.1?
> > > 
> > > As a reminder specs means jakarta already and there id jo ambiguity 
> > > between jakarta and javaee thanks the version. 
> > > 
> > > That said if we move to git it id even physically clearer.
> > > 
> > > Finally servlet is a bad example cause owned at tomcat for apache i 
> > > think. We should absolutely stop duplicating them, it pollutes user land 
> > > for no gain IMHO.
> > > 
> > > 
> > > 
> > > 
> > > Le dim. 5 mai 2019 à 16:28, Mark Struberg  a écrit :
> > > Eclipse itself probably doesn't yet have all the IP themselves. This 
> > > first needs to be clarified. Since all those legal questions have been 
> > > dealt with behind closed doors we simply have no idea.
> > > 
> > > But we do have clean-room implemented APIs under ALv2 over here at 
> > > Geronimo.
> > > And we can move this ourselves without having to wait for anybody.
> > > 
> > > LieGrue,
> > > strub
> > > 
> > > 
> > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels :
> > > > 
> > > > I wonder if you need that going forward for Jakarta Specs, they could 
> > > > just be distributed by Eclipse directly? Having said that, if this is 
> > > > not the case I would at least remove „geronimo-“ from the artifact Id?
> > > > 
> > > > 
> > > > --
> > > > http://bernd.eckenfels.net
> > > >  
> > > > Von: Mark Struberg 
> > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM
> > > > An: geronimo-dev
> > > > Betreff: Re: [DISCUSS] implement jakarta spec apis
> > > >  
> > > > For now I've used the following patterns: 
> > > > 
> > > > org.apache.geronimo.jakarta-specs 
> > > > because specs and jakarta-specs should be in a clearly separated 
> > > > folder. 
> > > > 
> > > > geronimo-jakarta-servlet_spec 
> > > > because 'jakarta' should be in the jar name 
> > > > 
> > > > 4.0_1-SNAPSHOT 
> > > > 4.0 is for servlet-4.0, 1 is the patch level. 
> > > > 
> > > > I'd NOT do a release or push to our snapshots repo until in about 2 
> > > > weeks when the modus operandi is clear within the Jakarta community. 
> > > > 
> > > > LieGrue, 
> > > > strub 
> > > > 
> > > > 
> > > > 
> > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau 
> > > > > : 
> > > > > 
> > > > > Do we also want to clean our gav? Artifact=spec, major.minor version 
> > > > > =spec version 
> > &