[VOTE] Apache Geronimo Mail 2.1 spec 1.0.0

[Jean-Louis MONTEIRO]

Hi everyone,

I fixed 2 bugs and realized we were still in milestone mode. So it's more
than overdue. Here is a vote for the final 1.0.0 of the Jakarta Mail spec
2.1

*SVN Tag*
https://svn.apache.org/viewvc/geronimo/specs/tags/geronimo-mail_2.1_spec-1.0.0/

*Staging repo*
https://repository.apache.org/content/repositories/orgapachegeronimo-1170

*Sources*
https://repository.apache.org/content/repositories/orgapachegeronimo-1170/org/apache/geronimo/specs/geronimo-mail_2.1_spec/1.0.0/geronimo-mail_2.1_spec-1.0.0-source-release.zip

*Dist*
https://dist.apache.org/repos/dist/dev/geronimo/specs/geronimo-mail_2.1_spec-1.0.0/

*The release notes are *
Bug

   - [GERONIMO-6869 ]
   - InternetAddress.toString(InternetAddress[] addresses) prints the same
   address
   - [GERONIMO-6870 ]
   - RFC822 violation with duplicated headers


The vote will be open for at least 72 hours or until the necessary number
of votes are reached.

Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove with the reason
-- 
Jean-Louis

[jira] [Assigned] (GERONIMO-6870) RFC822 violation with duplicated headers

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro reassigned GERONIMO-6870:
-

Assignee: Jean-Louis Monteiro

> RFC822 violation with duplicated headers
> 
>
> Key: GERONIMO-6870
> URL: https://issues.apache.org/jira/browse/GERONIMO-6870
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>    Reporter: Jean-Louis Monteiro
>Assignee: Jean-Louis Monteiro
>Priority: Major
>
> Some headers aren't supposed to be duplicated and are rejected from certaines 
> servers, like Google for example.
>  
> Aside from 'Received' and 'Returned-Path' others must not be duplicated.
> Cc and Bcc can sometimes be duplicated but they are often treated the same 
> way as To for consistency. This is what we'll do.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (GERONIMO-6870) RFC822 violation with duplicated headers

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6870.
---
Fix Version/s: Mail_2.1_1.1.0
   Resolution: Fixed

> RFC822 violation with duplicated headers
> 
>
> Key: GERONIMO-6870
> URL: https://issues.apache.org/jira/browse/GERONIMO-6870
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>    Reporter: Jean-Louis Monteiro
>Assignee: Jean-Louis Monteiro
>Priority: Major
> Fix For: Mail_2.1_1.1.0
>
>
> Some headers aren't supposed to be duplicated and are rejected from certaines 
> servers, like Google for example.
>  
> Aside from 'Received' and 'Returned-Path' others must not be duplicated.
> Cc and Bcc can sometimes be duplicated but they are often treated the same 
> way as To for consistency. This is what we'll do.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (GERONIMO-6869) InternetAddress.toString(InternetAddress[] addresses) prints the same address

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6869.
---
Fix Version/s: Mail_2.1_1.1.0
   Resolution: Fixed

> InternetAddress.toString(InternetAddress[] addresses) prints the same address
> -
>
> Key: GERONIMO-6869
> URL: https://issues.apache.org/jira/browse/GERONIMO-6869
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>    Reporter: Jean-Louis Monteiro
>Assignee: Jean-Louis Monteiro
>Priority: Major
> Fix For: Mail_2.1_1.1.0
>
>
> Helper method {color:#0033b3}public static {color}{color:#00}String 
> {color}{color:#00627a}toString{color}({color:#0033b3}final 
> {color}{color:#00}Address{color}[] {color:#00}addresses{color}, 
> {color:#0033b3}int {color}{color:#00}used{color})
> Does not loop accross all provided address but instead always prints the 
> second address in the array.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (GERONIMO-6869) InternetAddress.toString(InternetAddress[] addresses) prints the same address

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro reassigned GERONIMO-6869:
-

Assignee: Jean-Louis Monteiro

> InternetAddress.toString(InternetAddress[] addresses) prints the same address
> -
>
> Key: GERONIMO-6869
> URL: https://issues.apache.org/jira/browse/GERONIMO-6869
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>    Reporter: Jean-Louis Monteiro
>Assignee: Jean-Louis Monteiro
>Priority: Major
>
> Helper method {color:#0033b3}public static {color}{color:#00}String 
> {color}{color:#00627a}toString{color}({color:#0033b3}final 
> {color}{color:#00}Address{color}[] {color:#00}addresses{color}, 
> {color:#0033b3}int {color}{color:#00}used{color})
> Does not loop accross all provided address but instead always prints the 
> second address in the array.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Mail bugs

[Jean-Louis MONTEIRO]

Hi all,

I've just pushed a couple of changes
https://svn.apache.org/viewvc?view=revision=1918229

It fixes
https://issues.apache.org/jira/browse/GERONIMO-6869
https://issues.apache.org/jira/browse/GERONIMO-6870

Hopefully it does not break more.

-- 
Jean-Louis

[jira] [Created] (GERONIMO-6870) RFC822 violation with duplicated headers

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6870:
-

 Summary: RFC822 violation with duplicated headers
 Key: GERONIMO-6870
 URL: https://issues.apache.org/jira/browse/GERONIMO-6870
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
Reporter: Jean-Louis Monteiro


Some headers aren't supposed to be duplicated and are rejected from certaines 
servers, like Google for example.

 

Aside from 'Received' and 'Returned-Path' others must not be duplicated.

Cc and Bcc can sometimes be duplicated but they are often treated the same way 
as To for consistency. This is what we'll do.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (GERONIMO-6869) InternetAddress.toString(InternetAddress[] addresses) prints the same address

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro updated GERONIMO-6869:
--
Component/s: mail

> InternetAddress.toString(InternetAddress[] addresses) prints the same address
> -
>
> Key: GERONIMO-6869
> URL: https://issues.apache.org/jira/browse/GERONIMO-6869
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>    Reporter: Jean-Louis Monteiro
>Priority: Major
>
> Helper method {color:#0033b3}public static {color}{color:#00}String 
> {color}{color:#00627a}toString{color}({color:#0033b3}final 
> {color}{color:#00}Address{color}[] {color:#00}addresses{color}, 
> {color:#0033b3}int {color}{color:#00}used{color})
> Does not loop accross all provided address but instead always prints the 
> second address in the array.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (GERONIMO-6869) InternetAddress.toString(InternetAddress[] addresses) prints the same address

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6869:
-

 Summary: InternetAddress.toString(InternetAddress[] addresses) 
prints the same address
 Key: GERONIMO-6869
 URL: https://issues.apache.org/jira/browse/GERONIMO-6869
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Jean-Louis Monteiro


Helper method {color:#0033b3}public static {color}{color:#00}String 
{color}{color:#00627a}toString{color}({color:#0033b3}final 
{color}{color:#00}Address{color}[] {color:#00}addresses{color}, 
{color:#0033b3}int {color}{color:#00}used{color})

Does not loop accross all provided address but instead always prints the second 
address in the array.
 
 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache Geronimo BatchEE 2.0.0 - Binaries

[Jean-Louis MONTEIRO]

+1

Le ven. 3 mai 2024, 09:44, Jean-Baptiste Onofré  a écrit :

> +1 (binding)
>
> Regards
> JB
>
> On Wed, May 1, 2024 at 5:22 PM fpapon  wrote:
> >
> > Hi everyone,
> >
> > A problem occured with the stagging repository of the release (the repo
> > has been dropped), so had to redeploy them to a new stagging repo.
> >
> > I submit Apache Geronimo BatchEE 2.0.0 release binaries to your vote.
> >
> > Staging Maven repository:
> > https://repository.apache.org/content/repositories/orgapachebatchee-1015
> >
> > 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: [batch] 2.0.0 release?

[Jean-Louis MONTEIRO]

+1, thank you


Le dim. 21 avr. 2024 à 10:10, Richard Zowalla  a
écrit :

> Guess, you can go for it :-)
> I am done with my changes.
>
> Gruß
> Richard
>
>
> Am 21. April 2024 10:01:44 MESZ schrieb Francois Papon <
> francois.pa...@openobject.fr>:
>
>> +1
>>
>> I can try to run the release process if needed, just ask me :)
>>
>> regards,
>>
>> François
>>
>> On 19/04/2024 21:02, Richard Zowalla wrote:
>>
>>> Hi all,
>>>
>>> since the TCK challenge is resolved and we are passing the full Batch
>>> TCK and updated most of the dependencies of BatchEE, what do you think
>>> about doing a 2.0.0 release?
>>>
>>> Gruß
>>> Richard
>>>
>>

-- 
Jean-Louis

Re: [VOTE] Apache Geronimo BatchEE 1.0.4

[Jean-Louis MONTEIRO]

+1 binding
Thanks

Le dim. 24 mars 2024, 17:35, Jean-Baptiste Onofré  a
écrit :

> +1 (binding)
>
> Regards
> JB
>
> Le ven. 22 mars 2024 à 21:40, fpapon  a écrit :
>
>> Hi everyone,
>>
>> I submit Apache Geronimo BatchEE 1.0.4 release to your vote.
>>
>> Release Notes:
>>
>>  * [BATCHEE-169] - Apache Parent POM 31
>>  * [BATCHEE-170] - Jackson 2.17.0
>>  * [BATCHEE-171] - Johnzon 1.2.21
>>  * [BATCHEE-172] - TomEE 8.0.16
>>  * [BATCHEE-173] - XBean 4.24
>>  * [BATCHEE-174] - Deltaspike 1.9.6
>>  * [BATCHEE-175] - Use createAnnotatedType(Class,String) to avoid
>> NoSuchMethodErrors in CDI-4
>>
>> Staging Maven repository:
>> https://repository.apache.org/content/repositories/orgapachebatchee-1011
>>
>> Staging dist repository:
>> https://dist.apache.org/repos/dist/dev/geronimo/batchee/
>>
>> 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: [VOTE] Apache Geronimo Arthur 1.0.8 release

[Jean-Louis MONTEIRO]

+1 (binding)

Le mar. 30 janv. 2024 à 09:57, Jean-Baptiste Onofré  a
écrit :

> +1 (binding)
>
> Regards
> JB
>
> On Tue, Jan 23, 2024 at 9:36 AM fpapon  wrote:
> >
> > Hi everyone,
> >
> > I submit Apache Geronimo Arthur 1.0.8 release to your vote.
> >
> > Release Notes:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220=12353687
> >
> > Staging Maven repository:
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1167
> >
> > Staging dist repository:
> > https://dist.apache.org/repos/dist/dev/geronimo/arthur/
> >
> > 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
> >
>


-- 
Jean-Louis

Re: [VOTE] Apache Geronimo TXManager 4.0.0 release

[Jean-Louis MONTEIRO]

+1

Le ven. 20 oct. 2023, 14:39, Romain Manni-Bucau  a
écrit :

> +1
>
> Le ven. 20 oct. 2023 à 11:26, fpapon  a écrit :
>
>> Hi everyone,
>>
>> I submit Apache Geronimo TXManager 4..0.0 release to your vote.
>>
>> Release Notes:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220=12352739
>>
>> Staging Maven repository:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1163
>>
>> Staging dist repository:
>> https://dist.apache.org/repos/dist/dev/geronimo/txmanager/
>>
>> 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: Milestone / Alpha Release of geronimo-txmanager?

[Jean-Louis MONTEIRO]

+1 for final and then patch version if there is a bug

Le jeu. 19 oct. 2023, 21:08, Francois Papon 
a écrit :

> +1 for a final :)
> On 19/10/2023 19:44, Romain Manni-Bucau wrote:
>
> so let's do a final would be my 2 cts ;)
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le jeu. 19 oct. 2023 à 19:17, Richard Zowalla  a
> écrit :
>
>> Don't think anything more than the jakarta migration (which is done) is
>> planned at the moment, so I am fine either way ;-)
>>
>>
>> Am 19. Oktober 2023 19:00:35 MESZ schrieb Romain Manni-Bucau <
>> rmannibu...@gmail.com>:
>>
>>> Hi,
>>>
>>> How far are we from a final?
>>> I'm generally quite hesitant regarding alpha/beta/M if real work is not
>>> planned and AFAIK we don't plan anything there so we can try to jump to the
>>> final directly.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Old Blog
>>>  | Github
>>>  | LinkedIn
>>>  | Book
>>> 
>>>
>>>
>>> Le jeu. 19 oct. 2023 à 18:53, Richard Zowalla  a
>>> écrit :
>>>
 Hi all,

 can we do a a milestone release (4.0.0-M1 or similar) of
 https://github.com/apache/geronimo-txmanager ?

 I would like to build TomEE 10.x against a stable version of
 the txmanager, so we might be able to do a milestone/alpha release of a
 TomEE 10 since the normal build is looking good.

 Gruß
 Richard

Re: [VOTE] Apache XBean 4.23 release

[Jean-Louis MONTEIRO]

+1

Le lun. 16 oct. 2023, 16:03, Guillaume Nodet  a écrit :

> +1
>
> Le ven. 13 oct. 2023 à 16:04, fpapon  a écrit :
>
>> Hi everyone,
>>
>> I submit Apache XBean 4.24 release to your vote.
>>
>> This release mainly includes (other issue description is available on
>> the release note):
>>
>> - ASM 9.6 update
>>
>>
>> Release Notes:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12353264
>>
>> Staging Maven repository:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1162
>>
>> 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
>>
>>
>
> --
> 
> Guillaume Nodet
>
>

Re: [VOTE] Apache XBean 4.24 release

[Jean-Louis MONTEIRO]

+1

Le lun. 16 oct. 2023, 16:03, Guillaume Nodet  a écrit :

> +1
>
> Le ven. 13 oct. 2023 à 16:42, fpapon  a écrit :
>
>> Hi everyone,
>>
>> I submit Apache XBean 4.24 release to your vote.
>>
>> This release mainly includes (other issue description is available on
>> the release note):
>>
>> - ASM 9.6 update
>>
>>
>> Release Notes:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12353264
>>
>>
>> Staging Maven repository:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1162
>>
>> 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
>>
>> --
>> --
>> François
>>
>>
>
> --
> 
> Guillaume Nodet
>
>

Re: [XBEAN] Next release

[Jean-Louis MONTEIRO]

Fine with it. Thank you

Le mer. 11 oct. 2023, 12:05, Romain Manni-Bucau  a
écrit :

> +1
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mer. 11 oct. 2023 à 13:25, fpapon  a écrit :
>
>> Hi all,
>>
>> We upgrade the XBean project with the latest version of ASM (9.6) and I
>> would like to start the release process.
>>
>> Any objection?
>>
>> regards,
>>
>> --
>> --
>> François
>>
>>

Re: [VOTE] Release Apache Geronimo Arthur 1.0.7

[Jean-Louis MONTEIRO]

+1

Le lun. 21 août 2023 à 08:49, Romain Manni-Bucau  a
écrit :

> My own +1
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 21 août 2023 à 08:31, Francois Papon 
> a écrit :
>
>> +1 (binding)
>> On 18/08/2023 16:53, Romain Manni-Bucau wrote:
>>
>> Hi all,
>>
>> Here is the vote for Apache Geronimo Arthur 1.0.7.
>> Main change is the support of new URL for graalvm download.
>>
>> Repo:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1161/
>> Tag: https://github.com/apache/geronimo-arthur/tree/arthur-1.0.7
>> Sources: https://dist.apache.org/repos/dist/dev/geronimo/arthur/ (bundle
>> 1.0.7, rev 63502)
>>
>> Please vote +1 (I want it passes) or -1 (I'm against cause $xxx).
>>
>> Vote is opened for 3 days or until we get enough binding votes as usual.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>

-- 
Jean-Louis

Re: Coming arthur release

[Jean-Louis MONTEIRO]

Hi,

No problem Romain

Thanks for the visibility.

Le jeu. 17 août 2023 à 20:37, Romain Manni-Bucau  a
écrit :

> Hi all,
>
> With François we noticed that Arthur does not support very well last
> graalvm (ce and oracle) repositories.
> I'm planning to enhance the download and release soon after.
>
> > https://issues.apache.org/jira/browse/GERONIMO-6850
>
> If you want to test before I run the release (hopfully before the week-end
> else on monday) it would be awesome, I updated the doc in the project with
> the new version schemas.
>
> Best,
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>


-- 
Jean-Louis

[jira] [Commented] (GERONIMO-6849) Add geronimo-transaction-spring module (was: jencks)

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro commented on GERONIMO-6849:
---

I don't mind if you want to add that to Geronimo. I'd like to see at least a 
small PR we could discuss on.

Do you think you can start something?

> Add geronimo-transaction-spring module (was: jencks)
> 
>
> Key: GERONIMO-6849
> URL: https://issues.apache.org/jira/browse/GERONIMO-6849
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>Reporter: Matt Pavlovich
>Priority: Major
>
> Add geronimo-transaction-spring module
> Basically, a jakarta port of jencks to provide Geronimo Transaction and 
> Connector to Spring bean bridge.
> ref: https://github.com/codehaus/jencks/tree/master/jencks



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache XBean 4.23 release

[Jean-Louis MONTEIRO]

+1

Thanks François

Le mer. 17 mai 2023, 01:25, Guillaume Nodet  a écrit :

> +1
>
> Le mar. 16 mai 2023 à 18:00, fpapon  a écrit :
>
>> Hi everyone,
>>
>> I submit Apache XBean 4.23 release to your vote.
>>
>> This release mainly includes (other issue description is available on
>> the release note):
>> - ASM 9.5 update
>>
>>
>> Release Notes:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12352402
>>
>> Staging Maven repository:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1160
>>
>> 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
>>
>>
>
> --
> 
> Guillaume Nodet
>
>

Re: [XBean] next release

[Jean-Louis MONTEIRO]

Go for it. Thanks François

Le jeu. 11 mai 2023 à 12:47, Romain Manni-Bucau  a
écrit :

> +1
>
> Le jeu. 11 mai 2023 à 11:53, fpapon  a écrit :
>
>> Hi,
>>
>> We have a request from a user to release XBean after the upgrade of ASM
>> dependency.
>>
>> If there is no objection, I can start the process.
>>
>> regards,
>>
>> --
>> --
>> François
>>
>>

-- 
Jean-Louis

Re: Status BatchEE-2.0.0

[Jean-Louis MONTEIRO]

Yes. Let's use the major release to remove the components not ready. As
Romain says it's easy to add them back if needed

Le mar. 25 avr. 2023, 09:13, Romain Manni-Bucau  a
écrit :

> Agree, I also think we can drop all our extensions "components" since the
> reusability was never reached (it is always faster and simpler to implement
> your component) so let's keep only jbatch and UI/tools related modules
> maybe?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mar. 25 avr. 2023 à 08:52, Richard Zowalla  a
> écrit :
>
>> Hi,
>>
>> aside from the upgrade killing our active waiting strategy in the tests
>> for the DirectEndpoint, I am seeing
>>
>> Caused by: java.lang.ClassNotFoundException:
>> javax.activation.DataHandler
>> at
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClass
>> Loader.java:641)
>> at
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Cla
>> ssLoaders.java:188)
>> at
>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>> ... 82 more
>>
>> with the 2.25.x version of camel during the tests (if I workaround the
>> protected getConsumer() via a wrapper strategy, see [1]). However, the
>> tests will pass...
>>
>> This gives me the impression, that Camel 2.x isn't jakarta ready. From
>> looking into their Jira it seems, that Camel 4.x will be jakarta ready
>> (Java 17 as baseline) but for now upgrading would make it rather
>> useless (or we would need to relocate).
>>
>> Gruß
>> Richard
>>
>> [1]
>>
>> https://github.com/rzo1/geronimo-batchee/commit/6cc27362b7a0bb34a8bd3d39a1fe35c4a5f834b3
>>
>>
>>
>> Am Freitag, dem 21.04.2023 um 13:13 +0200 schrieb 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] Release Apache Geronimo BatchEE-1.0.3

[Jean-Louis MONTEIRO]

+1

Le mer. 19 avr. 2023 à 11:19, Francois Papon 
a écrit :

> +1 (binding)
>
> regards,
>
> François
> On 18/04/2023 12:26, Mark Struberg via dev wrote:
>
> 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
>
>

-- 
Jean-Louis

Re: [VOTE] Release Geronimo Arthur 1.0.6

[Jean-Louis MONTEIRO]

+1 (binding)

Le lun. 17 avr. 2023 à 20:55, fpapon  a écrit :

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

-- 
Jean-Louis

[jira] [Resolved] (GERONIMO-6847) Switch Language Level to 11 in TX Manager

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6847.
---
Fix Version/s: TxManager-4.0.0
   Resolution: Fixed

Thanks [~rzo1]

> Switch Language Level to 11 in TX Manager
> -
>
> Key: GERONIMO-6847
> URL: https://issues.apache.org/jira/browse/GERONIMO-6847
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>Reporter: Richard Zowalla
>Priority: Major
> Fix For: TxManager-4.0.0
>
>
> as the title says



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (GERONIMO-6844) Jakarta Version of Geronimo TX Manager

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6844.
---
Fix Version/s: TxManager-4.0.0
   Resolution: Fixed

Thanks [~rzo1]

> Jakarta Version of Geronimo TX Manager
> --
>
> Key: GERONIMO-6844
> URL: https://issues.apache.org/jira/browse/GERONIMO-6844
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>Reporter: Richard Zowalla
>Priority: Major
> Fix For: TxManager-4.0.0
>
>
> We should provide related standalone artifacts without the need to shade.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (GERONIMO-6846) Replace Dependency Towards SLF4J with JUL in TX Manager

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6846.
---
Fix Version/s: TxManager-4.0.0
   Resolution: Fixed

Thanks [~rzo1]

> Replace Dependency Towards SLF4J with JUL in TX Manager
> ---
>
> Key: GERONIMO-6846
> URL: https://issues.apache.org/jira/browse/GERONIMO-6846
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>Reporter: Richard Zowalla
>Priority: Major
> Fix For: TxManager-4.0.0
>
>
> as the title says



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (GERONIMO-6845) Provide Genesis Flava for Java 11

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6845.
---
Resolution: Won't Fix

We don't need that parent pom anymore. Let's start using the regular Apache 
parent pom.

> Provide Genesis Flava for Java 11
> -
>
> Key: GERONIMO-6845
> URL: https://issues.apache.org/jira/browse/GERONIMO-6845
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>Reporter: Richard Zowalla
>Priority: Major
> Attachments: GERONIMO-6845.patch
>
>
> as the title says.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Terminate Specs jars in Geronimo

[Jean-Louis MONTEIRO]

Do you see something I missed?
Do you have restrictions or edge cases maybe?

Le ven. 6 janv. 2023 à 13:13, Romain Manni-Bucau  a
écrit :

> Hi,
>
> While there is an OSGi home for the spec (can move to karaf/smix/...) I'm
> fine with 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 ven. 6 janv. 2023 à 13:04, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> a écrit :
>
>> Hi all,
>>
>> Historically due to legal restrictions mainly, we created a bunch of spec
>> jars for all APIs from almost the beginning of Java EE.
>>
>> Now that Jakarta is in Eclipse, I don't think there are restrictions to
>> prevent us from using theM.
>>
>> I can think of a few exceptions
>>
>> - activation and mail because API/IMPL are mixed
>> - same for Faces (we use spec and impl from MyFaces).
>>
>> I know we have some minor add-ons like a service locator for OSGi. Do we
>> still need all of this?
>> Who is maintaining that and the features XML file when they exist?
>>
>> From my window, except the few exceptions, we can terminate the spec jars
>> and only maintain what we have if needed but encourage Apache projects to
>> rely on Eclipse APIs instead.
>>
>> What do you think?
>> Did I miss something?
>>
>>
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>

-- 
Jean-Louis

Terminate Specs jars in Geronimo

[Jean-Louis Monteiro]

Hi all,

Historically due to legal restrictions mainly, we created a bunch of spec
jars for all APIs from almost the beginning of Java EE.

Now that Jakarta is in Eclipse, I don't think there are restrictions to
prevent us from using theM.

I can think of a few exceptions

- activation and mail because API/IMPL are mixed
- same for Faces (we use spec and impl from MyFaces).

I know we have some minor add-ons like a service locator for OSGi. Do we
still need all of this?
Who is maintaining that and the features XML file when they exist?

>From my window, except the few exceptions, we can terminate the spec jars
and only maintain what we have if needed but encourage Apache projects to
rely on Eclipse APIs instead.

What do you think?
Did I miss something?


--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: [batchee] future?

[Jean-Louis MONTEIRO]

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

MicroProfile, Jakarta, all the same. Most of the vendors now use the same
implementation. At Apache we still have some alternatives for JPA, CDI and
a couple more and I think it's good overall for the ecosystem. But for how
long will it continue?

Le mer. 23 nov. 2022 à 11:20, Mark Struberg via dev 
a écrit :

> 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  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 <
>> 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 :
>>>
>>> I've opened a thread on the TomEE side to maybe transition BatchEE to
>>> TomEE.
>>>
>>> *Overall I don't understand the recent discussions to kill all Geronimo
>>> projects and subprojects.*
>>>
>>> Le mar. 22 nov. 2022 à 23:33, Romain Manni-Bucau 
>>> a écrit :
>>>
>>>> No requirement, just making it living (updating versions and spec impl).
>>>>
>>>> Le mar. 22 nov. 2022 à 23:31, Mark Struberg via dev <
>>>> 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 <
>>>>> 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
>>
>
>

-- 
Jean-Louis

Re: [batchee] future?

[Jean-Louis MONTEIRO]

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 
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 :
>
> I've opened a thread on the TomEE side to maybe transition BatchEE to
> TomEE.
>
> *Overall I don't understand the recent discussions to kill all Geronimo
> projects and subprojects.*
>
> Le mar. 22 nov. 2022 à 23:33, Romain Manni-Bucau 
> a écrit :
>
>> No requirement, just making it living (updating versions and spec impl).
>>
>> Le mar. 22 nov. 2022 à 23:31, Mark Struberg via dev <
>> 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 <
>>> 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: [batchee] future?

[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  a
écrit :

> No requirement, just making it living (updating versions and spec impl).
>
> Le mar. 22 nov. 2022 à 23:31, Mark Struberg via dev <
> 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 <
>> 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  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>
>>

-- 
Jean-Louis

Re: [VOTE] Apache XBean 4.22 release

[Jean-Louis MONTEIRO]

+1

Le lun. 10 oct. 2022 à 14:04, Romain Manni-Bucau  a
écrit :

> +1, thanks François!
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 10 oct. 2022 à 11:23, fpapon  a écrit :
>
>> Hi everyone,
>>
>> I submit Apache XBean 4.22 release to your vote.
>>
>> This release includes:
>> - ASM 9.4 update
>>
>> Release Notes:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12352368
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12352368
>> >
>>
>> Staging Maven repository:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1157
>>
>> 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
>>
>>

-- 
Jean-Louis

Re: Proposal: Retiring the Geronimo Project

[Jean-Louis MONTEIRO]

Let's push that conversation for October. There is activity for now and no
real issue to rush it.

A lot of people are going in and out for summer time.

Le dim. 17 juil. 2022, 08:18, Francois Papon 
a écrit :

> +1 for retiring the main project and finding hosts for sub projects.
>
> regards,
>
> François
>
> On 11/07/2022 18:52, Raymond Augé wrote:
> > The "Geronimo" project is getting long in the tooth and has very few
> > maintainers. It's been teetering on the edge of what could be
> > considered active ever since I've been involved (I believe more than 5
> > years now.)
> >
> > The project has seen many parts of its portfolio go unmaintained or
> > deprecated. We've seen other projects adopt parts (with this project's
> > blessing [1]). I would also argue this project seems to have lost its
> > identity and is now some sort of mishmash of libraries and utilities
> > with barely related aspects which I don't believe is really the model
> > for a good Open Source Apache project to bank a future on.
> >
> > And now, we really should make an effort to settle the issue of
> > "Native"-themed mascotry which was raised again most recently here [2].
> >
> > PROPOSAL:
> > I would like to propose we attempt to find any other ASF projects that
> > would be willing to take over interesting parts of the portfolio.
> > After that is exhausted, if nothing significant of interest remains
> > the project could simply be retired. However, if something significant
> > does remain and someone speaks up about wanting to maintain it, they
> > could initiate a new ASF project to house the remaining parts and have
> > the new project adopt those interesting bits.
> >
> > Thoughts?
> >
> > Ray
> >
> > [1] https://lists.apache.org/thread/sdny91l920o2lnl58sj5wy577k39fhsz
> > [2] https://lists.apache.org/thread/bd8s3knj2541275rbdnx2718h0y8qhrj
> >
>

[VOTE RESULT] Apache Geronimo Mail (provider) 2.1 - 1.0.0

[Jean-Louis MONTEIRO]

Hi!

Vote passed with 3 bindings +1 and no other vote.

Thanks

Le mar. 21 juin 2022 à 09:26, Jean-Louis MONTEIRO  a
écrit :

> My own +1
>
> Le lun. 20 juin 2022 à 17:14, Jean-Louis Monteiro <
> jlmonte...@tomitribe.com> a écrit :
>
>> Hi,
>>
>> I'd like to call a vote for Apache Geronimo Mail 2.1 version 1.0.0. This
>> is the first implementation of the Jakarta based Mail 2.1 specification. It
>> does not fully pass the standalone TCK but the mail part of the platform
>> TCK already passes.
>>
>> *Sources*
>>
>> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-mail_2.1_mail-1.0.0/
>>
>> *Github Tag*
>> https://github.com/apache/geronimo-javamail/tree/geronimo-mail_2.1-1.0.0
>>
>> *Staging repo*
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1156
>>
>> *Release notes*
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220=12351860
>>
>> New Feature
>>
>>- [GERONIMO-6837 <https://issues.apache.org/jira/browse/GERONIMO-6837>]
>>- Implement Geronimo Mail 2.1 for Jakarta Mail 2.1
>>
>> Improvement
>>
>>- [GERONIMO-6838 <https://issues.apache.org/jira/browse/GERONIMO-6838>]
>>- Support additional body after IMAP CONTINUATION response
>>- [GERONIMO-6839 <https://issues.apache.org/jira/browse/GERONIMO-6839>]
>>- Upgrade to Activation Spec 2.0 - 1.0.0-M1
>>
>>
>> [ ] +1 approve this release
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>>
>> Here is my +1 Binding vote.
>> --
>> Jean-Louis Monteiro
>> http://twitter.com/jlouismonteiro
>> http://www.tomitribe.com
>>
>
>
> --
> Jean-Louis
>


-- 
Jean-Louis

[VOTE RESULT] Geronimo activation_2.0_spec 1.0.0

[Jean-Louis MONTEIRO]

Hi!

Vote passed with 4 +1 and no other votes. I'll proceed.
Thanks so much everyone.

JLouis

Le mar. 24 mai 2022 à 11:45, Jean-Louis Monteiro 
a écrit :

> Here we go
>
> We now pass all TCK and signature tests. Thanks Richard.
>
> This is essentially the same as the M1 David did last week but with the
> fixes for compliance (See GERONIMO-6832)
>
> Here is the link for sources
> https://dist.apache.org/repos/dist/dev/geronimo/activation_2.0_spec/
>
> Here is the svn tag
>
> https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-activation_2.0_spec-1.0.0/
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1155
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ]  0 Abstain (please provide specific comments)
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks
>
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>


-- 
Jean-Louis

[VOTE] Apache Geronimo Mail (provider) 2.1 - 1.0.0

[Jean-Louis MONTEIRO]

My own +1

Le lun. 20 juin 2022 à 17:14, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> I'd like to call a vote for Apache Geronimo Mail 2.1 version 1.0.0. This
> is the first implementation of the Jakarta based Mail 2.1 specification. It
> does not fully pass the standalone TCK but the mail part of the platform
> TCK already passes.
>
> *Sources*
>
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-mail_2.1_mail-1.0.0/
>
> *Github Tag*
> https://github.com/apache/geronimo-javamail/tree/geronimo-mail_2.1-1.0.0
>
> *Staging repo*
> https://repository.apache.org/content/repositories/orgapachegeronimo-1156
>
> *Release notes*
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220=12351860
>
> New Feature
>
>- [GERONIMO-6837 <https://issues.apache.org/jira/browse/GERONIMO-6837>]
>- Implement Geronimo Mail 2.1 for Jakarta Mail 2.1
>
> Improvement
>
>- [GERONIMO-6838 <https://issues.apache.org/jira/browse/GERONIMO-6838>]
>- Support additional body after IMAP CONTINUATION response
>- [GERONIMO-6839 <https://issues.apache.org/jira/browse/GERONIMO-6839>]
>- Upgrade to Activation Spec 2.0 - 1.0.0-M1
>
>
> [ ] +1 approve this release
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
> Here is my +1 Binding vote.
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>


-- 
Jean-Louis

Apache Geronimo Mail (provider) 2.1 - 1.0.0

[Jean-Louis Monteiro]

Hi,

I'd like to call a vote for Apache Geronimo Mail 2.1 version 1.0.0. This is
the first implementation of the Jakarta based Mail 2.1 specification. It
does not fully pass the standalone TCK but the mail part of the platform
TCK already passes.

*Sources*
https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-mail_2.1_mail-1.0.0/

*Github Tag*
https://github.com/apache/geronimo-javamail/tree/geronimo-mail_2.1-1.0.0

*Staging repo*
https://repository.apache.org/content/repositories/orgapachegeronimo-1156

*Release notes*
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220=12351860

New Feature

   - [GERONIMO-6837 <https://issues.apache.org/jira/browse/GERONIMO-6837>]
   - Implement Geronimo Mail 2.1 for Jakarta Mail 2.1

Improvement

   - [GERONIMO-6838 <https://issues.apache.org/jira/browse/GERONIMO-6838>]
   - Support additional body after IMAP CONTINUATION response
   - [GERONIMO-6839 <https://issues.apache.org/jira/browse/GERONIMO-6839>]
   - Upgrade to Activation Spec 2.0 - 1.0.0-M1


[ ] +1 approve this release
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)


Here is my +1 Binding vote.
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

[jira] [Resolved] (GERONIMO-6839) Upgrade to Activation Spec 2.0 - 1.0.0-M1

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6839.
---
Resolution: Fixed

> Upgrade to Activation Spec 2.0 - 1.0.0-M1
> -
>
> Key: GERONIMO-6839
> URL: https://issues.apache.org/jira/browse/GERONIMO-6839
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Jean-Louis Monteiro
>Priority: Major
> Fix For: Mail_2.1_1.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (GERONIMO-6838) Support additional body after IMAP CONTINUATION response

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6838.
---
Resolution: Fixed

> Support additional body after IMAP CONTINUATION response
> 
>
> Key: GERONIMO-6838
> URL: https://issues.apache.org/jira/browse/GERONIMO-6838
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>    Reporter: Jean-Louis Monteiro
>Priority: Major
> Fix For: Mail_2.1_1.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GERONIMO-6839) Upgrade to Activation Spec 2.0 - 1.0.0-M1

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6839:
-

 Summary: Upgrade to Activation Spec 2.0 - 1.0.0-M1
 Key: GERONIMO-6839
 URL: https://issues.apache.org/jira/browse/GERONIMO-6839
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Jean-Louis Monteiro
 Fix For: Mail_2.1_1.0.0






--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GERONIMO-6838) Support additional body after IMAP CONTINUATION response

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6838:
-

 Summary: Support additional body after IMAP CONTINUATION response
 Key: GERONIMO-6838
 URL: https://issues.apache.org/jira/browse/GERONIMO-6838
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
Reporter: Jean-Louis Monteiro
 Fix For: Mail_2.1_1.0.0






--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GERONIMO-6837) Implement Geronimo Mail 2.1 for Jakarta Mail 2.1

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6837:
-

 Summary: Implement Geronimo Mail 2.1 for Jakarta Mail 2.1
 Key: GERONIMO-6837
 URL: https://issues.apache.org/jira/browse/GERONIMO-6837
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
Reporter: Jean-Louis Monteiro
 Fix For: Mail_2.1_1.0.0






--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (GERONIMO-6837) Implement Geronimo Mail 2.1 for Jakarta Mail 2.1

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6837.
---
Resolution: Fixed

> Implement Geronimo Mail 2.1 for Jakarta Mail 2.1
> 
>
> Key: GERONIMO-6837
> URL: https://issues.apache.org/jira/browse/GERONIMO-6837
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>    Reporter: Jean-Louis Monteiro
>Priority: Major
> Fix For: Mail_2.1_1.0.0
>
>




--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: Moving Mail, Activation, Transaction and Connector to Apache TomEE (was Re: [DISCUSS] Move microprofile impl to Apache TomEE)

[Jean-Louis MONTEIRO]

+1

Le dim. 19 juin 2022 à 16:02, Jean-Baptiste Onofré  a
écrit :

> Hi,
>
> Activation, transaction and connector are used also in Aries, ActiveMQ,
> Karaf.
>
> So, no problem for me as soon as we keep the "generic" aspect (not
> TomEE too centric).
>
> Regards
> JB
>
> On Tue, Jun 14, 2022 at 6:29 PM David Blevins 
> wrote:
> >
> > Jumping off of this thread, is there any openness to discussing moving
> this code over to TomEE?
> >
> >  - http://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk/
> >  -
> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-activation_2.0_spec/
> >  -
> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jakartamail_2.1_spec/
> >  -
> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-mail_2.1_spec/
> >
> > These are on the critical path for TomEE, being updated in Jakarta EE
> 10.  We're not working on Jakarta EE 10 yet, but we'll hopefully be doing
> that by early next year.
> >
> > It's a bit painful to send people over from the TomEE project to here
> and submit patches against SVN repos.  It would be great if we could have
> them in git and under the TomEE PMC if possible.
> >
> > Thoughts?
> >
> >
> > -David
> >
> > > On Jun 6, 2022, at 1:59 AM, fpapon  wrote:
> > >
> > > Hi all,
> > >
> > > I would like to start a thread to discuss about the future of the
> Apache Geronimo Microprofile implementation:
> > >
> > > https://geronimo.apache.org/microprofile/
> > >
> > > As we can see, we don't have a lot of traction about the maintenance
> of the implementation to be up-to-date with the Microprofile specification.
> > >
> > > The J2EE Geronimo server is no longer exist and at Apache, the active
> EE server seems to be Apache TomEE.
> > >
> > > May be it could make more sense to move the Microprofile
> implementation to the Apache TomEE umbrella.
> > >
> > > WDYT?
> > >
> > > regards,
> > >
> > > --
> > > --
> > > François
> > >
> >
>


-- 
Jean-Louis

Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Jean-Louis MONTEIRO]

Is there any interest to vote on this one?

Le lun. 30 mai 2022 à 16:10, Jean-Louis MONTEIRO  a
écrit :

> up ...
>
> Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau  a
> écrit :
>
>> +1 after the discussion in the other thread and points Richard raised
>>
>> 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. 25 mai 2022 à 02:13, Jean-Louis MONTEIRO  a
>> écrit :
>>
>>> here is my own +1 (binding)
>>>
>>> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO  a
>>> écrit :
>>>
>>>> I always find it better when we can keep backward compatibility for
>>>> users.
>>>> But this is a major version and I'm not a big fan of cheap system
>>>> properties.
>>>>
>>>> If we think it's not good, we should create a challenge to get it fixed
>>>> in the spec + TCK.
>>>> Otherwise, I would keep it the way it is. If it breaks users and we
>>>> want to help them out, it's still time to add the system property or a
>>>> better configuration option and do a maintenance release.
>>>>
>>>> I'd go lazy instead of eager considering it's a major version.
>>>> Meanwhile, I'd create an issue on the TCK + Spec
>>>>
>>>>
>>>> Le mar. 24 mai 2022 à 13:21, Zowalla, Richard <
>>>> richard.zowa...@hs-heilbronn.de> a écrit :
>>>>
>>>>> Romain mentioned the idea (via Slack) of introducing a (cheap) system
>>>>> property, which a user can specifiy to get back the old behaviour.
>>>>>
>>>>> If we want to follow the compatibility appraoch, we should add that
>>>>> flag as the spec / RI is really unclear.
>>>>>
>>>>>
>>>>> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
>>>>> > I conclude the same thing thanks your pointers so back to the
>>>>> > question: do we want to maintain the compat for our user base, do we
>>>>> > want to align on the random spec behavior or do we don't care?
>>>>> > Indeed I'm always in first team, in particular there since it will be
>>>>> > deprecated so the least we touch the best it is but guess it is a 50-
>>>>> > 50 case in terms of actual points :s.
>>>>> >
>>>>> > Romain Manni-Bucau
>>>>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>>>> >
>>>>> >
>>>>> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
>>>>> > richard.zowa...@hs-heilbronn.de> a écrit :
>>>>> > > The test in question is
>>>>> > >
>>>>> https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
>>>>> > >
>>>>> > > which expects the plain parameter value instead of
>>>>> > > "parameter=value" as
>>>>> > > a return value.
>>>>> > >
>>>>> > > The JavaDoc is also not quite clear about it:
>>>>> > >
>>>>> > >
>>>>> https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
>>>>> > >
>>>>> > > with "This method is called for each parameter name/value pair and
>>>>> > > should return the normalized representation of the
>>>>> > > parameterValue.".
>>>>> > >
>>>>> > > The spec document itself
>>>>> > >
>>>>> https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
>>>>> > >  doesn't mention anything about it.
>>>>> > >
>>>>> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
>>>>> > > there)
>>>>> > > to keep compatibility after removing the references to it.
>>>>>

[VOTE RESULT] Apache BatchEE 1.0.2

[Jean-Louis MONTEIRO]

Hi!

Vote passed with 5 +1 and no other vote.

Thanks everyone. I'll proceed with the remaining steps.

JLouis

Le ven. 17 juin 2022 à 10:41, Jean-Louis Monteiro 
a écrit :

> Hi,
>
> As discussed, here is the vote for Apache BatchEE 1.0.2.
>
> This is a maintenance release with minor fixes and a fix for jakarta
> reloction.
>
> Maven staging repo
> https://repository.apache.org/content/repositories/orgapachebatchee-1009
>
> Binaries and sources
> https://dist.apache.org/repos/dist/dev/geronimo/batchee/1.0.2
>
> Github Tag
> https://github.com/apache/geronimo-batchee/tree/batchee-1.0.2
>
> Release Notes
> https://issues.apache.org/jira/projects/BATCHEE/versions/12350726
>
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>


-- 
Jean-Louis

Re: [VOTE] Apache BatchEE 1.0.2

[Jean-Louis MONTEIRO]

My own +1

Le ven. 17 juin 2022 à 15:21, fpapon  a écrit :

> +1 (binding)
>
> Regards,
>
>
> On 17/06/2022 10:40, Jean-Louis Monteiro wrote:
>
> Hi,
>
> As discussed, here is the vote for Apache BatchEE 1.0.2.
>
> This is a maintenance release with minor fixes and a fix for jakarta
> reloction.
>
> Maven staging repo
> https://repository.apache.org/content/repositories/orgapachebatchee-1009
>
> Binaries and sources
> https://dist.apache.org/repos/dist/dev/geronimo/batchee/1.0.2
>
> Github Tag
> https://github.com/apache/geronimo-batchee/tree/batchee-1.0.2
>
> Release Notes
> https://issues.apache.org/jira/projects/BATCHEE/versions/12350726
>
>
> Please VOTE
>
> [+1] go ship it
> [+0] meh, don't care
> [-1] stop, there is a ${showstopper}
>
> The VOTE is open for 72h
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
> --
> --
> François
>
>

[VOTE] Apache BatchEE 1.0.2

[Jean-Louis Monteiro]

Hi,

As discussed, here is the vote for Apache BatchEE 1.0.2.

This is a maintenance release with minor fixes and a fix for jakarta
reloction.

Maven staging repo
https://repository.apache.org/content/repositories/orgapachebatchee-1009

Binaries and sources
https://dist.apache.org/repos/dist/dev/geronimo/batchee/1.0.2

Github Tag
https://github.com/apache/geronimo-batchee/tree/batchee-1.0.2

Release Notes
https://issues.apache.org/jira/projects/BATCHEE/versions/12350726


Please VOTE

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

The VOTE is open for 72h
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

BatchEE releases?

[Jean-Louis Monteiro]

Hi,

is there any issue if I do a release for BatchEE?

I'd like to create a new TomEE mIlestone soon, but we are still using a
SNAPSHOT.

Thanks

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: [VOTE] Release Mail 2.0.0-M1

[Jean-Louis MONTEIRO]

Hey David,

Can you help me find the artifacts please?
I looked at the staging repo, but it does not exist.
Looked at
https://repository.apache.org/content/repositories/releases/org/apache/geronimo/
and I can't see the artifacts.

I'd like to do some upgrades in TomEE, but can't find where the artifacts
are currently.

Le mar. 24 mai 2022 à 08:27, Romain Manni-Bucau  a
écrit :

> Side note: referencing tag+hash + dist (dev) area (only thing we vote
> against) would be neat for future votes since we dont vote on a staging
> repo.
>
> Anyway thanks for doing it, really great to see you back ;)
>
> PS: dont forget jira and site updates, we missed it by the past and hurts
> way later when we need to catch up.
>
> Le lun. 23 mai 2022 à 18:15, David Blevins  a
> écrit :
>
>> Vote passes with 6 +1s (4 binding)
>>
>> As noted in the other vote I didn't propose a final as we haven't yet run
>> the full set of TCK tests for this library, specifically the signature
>> tests.  In particular, the signature tests verify all the classes and
>> method signatures match the expected set and there are no
>> additions/changes, etc.  These are separate from the
>> com.sun.ts.tests.javamail tests.
>>
>> In the past we would always ensure these tests before releasing.
>>
>>
>> -David
>>
>>
>> > On May 14, 2022, at 2:27 PM, David Blevins 
>> wrote:
>> >
>> > Hey All,
>> >
>> > If I was thinking ahead I'd have put these both in the same staging
>> repo and vote :)
>> >
>> > Staging Maven repository:
>> >
>> > -
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
>> >
>> > The only change is conversion from javax to the jakarta namespace via
>> contributor Richard Zowalla and a change from "javamail" to simply "mail"
>> >
>> >
>> > Please vote to approve this release:
>> > [ ] +1 Approve the release
>> > [ ]  0 Abstain (please provide specific comments)
>> > [ ] -1 Don't approve the release (please provide specific comments)
>> >
>> > This vote will be open for at least 72 hours.
>> >
>> > -David
>> >
>>
>>

-- 
Jean-Louis

BatchEE TCK?

[Jean-Louis Monteiro]

Hi,

Did someone try to run jBatch TCK against BatchEE?


--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Jean-Louis MONTEIRO]

up ...

Le mer. 25 mai 2022 à 14:54, Romain Manni-Bucau  a
écrit :

> +1 after the discussion in the other thread and points Richard raised
>
> 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. 25 mai 2022 à 02:13, Jean-Louis MONTEIRO  a
> écrit :
>
>> here is my own +1 (binding)
>>
>> Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO  a
>> écrit :
>>
>>> I always find it better when we can keep backward compatibility for
>>> users.
>>> But this is a major version and I'm not a big fan of cheap system
>>> properties.
>>>
>>> If we think it's not good, we should create a challenge to get it fixed
>>> in the spec + TCK.
>>> Otherwise, I would keep it the way it is. If it breaks users and we want
>>> to help them out, it's still time to add the system property or a better
>>> configuration option and do a maintenance release.
>>>
>>> I'd go lazy instead of eager considering it's a major version.
>>> Meanwhile, I'd create an issue on the TCK + Spec
>>>
>>>
>>> Le mar. 24 mai 2022 à 13:21, Zowalla, Richard <
>>> richard.zowa...@hs-heilbronn.de> a écrit :
>>>
>>>> Romain mentioned the idea (via Slack) of introducing a (cheap) system
>>>> property, which a user can specifiy to get back the old behaviour.
>>>>
>>>> If we want to follow the compatibility appraoch, we should add that
>>>> flag as the spec / RI is really unclear.
>>>>
>>>>
>>>> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
>>>> > I conclude the same thing thanks your pointers so back to the
>>>> > question: do we want to maintain the compat for our user base, do we
>>>> > want to align on the random spec behavior or do we don't care?
>>>> > Indeed I'm always in first team, in particular there since it will be
>>>> > deprecated so the least we touch the best it is but guess it is a 50-
>>>> > 50 case in terms of actual points :s.
>>>> >
>>>> > Romain Manni-Bucau
>>>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>>>> >
>>>> >
>>>> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
>>>> > richard.zowa...@hs-heilbronn.de> a écrit :
>>>> > > The test in question is
>>>> > >
>>>> https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
>>>> > >
>>>> > > which expects the plain parameter value instead of
>>>> > > "parameter=value" as
>>>> > > a return value.
>>>> > >
>>>> > > The JavaDoc is also not quite clear about it:
>>>> > >
>>>> > >
>>>> https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
>>>> > >
>>>> > > with "This method is called for each parameter name/value pair and
>>>> > > should return the normalized representation of the
>>>> > > parameterValue.".
>>>> > >
>>>> > > The spec document itself
>>>> > >
>>>> https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
>>>> > >  doesn't mention anything about it.
>>>> > >
>>>> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
>>>> > > there)
>>>> > > to keep compatibility after removing the references to it.
>>>> > >
>>>> > > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
>>>> > > Bucau:
>>>> > > > Hmm, before that the question is "are the TCK spec compliant", a
>>>> > > lot
>>>> > > > have a reference in the spec we maybe missed, do you have some
>>>> > > > pointers on them? If we were wrong let's fix it, if the TCK are

Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Jean-Louis MONTEIRO]

here is my own +1 (binding)

Le mer. 25 mai 2022 à 02:12, Jean-Louis MONTEIRO  a
écrit :

> I always find it better when we can keep backward compatibility for users.
> But this is a major version and I'm not a big fan of cheap system
> properties.
>
> If we think it's not good, we should create a challenge to get it fixed in
> the spec + TCK.
> Otherwise, I would keep it the way it is. If it breaks users and we want
> to help them out, it's still time to add the system property or a better
> configuration option and do a maintenance release.
>
> I'd go lazy instead of eager considering it's a major version.
> Meanwhile, I'd create an issue on the TCK + Spec
>
>
> Le mar. 24 mai 2022 à 13:21, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
>
>> Romain mentioned the idea (via Slack) of introducing a (cheap) system
>> property, which a user can specifiy to get back the old behaviour.
>>
>> If we want to follow the compatibility appraoch, we should add that
>> flag as the spec / RI is really unclear.
>>
>>
>> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
>> > I conclude the same thing thanks your pointers so back to the
>> > question: do we want to maintain the compat for our user base, do we
>> > want to align on the random spec behavior or do we don't care?
>> > Indeed I'm always in first team, in particular there since it will be
>> > deprecated so the least we touch the best it is but guess it is a 50-
>> > 50 case in terms of actual points :s.
>> >
>> > Romain Manni-Bucau
>> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> >
>> >
>> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
>> > richard.zowa...@hs-heilbronn.de> a écrit :
>> > > The test in question is
>> > >
>> https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
>> > >
>> > > which expects the plain parameter value instead of
>> > > "parameter=value" as
>> > > a return value.
>> > >
>> > > The JavaDoc is also not quite clear about it:
>> > >
>> > >
>> https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
>> > >
>> > > with "This method is called for each parameter name/value pair and
>> > > should return the normalized representation of the
>> > > parameterValue.".
>> > >
>> > > The spec document itself
>> > >
>> https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
>> > >  doesn't mention anything about it.
>> > >
>> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
>> > > there)
>> > > to keep compatibility after removing the references to it.
>> > >
>> > > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
>> > > Bucau:
>> > > > Hmm, before that the question is "are the TCK spec compliant", a
>> > > lot
>> > > > have a reference in the spec we maybe missed, do you have some
>> > > > pointers on them? If we were wrong let's fix it, if the TCK are
>> > > wrong
>> > > > then maybe ignore the TCK?
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
>> > > >
>> > > >
>> > > > Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
>> > > > richard.zowa...@hs-heilbronn.de> a écrit :
>> > > > > There is a TCK test regarding normalizeMimeTypeParameter which
>> > > > > broke with the current impl of normalizeMimeTypeParameter
>> > > > >
>> > > > > Therefore, I adjusted it but agree that it is mit really
>> > > specified.
>> > > > > Question would be, if it is "ok" to fail specific tests of the
>> > > TCK.
>> > > > >
>> > > > > Gruß
>> > > > > Richard
>> > > > > Von: Romain Manni-Bucau 
>> > > > > Gesendet: Dienstag, 24. Mai 2022 11:53:37
>> > > > > An: dev@geronimo.apache.org
>> > > > > Betreff: Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
>> > > &g

Re: [VOTE] Geronimo activation_2.0_spec 1.0.0

[Jean-Louis MONTEIRO]

I always find it better when we can keep backward compatibility for users.
But this is a major version and I'm not a big fan of cheap system
properties.

If we think it's not good, we should create a challenge to get it fixed in
the spec + TCK.
Otherwise, I would keep it the way it is. If it breaks users and we want to
help them out, it's still time to add the system property or a better
configuration option and do a maintenance release.

I'd go lazy instead of eager considering it's a major version.
Meanwhile, I'd create an issue on the TCK + Spec


Le mar. 24 mai 2022 à 13:21, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Romain mentioned the idea (via Slack) of introducing a (cheap) system
> property, which a user can specifiy to get back the old behaviour.
>
> If we want to follow the compatibility appraoch, we should add that
> flag as the spec / RI is really unclear.
>
>
> Am Dienstag, dem 24.05.2022 um 13:01 +0200 schrieb Romain Manni-Bucau:
> > I conclude the same thing thanks your pointers so back to the
> > question: do we want to maintain the compat for our user base, do we
> > want to align on the random spec behavior or do we don't care?
> > Indeed I'm always in first team, in particular there since it will be
> > deprecated so the least we touch the best it is but guess it is a 50-
> > 50 case in terms of actual points :s.
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le mar. 24 mai 2022 à 12:57, Zowalla, Richard <
> > richard.zowa...@hs-heilbronn.de> a écrit :
> > > The test in question is
> > >
> https://github.com/eclipse-ee4j/jaf-tck/blob/2.0.1/tests/api/javasoft/sqe/tests/jakarta/activation/ActivationDataFlavor/normalizeMimeTypeParameter_Test.java
> > >
> > > which expects the plain parameter value instead of
> > > "parameter=value" as
> > > a return value.
> > >
> > > The JavaDoc is also not quite clear about it:
> > >
> > >
> https://jakarta.ee/specifications/activation/2.0/apidocs/jakarta.activation/jakarta/activation/activationdataflavor#normalizeMimeTypeParameter(java.lang.String,java.lang.String)
> > >
> > > with "This method is called for each parameter name/value pair and
> > > should return the normalized representation of the
> > > parameterValue.".
> > >
> > > The spec document itself
> > >
> https://jakarta.ee/specifications/activation/2.0/jakarta-activation-spec-2.0.html
> > >  doesn't mention anything about it.
> > >
> > > Guess it is a relict from java.awt.DataFlavour (also @Deprecated
> > > there)
> > > to keep compatibility after removing the references to it.
> > >
> > > Am Dienstag, dem 24.05.2022 um 12:42 +0200 schrieb Romain Manni-
> > > Bucau:
> > > > Hmm, before that the question is "are the TCK spec compliant", a
> > > lot
> > > > have a reference in the spec we maybe missed, do you have some
> > > > pointers on them? If we were wrong let's fix it, if the TCK are
> > > wrong
> > > > then maybe ignore the TCK?
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> > > >
> > > >
> > > > Le mar. 24 mai 2022 à 12:33, Zowalla, Richard <
> > > > richard.zowa...@hs-heilbronn.de> a écrit :
> > > > > There is a TCK test regarding normalizeMimeTypeParameter which
> > > > > broke with the current impl of normalizeMimeTypeParameter
> > > > >
> > > > > Therefore, I adjusted it but agree that it is mit really
> > > specified.
> > > > > Question would be, if it is "ok" to fail specific tests of the
> > > TCK.
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > > Von: Romain Manni-Bucau 
> > > > > Gesendet: Dienstag, 24. Mai 2022 11:53:37
> > > > > An: dev@geronimo.apache.org
> > > > > Betreff: Re: [VOTE] Geronimo activation_2.0_spec 1.0.0
> > > > >
> > > > > Not voting negatively but seems we
> > > > > broke normalizeMimeTypeParameter (I guess copying the RI?) and
> > > I'm
> > > > > not sure it should be done.
> > > > > From my understanding this part is not well specified and
> > > highly
> > > > > depends on the impl but I don't see a reson to break existing
> > > > > consumers which I always favor in re

[VOTE] Geronimo activation_2.0_spec 1.0.0

[Jean-Louis Monteiro]

Here we go

We now pass all TCK and signature tests. Thanks Richard.

This is essentially the same as the M1 David did last week but with the
fixes for compliance (See GERONIMO-6832)

Here is the link for sources
https://dist.apache.org/repos/dist/dev/geronimo/activation_2.0_spec/

Here is the svn tag
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-activation_2.0_spec-1.0.0/

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

Please vote to approve this release:
[ ] +1 Approve the release
[ ]  0 Abstain (please provide specific comments)
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks



--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: GERONIMO-6832 - SigTests + TCK Failures for Activation 2.0.0-M1

[Jean-Louis MONTEIRO]

Hi Richard,

I reviewed and merged you diff.

Thanks

Le lun. 23 mai 2022 à 21:56, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Hi all,
>
> I gave it a try: the main issues were related to the change regarding
> java.desktop.
>
> I added a patch (svn diff) to
> https://issues.apache.org/jira/browse/GERONIMO-6832 with some changes.
> With this changes, the TCK + Sigtests are now passing for Java 8 + Java
> 11:
>
> [javatest.batch] Number of tests completed:  90 (90 pass, 0 fail, 0
> errors)
> [javatest.batch]
> ***
> [javatest.batch] Completed running 90 tests.
> [javatest.batch] Number of Tests Passed  = 90
> [javatest.batch] Number of Tests Failed  = 0
> [javatest.batch] Number of Tests with Errors = 0
> [javatest.batch] Number of Tests Not Run = 0
>
> If someone can have a look, it would be appreciated.
>
> Gruß
> Richard
>
>
> Am Montag, dem 23.05.2022 um 18:47 + schrieb Zowalla, Richard:
> > Hi all,
> >
> > I did run the sig tests + tck on the 2.0.0-M1 and found some issues.
> > Subsequently, I created
> > https://issues.apache.org/jira/browse/GERONIMO-6832 and will try to
> > fix
> > them.
> >
> > Gruß
> > Richard
> >
>
>

-- 
Jean-Louis

[jira] [Resolved] (GERONIMO-6832) Fix TCK + Signature Tests for geronimo-activation_2.0_spec

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6832.
---
Fix Version/s: Spec_Activation_2.0_1.0.0
   Resolution: Fixed

Thanks Richard

> Fix TCK + Signature Tests for geronimo-activation_2.0_spec
> --
>
> Key: GERONIMO-6832
> URL: https://issues.apache.org/jira/browse/GERONIMO-6832
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Richard Zowalla
>Priority: Major
> Fix For: Spec_Activation_2.0_1.0.0
>
> Attachments: GERONIMO-6832.diff
>
>
> Did run the sigtests + TCK and found some issues.
> Sigtests currently fail due to some issues regarding the removal of the 
> depenency towards java.desktop + TCK also have has issues.
> Did test with the milestone version. I will try to fix them.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Submitting a CCR for Geronimo Mail and Activation

[Jean-Louis Monteiro]

Hello,

With the last release David did, Richard ran the TCK and the signature
tests and it looks like we are now fully compliant.

What about submitting a CCR to Eclipse foundation Jakarta to be listed as a
compliant implementation?

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

Re: [VOTE] Release Activation 2.0.0-M1

[Jean-Louis MONTEIRO]

+1

Same feedback, I'd go for a final. There is no work remaining as far as I
can tell

Le dim. 15 mai 2022 à 09:03, Romain Manni-Bucau  a
écrit :

> Hi
>
> If we are confident to match javax/jakarta namespace change why not doing
> a final? Errors/missing features could go in bugs.
> Issue with milestones is the tooling support and proposed updates vs
> version policies so if we can avoid it I would be for it but not sure if I
> missed sthg.
>
> Le dim. 15 mai 2022 à 07:29, Jean-Baptiste Onofré  a
> écrit :
>
>> +1 (binding)
>>
>> Regards
>> JB
>>
>> On Sat, May 14, 2022 at 11:00 PM David Blevins 
>> wrote:
>> >
>> > Hey All,
>> >
>> > We're thinking to do a release on the TomEE side and this is one of the
>> snapshot dependencies we have.  I've prepped a 2.0.0-M1 with the idea that
>> being a milestone it should be fairly non-controversial to propose without
>> a heads up and I haven't checked the TCK status.  I know we're not yet
>> actively running the signature tests on the TomEE side.
>> >
>> > I propose we release 2.0.0-M1 so we have some non-snapshots to work
>> with and come back to 2.0.0 as things look 100% on all fronts
>> >
>> > Staging Maven repository:
>> >
>> >  -
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
>> >
>> > The only change is conversion from javax to the jakarta namespace via
>> contributor Richard Zowalla.
>> >
>> >
>> > Please vote to approve this release:
>> > [ ] +1 Approve the release
>> > [ ]  0 Abstain (please provide specific comments)
>> > [ ] -1 Don't approve the release (please provide specific comments)
>> >
>> > This vote will be open for at least 72 hours.
>> >
>> > -David
>> >
>>
>

-- 
Jean-Louis

Re: [VOTE] Release Mail 2.0.0-M1

[Jean-Louis MONTEIRO]

+1

But I agree with Romain, don't think there is remaining work on this one
for now. So wondering why we need a milestone.
We ran the unit tests and we ran all the platform TCK for Mail and
everything is passing.

Le dim. 15 mai 2022 à 11:31, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Side note: JL did run the mail tck:
> https://tck.work/tomee/tests?build=1651841331620=com.sun.ts.tests.javamail
>
> Gruß
> Richard
> --
> *Von:* David Blevins 
> *Gesendet:* Samstag, 14. Mai 2022 23:27:29
> *An:* dev@geronimo.apache.org
> *Betreff:* [VOTE] Release Mail 2.0.0-M1
>
> Hey All,
>
> If I was thinking ahead I'd have put these both in the same staging repo
> and vote :)
>
> Staging Maven repository:
>
> -
> https://repository.apache.org/content/repositories/orgapachegeronimo-1153/
>
> The only change is conversion from javax to the jakarta namespace via
> contributor Richard Zowalla and a change from "javamail" to simply "mail"
>
>
> Please vote to approve this release:
> [ ] +1 Approve the release
> [ ]  0 Abstain (please provide specific comments)
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> -David
>
>

-- 
Jean-Louis

[jira] [Resolved] (GERONIMO-6829) Create geronimo-jakartamail_2.1_spec & geronimo-activation_2.0_spec

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6829.
---
Resolution: Fixed

> Create geronimo-jakartamail_2.1_spec & geronimo-activation_2.0_spec
> ---
>
> Key: GERONIMO-6829
> URL: https://issues.apache.org/jira/browse/GERONIMO-6829
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Richard Zowalla
>Priority: Major
>
> Task for adding jakartmail 2.1 spec
> Impl / API are a bit tied together. We can start with 1.6 & package renamings 
> and figure out potential gaps later.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Re: TomEE MicroProfile and Jakarta

[Jean-Louis Monteiro]

Hi,

Following our discussion I went ahead and did the following
- yank all Geronimo MicroProfile implementations until we can update them
- update MicroProfile APIs to their latest and jakarta compatible versions
- add SmallRye implementations for Config, Fault-Tolerance, OpenAPI,
OpenTracing, Health and Metrics.
- Kept our JWT microprofile implementation
- Used CXF shaded and relocated version of the Rest Client

Now, where are we?
Doing all that worked but does not make TomEE to now be MicroProfile
compliant.
I went ahead and also updated all TCK to use the latest TCK and jakarta
compatible version of MicroProfile.

Unfortunately, SmallRye isn't like Geronimo so adding the libraries does
not make anything happen. We were failing in all specifications. It's just
a base set of libraries you can rely on, but ultimately, you need to write
some integration code.

Did most of the integration for Config, Metrics, Health, JWT and
Rest-Client. Haven't started Fault-Tolerance and OpenAPI.

- Config: we have 3 failures to look at. It might need some more code to
address edge cases.
- JWT: 22 failures and 12 not executed. Mainly a key issue.
- Metrics: all green, yeah
- Health: a few failures I'm working on now
- Rest Client: half failing or maybe more - tck setup or missing bits to
start with
- OpenAPI, Fault-tolerance: all failing or almost - no TCK setup or
integration code

I'd appreciate some help as I feel like I'm not seeing the end of the
tunnel lol

Hope it helps







--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Sat, Apr 2, 2022 at 11:13 AM Jean-Louis Monteiro <
jlmonte...@tomitribe.com> wrote:

> Great discussion. Thanks everyone.
>
> I'll look at Sallrye over the weekend and see how hard it is to replace
> our Apache libraries.
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Fri, Apr 1, 2022 at 12:48 PM David Blevins 
> wrote:
>
>> This is very close.  The dangers of A are not quite captured.  Completely
>> agree with the dangers of B.
>>
>> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
>> richard.zowa...@hs-heilbronn.de> wrote:
>> >
>> > So we basically have to options (if I understand the discussion
>> > correctly):
>> >
>> > (A) Put some effort / resources into upgrade our MP impls to the latest
>> > versions to fully support Jakarta namespace. From my understanding
>> > maintaining these impls is a bit PITA as MP tends to break its API
>> > every few months, right? It will take some time, effort and resources
>> > to catch up.
>>
>> The danger here is that we - due to lack of time / resources - will
>> continue to not be seen as a viable MicroProfile implementation.
>>
>> MicroProfile is approximately 70 months old.  We were able to keep up for
>> only 1.5 months out of that 70.  It was with TomEE 7.1, released with
>> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
>> in October 2018.  We were 27 months late to getting our first and only
>> MicroProfile version implemented, which is now 41 months out of date.
>>
>> >
>> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
>> > side, which breaks the "we use apache impls"-credo but enables a faster
>> > move forward. I see the danger here that we - due to lack of time /
>> > resources - will not find the way back to our own Apache
>> > implementations and will stick with smallrye for a long (?) time
>> > perhaps.
>>
>> Correct.  And as mentioned, not finding our way back to our own Apache
>> implementations has already been the status quo.
>>
>> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
>> > ready for it, yet. With the latest M7 version, users cannot start new
>> > projects as testing possibilities are super limited.
>> >
>> > Btw.: I am unsure, if we are still using Hibernate Validation in the
>> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
>> > "everything from apache"-credo for the sake of getting the
>> > certifaction.
>>
>> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
>> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>>
>>
>> -David
>>
>>

Re: TomEE MicroProfile and Jakarta

[Jean-Louis Monteiro]

Great discussion. Thanks everyone.

I'll look at Sallrye over the weekend and see how hard it is to replace our
Apache libraries.

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Fri, Apr 1, 2022 at 12:48 PM David Blevins 
wrote:

> This is very close.  The dangers of A are not quite captured.  Completely
> agree with the dangers of B.
>
> > On Apr 1, 2022, at 1:13 AM, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> wrote:
> >
> > So we basically have to options (if I understand the discussion
> > correctly):
> >
> > (A) Put some effort / resources into upgrade our MP impls to the latest
> > versions to fully support Jakarta namespace. From my understanding
> > maintaining these impls is a bit PITA as MP tends to break its API
> > every few months, right? It will take some time, effort and resources
> > to catch up.
>
> The danger here is that we - due to lack of time / resources - will
> continue to not be seen as a viable MicroProfile implementation.
>
> MicroProfile is approximately 70 months old.  We were able to keep up for
> only 1.5 months out of that 70.  It was with TomEE 7.1, released with
> MicroProfile 2.0 support in September of 2018, outdated by MicroProfile 2.1
> in October 2018.  We were 27 months late to getting our first and only
> MicroProfile version implemented, which is now 41 months out of date.
>
> >
> > (B) Use existing MP impls to make "fast" progress on the TomEE 9.x
> > side, which breaks the "we use apache impls"-credo but enables a faster
> > move forward. I see the danger here that we - due to lack of time /
> > resources - will not find the way back to our own Apache
> > implementations and will stick with smallrye for a long (?) time
> > perhaps.
>
> Correct.  And as mentioned, not finding our way back to our own Apache
> implementations has already been the status quo.
>
> > People are eager to use EE9 / Jakarta namespace and TomEE isn't really
> > ready for it, yet. With the latest M7 version, users cannot start new
> > projects as testing possibilities are super limited.
> >
> > Btw.: I am unsure, if we are still using Hibernate Validation in the
> > current TomEE 9-M8 Snapshot. But if we do, we already broke the
> > "everything from apache"-credo for the sake of getting the
> > certifaction.
>
> Our certified distribution (Plume) used EclipseLink instead of OpenJPA,
> Mojarra instead of MyFaces and Hibernate Bean Validation instead of BVal.
>
>
> -David
>
>

TomEE MicroProfile and Jakarta

[Jean-Louis Monteiro]

Hi,

Small update regarding jakarta namespace switch and MicroProfile. Adding
Geronimo dev@list because we are using most of the Geronimo implementations

In order to migrate, we have created a shaded version of all MicroProfile
APIs to relocate all javax to jakarta. It worked but it's causing some
issues with TCK. They are not relocated so of course, all TCK are failing.

I wanted to see how far we are regarding our implementations, so I went
ahead and updated all TCK to the latest version (and compatible with the
Jakarta namespace).

The other option would be to grab all the TCK and create their equivalent
in jakarta namespace using the same approach as for the APIs.

What are your thoughts?

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com

[jira] [Updated] (GERONIMO-6754) Update Johnzon to 1.2.1 in Geronimo OpenAPI

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro updated GERONIMO-6754:
--
Fix Version/s: OpenTracing_1.0.4
   (was: OpenTracing_1.0.3)

> Update Johnzon to 1.2.1 in Geronimo OpenAPI
> ---
>
> Key: GERONIMO-6754
> URL: https://issues.apache.org/jira/browse/GERONIMO-6754
> Project: Geronimo
>  Issue Type: Improvement
>  Security Level: public(Regular issues) 
>Reporter: Jonathan Gallimore
>Priority: Major
> Fix For: OpenTracing_1.0.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Update Geronimo OpenAPI to use the latest version of Johnzon.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GERONIMO-6728) Geronimo OpenTracing OpenTracingServerRequestFilter is fired twice

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro updated GERONIMO-6728:
--
Fix Version/s: OpenTracing_1.0.4
   (was: OpenTracing_1.0.3)

> Geronimo OpenTracing OpenTracingServerRequestFilter is fired twice
> --
>
> Key: GERONIMO-6728
> URL: https://issues.apache.org/jira/browse/GERONIMO-6728
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Reporter: Jonathan Gallimore
>Assignee: Romain Manni-Bucau
>Priority: Major
> Fix For: OpenTracing_1.0.4
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Geronimo OpenTracing OpenTracingServerRequestFilter is fired twice for a 
> request. This leads to the ThreadLocal in ScopeManagerImpl not being cleaned 
> up properly, and threads picking up the wrong traceId (i.e. from previous 
> threads). 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[RESULT] Apache TransactionManager 3.1.5 and Geronimo Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics 1.0.6

[Jean-Louis MONTEIRO]

Hi!

Vote passes with 4 +1 and no other vote.
I'll promote binaries, update JIRA, dist area and all remaining tasks

Thanks everyone

Le mer. 2 mars 2022 à 19:45, Jean-Louis MONTEIRO  a
écrit :

> My own +1
>
> Le mer. 2 mars 2022 à 14:08, Francois Papon 
> a écrit :
>
>> +1 (binding)
>>
>> Thanks!
>>
>> regards,
>>
>> François
>> On 25/02/2022 12:10, Jean-Louis MONTEIRO wrote:
>>
>> Hi!
>>
>> Just adding VOTE to the message object so it's clear.
>>
>> JLouis
>>
>> Le jeu. 24 févr. 2022 à 20:22, Jean-Louis MONTEIRO 
>> a écrit :
>>
>>> Hi everyone,
>>>
>>> I'd like to release our Apache TransactionManager 3.1.5 and Geronimo
>>> Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics
>>> 1.0.6.
>>>
>>> Main change is to support a jakarta classifier so they can be used in
>>> the context of jakarta namespace, the reason why this vote addresses many
>>> of our components.
>>>
>>> Tags:
>>> - Transaction Manager:
>>> https://github.com/apache/geronimo-txmanager/tree/geronimo-txmanager-parent-3.1.5
>>> - Config:
>>> https://github.com/apache/geronimo-config/tree/geronimo-config-1.2.3
>>> - Health:
>>> https://github.com/apache/geronimo-health/tree/geronimo-health-parent-2.0.1
>>> - OpenAPI:
>>> https://github.com/apache/geronimo-openapi/tree/geronimo-openapi-1.0.15
>>> - OpenTracing:
>>> https://github.com/apache/geronimo-opentracing/tree/geronimo-opentracing-parent-1.0.3
>>> - Metrics:
>>> https://github.com/apache/geronimo-metrics/tree/geronimo-metrics-parent-1.0.6
>>>
>>> Staging repos:
>>> - Transaction Manager:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1146/
>>> - Config:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1147
>>> - Health:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1148
>>> - OpenAPI:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1149
>>> - OpenTracing:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1150
>>> - Metrics:
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1151
>>>
>>> Sources:
>>> - Transaction Manager:
>>> https://dist.apache.org/repos/dist/dev/geronimo/transaction-manager/
>>> - Config: https://dist.apache.org/repos/dist/dev/geronimo/config/
>>> - Health: https://dist.apache.org/repos/dist/dev/geronimo/health/
>>> - OpenAPI: https://dist.apache.org/repos/dist/dev/geronimo/openapi/
>>> - OpenTracing:
>>> https://dist.apache.org/repos/dist/dev/geronimo/opentracing/
>>> - Metrics: https://dist.apache.org/repos/dist/dev/geronimo/metrics/
>>>
>>> Release notes:
>>> - Transaction Manager:
>>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351385
>>> - Config:
>>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345015
>>> - Health:
>>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351383
>>> - OpenAPI:
>>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12349477
>>> - OpenTracing:
>>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345013
>>> - Metrics:
>>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351384
>>>
>>> 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.
>>>
>>>
>>> --
>>> Jean-Louis
>>>
>>
>>
>> --
>> Jean-Louis
>>
>>

-- 
Jean-Louis

Re: [VOTE Apache TransactionManager 3.1.5 and Geronimo Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics 1.0.6

[Jean-Louis MONTEIRO]

My own +1

Le mer. 2 mars 2022 à 14:08, Francois Papon 
a écrit :

> +1 (binding)
>
> Thanks!
>
> regards,
>
> François
> On 25/02/2022 12:10, Jean-Louis MONTEIRO wrote:
>
> Hi!
>
> Just adding VOTE to the message object so it's clear.
>
> JLouis
>
> Le jeu. 24 févr. 2022 à 20:22, Jean-Louis MONTEIRO  a
> écrit :
>
>> Hi everyone,
>>
>> I'd like to release our Apache TransactionManager 3.1.5 and Geronimo
>> Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics
>> 1.0.6.
>>
>> Main change is to support a jakarta classifier so they can be used in the
>> context of jakarta namespace, the reason why this vote addresses many of
>> our components.
>>
>> Tags:
>> - Transaction Manager:
>> https://github.com/apache/geronimo-txmanager/tree/geronimo-txmanager-parent-3.1.5
>> - Config:
>> https://github.com/apache/geronimo-config/tree/geronimo-config-1.2.3
>> - Health:
>> https://github.com/apache/geronimo-health/tree/geronimo-health-parent-2.0.1
>> - OpenAPI:
>> https://github.com/apache/geronimo-openapi/tree/geronimo-openapi-1.0.15
>> - OpenTracing:
>> https://github.com/apache/geronimo-opentracing/tree/geronimo-opentracing-parent-1.0.3
>> - Metrics:
>> https://github.com/apache/geronimo-metrics/tree/geronimo-metrics-parent-1.0.6
>>
>> Staging repos:
>> - Transaction Manager:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1146/
>> - Config:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1147
>> - Health:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1148
>> - OpenAPI:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1149
>> - OpenTracing:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1150
>> - Metrics:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1151
>>
>> Sources:
>> - Transaction Manager:
>> https://dist.apache.org/repos/dist/dev/geronimo/transaction-manager/
>> - Config: https://dist.apache.org/repos/dist/dev/geronimo/config/
>> - Health: https://dist.apache.org/repos/dist/dev/geronimo/health/
>> - OpenAPI: https://dist.apache.org/repos/dist/dev/geronimo/openapi/
>> - OpenTracing:
>> https://dist.apache.org/repos/dist/dev/geronimo/opentracing/
>> - Metrics: https://dist.apache.org/repos/dist/dev/geronimo/metrics/
>>
>> Release notes:
>> - Transaction Manager:
>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351385
>> - Config:
>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345015
>> - Health:
>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351383
>> - OpenAPI:
>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12349477
>> - OpenTracing:
>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345013
>> - Metrics:
>> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351384
>>
>> 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.
>>
>>
>> --
>> Jean-Louis
>>
>
>
> --
> Jean-Louis
>
>

[VOTE Apache TransactionManager 3.1.5 and Geronimo Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics 1.0.6

[Jean-Louis MONTEIRO]

Hi!

Just adding VOTE to the message object so it's clear.

JLouis

Le jeu. 24 févr. 2022 à 20:22, Jean-Louis MONTEIRO  a
écrit :

> Hi everyone,
>
> I'd like to release our Apache TransactionManager 3.1.5 and Geronimo
> Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics
> 1.0.6.
>
> Main change is to support a jakarta classifier so they can be used in the
> context of jakarta namespace, the reason why this vote addresses many of
> our components.
>
> Tags:
> - Transaction Manager:
> https://github.com/apache/geronimo-txmanager/tree/geronimo-txmanager-parent-3.1.5
> - Config:
> https://github.com/apache/geronimo-config/tree/geronimo-config-1.2.3
> - Health:
> https://github.com/apache/geronimo-health/tree/geronimo-health-parent-2.0.1
> - OpenAPI:
> https://github.com/apache/geronimo-openapi/tree/geronimo-openapi-1.0.15
> - OpenTracing:
> https://github.com/apache/geronimo-opentracing/tree/geronimo-opentracing-parent-1.0.3
> - Metrics:
> https://github.com/apache/geronimo-metrics/tree/geronimo-metrics-parent-1.0.6
>
> Staging repos:
> - Transaction Manager:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1146/
> - Config:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1147
> - Health:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1148
> - OpenAPI:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1149
> - OpenTracing:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1150
> - Metrics:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1151
>
> Sources:
> - Transaction Manager:
> https://dist.apache.org/repos/dist/dev/geronimo/transaction-manager/
> - Config: https://dist.apache.org/repos/dist/dev/geronimo/config/
> - Health: https://dist.apache.org/repos/dist/dev/geronimo/health/
> - OpenAPI: https://dist.apache.org/repos/dist/dev/geronimo/openapi/
> - OpenTracing:
> https://dist.apache.org/repos/dist/dev/geronimo/opentracing/
> - Metrics: https://dist.apache.org/repos/dist/dev/geronimo/metrics/
>
> Release notes:
> - Transaction Manager:
> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351385
> - Config:
> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345015
> - Health:
> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351383
> - OpenAPI:
> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12349477
> - OpenTracing:
> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345013
> - Metrics:
> https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351384
>
> 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.
>
>
> --
> Jean-Louis
>


-- 
Jean-Louis

Apache TransactionManager 3.1.5 and Geronimo Config 1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics 1.0.6

[Jean-Louis MONTEIRO]

Hi everyone,

I'd like to release our Apache TransactionManager 3.1.5 and Geronimo Config
1.2.3, Health 2.0.1, OpenAPI 1.0.15, OpenTracing 1.0.3, Metrics 1.0.6.

Main change is to support a jakarta classifier so they can be used in the
context of jakarta namespace, the reason why this vote addresses many of
our components.

Tags:
- Transaction Manager:
https://github.com/apache/geronimo-txmanager/tree/geronimo-txmanager-parent-3.1.5
- Config:
https://github.com/apache/geronimo-config/tree/geronimo-config-1.2.3
- Health:
https://github.com/apache/geronimo-health/tree/geronimo-health-parent-2.0.1
- OpenAPI:
https://github.com/apache/geronimo-openapi/tree/geronimo-openapi-1.0.15
- OpenTracing:
https://github.com/apache/geronimo-opentracing/tree/geronimo-opentracing-parent-1.0.3
- Metrics:
https://github.com/apache/geronimo-metrics/tree/geronimo-metrics-parent-1.0.6

Staging repos:
- Transaction Manager:
https://repository.apache.org/content/repositories/orgapachegeronimo-1146/
- Config:
https://repository.apache.org/content/repositories/orgapachegeronimo-1147
- Health:
https://repository.apache.org/content/repositories/orgapachegeronimo-1148
- OpenAPI:
https://repository.apache.org/content/repositories/orgapachegeronimo-1149
- OpenTracing:
https://repository.apache.org/content/repositories/orgapachegeronimo-1150
- Metrics:
https://repository.apache.org/content/repositories/orgapachegeronimo-1151

Sources:
- Transaction Manager:
https://dist.apache.org/repos/dist/dev/geronimo/transaction-manager/
- Config: https://dist.apache.org/repos/dist/dev/geronimo/config/
- Health: https://dist.apache.org/repos/dist/dev/geronimo/health/
- OpenAPI: https://dist.apache.org/repos/dist/dev/geronimo/openapi/
- OpenTracing: https://dist.apache.org/repos/dist/dev/geronimo/opentracing/
- Metrics: https://dist.apache.org/repos/dist/dev/geronimo/metrics/

Release notes:
- Transaction Manager:
https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351385
- Config:
https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345015
- Health:
https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351383
- OpenAPI:
https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12349477
- OpenTracing:
https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12345013
- Metrics:
https://issues.apache.org/jira/browse/GERONIMO/fixforversion/12351384

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.


-- 
Jean-Louis

[jira] [Resolved] (GERONIMO-6828) Support for Jakarta classifier binaries for jakarta namespace

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6828.
---
Fix Version/s: Health_2.0.1
   Metrics_1.0.6
   TransactionManager_3.1.5
   OpenTracing_1.0.3
   Config_1.2.3
   OpenAPI_1.0.15
 Assignee: Jean-Louis Monteiro
   Resolution: Fixed

> Support for Jakarta classifier binaries for jakarta namespace
> -
>
> Key: GERONIMO-6828
> URL: https://issues.apache.org/jira/browse/GERONIMO-6828
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config, Health, Metrics, OpenAPI, OpenTracing, 
> transaction manager
>Reporter: Jean-Louis Monteiro
>    Assignee: Jean-Louis Monteiro
>Priority: Major
> Fix For: Health_2.0.1, Metrics_1.0.6, TransactionManager_3.1.5, 
> OpenTracing_1.0.3, Config_1.2.3, OpenAPI_1.0.15
>
>
> The idea is to leverage the maven shade plugin to relocated our binaries and 
> publish under a jakarta classifier
> Some of our libraries already have it declared, so it's a matter of refining 
> when needed.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GERONIMO-6828) Support for Jakarta classifier binaries for jakarta namespace

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro updated GERONIMO-6828:
--
Component/s: transaction manager

> Support for Jakarta classifier binaries for jakarta namespace
> -
>
> Key: GERONIMO-6828
> URL: https://issues.apache.org/jira/browse/GERONIMO-6828
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config, Health, Metrics, OpenAPI, OpenTracing, 
> transaction manager
>Reporter: Jean-Louis Monteiro
>Priority: Major
>
> The idea is to leverage the maven shade plugin to relocated our binaries and 
> publish under a jakarta classifier



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GERONIMO-6828) Support for Jakarta classifier binaries for jakarta namespace

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro updated GERONIMO-6828:
--
Description: 
The idea is to leverage the maven shade plugin to relocated our binaries and 
publish under a jakarta classifier

Some of our libraries already have it declared, so it's a matter of refining 
when needed.

 

  was:The idea is to leverage the maven shade plugin to relocated our binaries 
and publish under a jakarta classifier


> Support for Jakarta classifier binaries for jakarta namespace
> -
>
> Key: GERONIMO-6828
> URL: https://issues.apache.org/jira/browse/GERONIMO-6828
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: Config, Health, Metrics, OpenAPI, OpenTracing, 
> transaction manager
>Reporter: Jean-Louis Monteiro
>Priority: Major
>
> The idea is to leverage the maven shade plugin to relocated our binaries and 
> publish under a jakarta classifier
> Some of our libraries already have it declared, so it's a matter of refining 
> when needed.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GERONIMO-6828) Support for Jakarta classifier binaries for jakarta namespace

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6828:
-

 Summary: Support for Jakarta classifier binaries for jakarta 
namespace
 Key: GERONIMO-6828
 URL: https://issues.apache.org/jira/browse/GERONIMO-6828
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: Metrics, Health, OpenAPI, OpenTracing, Config
Reporter: Jean-Louis Monteiro


The idea is to leverage the maven shade plugin to relocated our binaries and 
publish under a jakarta classifier



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GERONIMO-6827) Jakarta version of Gronimo Transaction manager

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6827.
---
  Assignee: Jean-Louis Monteiro
Resolution: Fixed

> Jakarta version of Gronimo Transaction manager
> --
>
> Key: GERONIMO-6827
> URL: https://issues.apache.org/jira/browse/GERONIMO-6827
> Project: Geronimo
>  Issue Type: New Feature
>  Security Level: public(Regular issues) 
>  Components: transaction manager
>    Reporter: Jean-Louis Monteiro
>Assignee: Jean-Louis Monteiro
>Priority: Major
>
> As we don't really need more than a package relocate, let's start with a 
> shade approach.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GERONIMO-6827) Jakarta version of Gronimo Transaction manager

[Jean-Louis Monteiro (Jira)]

Jean-Louis Monteiro created GERONIMO-6827:
-

 Summary: Jakarta version of Gronimo Transaction manager
 Key: GERONIMO-6827
 URL: https://issues.apache.org/jira/browse/GERONIMO-6827
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: transaction manager
Reporter: Jean-Louis Monteiro


As we don't really need more than a package relocate, let's start with a shade 
approach.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: website subcontexts?

[Jean-Louis MONTEIRO]

Hi!

I have no idea how this works, I'm afraid

Le dim. 31 oct. 2021 à 19:18, Romain Manni-Bucau  a
écrit :

> Hi all,
>
> since CMS was dropped I'm not sure how we are supposed to publish
> subcontext websites.
>
> svn seems inactive (
> https://svn.apache.org/repos/infra/websites/production/geronimo/content/batchee/index.html
> is ok but not what we have in prod) and git does not contain subcontexts (
> https://gitbox.apache.org/repos/asf?p=geronimo-website.git;a=tree;h=refs/heads/master;hb=refs/heads/master)
> so not sure how content is served from
> https://geronimo.apache.org/batchee/ for example.
>
> Any pointer? Do we miss some rule in
> https://github.com/apache/infrastructure-puppet/ (like commit
> 0d4db914be98ad38c0edf7b46c493203c967a9bd) ?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>


-- 
Jean-Louis

Re: [VOTE] Release Apache Geronimo BatchEE 1.0.1

[Jean-Louis MONTEIRO]

+1

Le dim. 31 oct. 2021 à 11:55, Romain Manni-Bucau  a
écrit :

> My own +1
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le ven. 29 oct. 2021 à 09:23, Francois Papon 
> a écrit :
>
>> +1 (binding)
>>
>> regards,
>>
>> François
>> On 28/10/2021 14:11, Romain Manni-Bucau wrote:
>>
>> Hi all,
>>
>> Here is the vote for BatchEE 1.0.1
>>
>> Changelog:
>>
>> [image: Major][image: Task]BATCHEE-152
>> Provide a batchee UI
>> spring-batch/spring-boot bridge
>> Romain Manni-Bucau
>> 
>> RESOLVED[image: Major][image: Task]BATCHEE-153
>> Enable to build the
>> project on java 11 Romain
>> Manni-Bucau
>> 
>> RESOLVED[image: Major][image: Task]BATCHEE-154
>> Drop CXF 2. web
>> client support Romain
>> Manni-Bucau
>> 
>> RESOLVED
>>
>> Staging:
>> https://repository.apache.org/content/repositories/orgapachebatchee-1008/
>> Dist area: https://dist.apache.org/repos/dist/dev/geronimo/batchee/
>> Tag:
>> https://gitbox.apache.org/repos/asf?p=geronimo-batchee.git;a=tag;h=ba4c886d7ad5db1847c479289a81149fa628744f
>> My key is the same than last time.
>>
>> Please vote:
>>
>> [ ] +1 release it
>> [ ] -1 ${cause}
>>
>> Vote will be opened for 3 days or until we get enough binding votes.
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Blog
>>  | Github
>>  | LinkedIn
>>  | Book
>> 
>>
>>

[RESULT][VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1 (reroll)

[Jean-Louis MONTEIRO]

Time to close the vote now.
Vote passes with 3 +1 and no other vote.

+1 from Richard, Raymond, Jean-Louis, Cesar, François, Jean-Baptiste

I'll proceed with the remaining steps.

Jean-Louis

Le sam. 16 oct. 2021 à 04:50, JB Onofré  a écrit :

> +1 (binding)
>
> Regards
> JB
>
> Le 15 oct. 2021 à 21:16, Francois Papon  a
> écrit :
>
> 
>
> +1 (binding)
>
> Thanks!
>
> regards,
>
> Françoisfpapon@apache.orgfrancois.pa...@openobject.fr
>
> Le 15/10/2021 à 15:47, Jean-Louis MONTEIRO a écrit :
>
> Hi!
>
> I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> 1.0.1
> Importante note: we previously voted for the spec part. This vote is for
> the provider and the mail core.
>
> This is a re-roll because we were missing the spec update.
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1143
>
> And the source jar which is voted on
>
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
>
> Git tag
>
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-1.0.1
> <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
>
>

-- 
Jean-Louis

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1 (reroll)

[Jean-Louis MONTEIRO]

+1 (binding)

Le ven. 15 oct. 2021 à 15:55, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> +1 (thx, JL)
>
> Am Freitag, dem 15.10.2021 um 15:47 +0200 schrieb Jean-Louis MONTEIRO:
> > Hi!
> >
> > I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> > 1.0.1
> > Importante note: we previously voted for the spec part. This vote is
> > for the provider and the mail core.
> >
> > This is a re-roll because we were missing the spec update.
> >
> > Here is the staging repo
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1143
> >
> > And the source jar which is voted on
> >
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
> >
> > Git tag
> >
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-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

[VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1 (reroll)

[Jean-Louis MONTEIRO]

Hi!

I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail) 1.0.1
Importante note: we previously voted for the spec part. This vote is for
the provider and the mail core.

This is a re-roll because we were missing the spec update.

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

And the source jar which is voted on
https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip

Git tag
https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-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

[CANCEL][VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Jean-Louis MONTEIRO]

Even though it is not a legal issue, I'll reroll to update the spec part in
the provider and mail.
For javamail, they are all pretty much tight together so better to update
spec

Le mar. 12 oct. 2021 à 22:51, Jean-Louis MONTEIRO  a
écrit :

> Hi!
>
> I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> 1.0.1
> Importante note: we previously voted for the spec part. This vote is for
> the provider and the mail core.
>
> Here is the staging repo
> https://repository.apache.org/content/repositories/orgapachegeronimo-1142
> <https://repository.apache.org/content/repositories/orgapachegeronimo-1141>
>
> And the source jar which is voted on
>
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
>
> Git tag
>
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-1.0.1
> <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
>


-- 
Jean-Louis

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Jean-Louis MONTEIRO]

I'll cancel this one and re-roll.

Le ven. 15 oct. 2021 à 15:18, Jean-Louis MONTEIRO  a
écrit :

> It would have been better yes
>
> Le ven. 15 oct. 2021 à 15:17, Zowalla, Richard <
> richard.zowa...@hs-heilbronn.de> a écrit :
>
>> Shouldn't it be spec v1.0.1 in the POM:
>>
>> https://github.com/apache/geronimo-javamail/blob/geronimo-javamail_1.6-1.0.1/geronimo-javamail_1.6/pom.xml#L46
>>
>> I am just curios and might be wrong? :)
>>
>>
>> Am Dienstag, dem 12.10.2021 um 22:51 +0200 schrieb Jean-Louis MONTEIRO:
>> > Hi!
>> >
>> > I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
>> > 1.0.1
>> > Importante note: we previously voted for the spec part. This vote is
>> > for the provider and the mail core.
>> >
>> > Here is the staging repo
>> >
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1142
>> >
>> > And the source jar which is voted on
>> >
>> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
>> >
>> > Git tag
>> >
>> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-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
>>
>
>
> --
> Jean-Louis
>


-- 
Jean-Louis

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Jean-Louis MONTEIRO]

It would have been better yes

Le ven. 15 oct. 2021 à 15:17, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> Shouldn't it be spec v1.0.1 in the POM:
>
> https://github.com/apache/geronimo-javamail/blob/geronimo-javamail_1.6-1.0.1/geronimo-javamail_1.6/pom.xml#L46
>
> I am just curios and might be wrong? :)
>
>
> Am Dienstag, dem 12.10.2021 um 22:51 +0200 schrieb Jean-Louis MONTEIRO:
> > Hi!
> >
> > I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
> > 1.0.1
> > Importante note: we previously voted for the spec part. This vote is
> > for the provider and the mail core.
> >
> > Here is the staging repo
> >
> https://repository.apache.org/content/repositories/orgapachegeronimo-1142
> >
> > And the source jar which is voted on
> >
> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
> >
> > Git tag
> >
> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-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
>


-- 
Jean-Louis

Re: [VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Jean-Louis MONTEIRO]

My own +1


Le mer. 13 oct. 2021 à 20:06, Cesar Hernandez  a
écrit :

> As a side note, the first link works if you copy/paste the url, the link
> itself hast the last digit as 1 instead of 2
>
> [works]
> https://repository.apache.org/content/repositories/orgapachegeronimo-1142 
> trying
> to link to
> [Not found ]
> https://repository.apache.org/content/repositories/orgapachegeronimo-1141
>
> El mié, 13 oct 2021 a las 12:03, Cesar Hernandez ()
> escribió:
>
>> +1
>>
>> El mié, 13 oct 2021 a las 0:53, Zowalla, Richard (<
>> richard.zowa...@hs-heilbronn.de>) escribió:
>>
>>> +1
>>>
>>> Am Dienstag, dem 12.10.2021 um 22:51 +0200 schrieb Jean-Louis MONTEIRO:
>>> > Hi!
>>> >
>>> > I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail)
>>> > 1.0.1
>>> > Importante note: we previously voted for the spec part. This vote is
>>> > for the provider and the mail core.
>>> >
>>> > Here is the staging repo
>>> >
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1142
>>> >
>>> > And the source jar which is voted on
>>> >
>>> https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip
>>> >
>>> > Git tag
>>> >
>>> https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-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
>>>
>>
>>
>> --
>> Atentamente:
>> César Hernández.
>>
>
>
> --
> Atentamente:
> César Hernández.
>


-- 
Jean-Louis

[VOTE] geronimo-javamail_1.6_(provider|mail) 1.0.1

[Jean-Louis MONTEIRO]

Hi!

I’d like to call a VOTE on the geronimo-javamail_1.6_(provider|mail) 1.0.1
Importante note: we previously voted for the spec part. This vote is for
the provider and the mail core.

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


And the source jar which is voted on
https://dist.apache.org/repos/dist/dev/geronimo/javamail/geronimo-javamail_1.6-1.0.1-source-release.zip

Git tag
https://github.com/apache/geronimo-javamail/tree/geronimo-javamail_1.6-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

[RESULT][VOTE] geronimo-javamail_1.6_spec 1.0.1

[Jean-Louis MONTEIRO]

Hi!

Vote passes with 7 +1 and no other vote.
Jean-Baptiste (Binding), Romain (Binding), Richard, Jean-Louis (Binding),
Cesar, Raymond, François (Binding)

I'll proceed with the other steps
Thanks everyone


Le jeu. 7 oct. 2021 à 21:30, Jean-Louis MONTEIRO  a
écrit :

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


-- 
Jean-Louis

[jira] [Resolved] (GERONIMO-6800) MimeBodyPart.setText ignores subtype

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro resolved GERONIMO-6800.
---
Resolution: Fixed

> MimeBodyPart.setText ignores subtype
> 
>
> Key: GERONIMO-6800
> URL: https://issues.apache.org/jira/browse/GERONIMO-6800
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Argannor
>Assignee: Francois Papon
>Priority: Minor
> Fix For: Javamail_1.6_1.0.1
>
> Attachments: setText-subtype-ignored.patch
>
>
> Hi there,
> the following method from MimeBodyPart in geonimo-javamail_1.6_spec ignores 
> the parameter subtype, and always sets the mime type to text/plain.
> {code:java}
> public void setText(final String text, String charset, final String subtype)
> {code}
> I've written a small patch, including a test case. Please let me know if I 
> need to sign any legal documents to donate this code.
> Kind regards
>  



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

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

[Jean-Louis MONTEIRO]

I'm confused François.
The ticket seems to reference Geronimo javamail provider and mail.

This VOTE is for Geronimo Javamail specs.

Did specs all move to gitbox?

If so I'm sorry, I missed that information.

Le lun. 11 oct. 2021 à 17:49, Francois Papon 
a écrit :

> Here the new ticket:
>
> https://issues.apache.org/jira/browse/INFRA-22400
>
> regards,
>
> Françoisfpapon@apache.orgfrancois.pa...@openobject.fr
>
> Le 11/10/2021 à 17:41, Francois Papon a écrit :
>
> Hi,
>
> According to the ticket, Infra noticed that the repo was made in RO at the
> start of the migration process:
>
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-21908
>
> Let me re-open it.
>
> regards,
>
> Françoisfpapon@apache.orgfrancois.pa...@openobject.fr
>
> Le 11/10/2021 à 17:37, Romain Manni-Bucau a écrit :
>
> Outch, good catch, think we have to rollback and ask infra to make the svn
> read only.
>
> 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 lun. 11 oct. 2021 à 17:29, Francois Papon 
> a écrit :
>
>> Hi,
>>
>> I'm not sure to understand, we moved the source repository from svn to
>> gitbox for javamail so for me it's a -1.
>>
>> Can you do the release from gitbox?
>>
>> regards,
>>
>> Françoisfpapon@apache.orgfrancois.pa...@openobject.fr
>>
>> Le 07/10/2021 à 21:30, Jean-Louis MONTEIRO a écrit :
>>
>> 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
>>
>>

-- 
Jean-Louis

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

[Jean-Louis MONTEIRO]

+1

And yes I'll do provider and mail at the same time after. Wanted to get the
spec first and separately.

Le ven. 8 oct. 2021 à 15:08, Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> a écrit :

> +1 (downstream mail & provider would be great in terms of TLS 1.2+
> compatibility)
>
> Am Freitag, dem 08.10.2021 um 15:05 +0200 schrieb Romain Manni-Bucau:
> > +1 (I assume a follow up vote can be needed for
> >
> https://svn.apache.org/repos/asf/geronimo/javamail/trunk/geronimo-javamail_1.6/
> > to get it fully out the door? if you want you can run both at the
> > same time making downstream one dependent on this one ;))
> >
> > Romain Manni-Bucau
> > @rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book
> >
> >
> > Le ven. 8 oct. 2021 à 10:13, Jean-Baptiste Onofré  a
> > écrit :
> > > +1 (binding)
> > >
> > > Regards
> > > JB
> > >
> > > On 07/10/2021 21:30, Jean-Louis MONTEIRO wrote:
> > > > 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
> > > <
> > >
> 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
> > >
> > > > <
> > >
> 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/
> > >
> > > > <
> > >
> 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
> > > > <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
> --
> Richard Zowalla, M.Sc.
> Research Associate, PhD Student | Medical Informatics
>
> Hochschule Heilbronn – University of Applied Sciences
> Max-Planck-Str. 39
> D-74081 Heilbronn
> phone: +49 7131 504 6791 (zur Zeit nicht via Telefon erreichbar)
> mail: richard.zowa...@hs-heilbronn.de
> web: https://www.mi.hs-heilbronn.de/
>


-- 
Jean-Louis

[VOTE] geronimo-javamail_1.6_spec 1.0.1

[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

[jira] [Commented] (GERONIMO-6800) MimeBodyPart.setText ignores subtype

[Jean-Louis Monteiro (Jira)]

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

Jean-Louis Monteiro commented on GERONIMO-6800:
---

[~Argannor] can you please sign the iCLA and send it over to 
secret...@apache.org

> MimeBodyPart.setText ignores subtype
> 
>
> Key: GERONIMO-6800
> URL: https://issues.apache.org/jira/browse/GERONIMO-6800
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: specs
>Reporter: Argannor
>Assignee: Francois Papon
>Priority: Minor
> Fix For: Javamail_1.6_1.0.1
>
> Attachments: setText-subtype-ignored.patch
>
>
> Hi there,
> the following method from MimeBodyPart in geonimo-javamail_1.6_spec ignores 
> the parameter subtype, and always sets the mime type to text/plain.
> {code:java}
> public void setText(final String text, String charset, final String subtype)
> {code}
> I've written a small patch, including a test case. Please let me know if I 
> need to sign any legal documents to donate this code.
> Kind regards
>  



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

Re: [VOTE] Apache Bean 4.19 release

[Jean-Louis MONTEIRO]

+1

Le mar. 13 avr. 2021 à 07:00, Jean-Baptiste Onofre  a
écrit :

> Hi everyone,
>
> I submit XBean 4.19 to your vote.
>
> This release especially includes:
> - Upgrade to ASM 9.1
> - Fix a NPE when the superclass is not set in the bundle finder
> - Fix OSGi headers in asm9 shaded artifact
>
> Release Notes:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310312=12348824
>
> Maven Staging Repository:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1138/
>
> Dist Staging Repository:
> https://dist.apache.org/repos/dist/dev/geronimo/xbean/4.19/
>
> 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.
>
> Thanks !
> Regards
> JB
>


-- 
Jean-Louis

Re: Release XBean 4.19

[Jean-Louis MONTEIRO]

+1

Le sam. 10 avr. 2021 à 11:34, Romain Manni-Bucau  a
écrit :

> +1
>
> Le sam. 10 avr. 2021 à 08:17,  a écrit :
>
>> Hi JB,
>>
>> Sounds good to me.
>>
>> Regards,
>>
>> François
>> fpa...@apache.org
>>
>> Le 10/04/2021 à 07:12, Jean-Baptiste Onofre a écrit :
>> > Hi guys,
>> >
>> > As XBEAN-326 is impacting several projects (Pax Web, Karaf, ActiveMQ,
>> …), especially when using Jackson 2.12.x, I would like to release xbean
>> 4.19.
>> > I have some minor dependency updates but it’s ready: I tested
>> 4.19-SNAPSHOT and it fixes the NPE issue.
>> >
>> > No objection ?
>> >
>> > Thanks,
>> > Regards
>> > JB
>>
>

Re: [VOTE] Release geronimo-openapi-1.0.14

[Jean-Louis MONTEIRO]

+1

Le jeu. 3 déc. 2020 à 17:40, Romain Manni-Bucau  a
écrit :

> My own +1
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le lun. 30 nov. 2020 à 16:06, Daniel Dias Dos Santos <
> daniel.dias.analist...@gmail.com> a écrit :
>
>> +1
>>
>> On Mon, Nov 30, 2020, 11:10 Daniel Cunha  wrote:
>>
>>> +1
>>>
>>> Em seg., 30 de nov. de 2020 às 10:32, Francois Papon <
>>> francois.pa...@openobject.fr> escreveu:
>>>
 +1 (non-binding)

 regards,

 Françoisfpa...@apache.org

 Le 30/11/2020 à 11:53, Romain Manni-Bucau a écrit :

 Hi everyone,

 Here is the vote for Geronimo OpenAPI 1.0.14.
 Here is the changelog:

 1–4 of 4View in Issue Navigator
 
 P T Key Summary Assignee Status
 [image: Major] [image: Task] GERONIMO-6786
  Support
 @BeanParam  Romain
 Manni-Bucau
 
 RESOLVED
 [image: Major] [image: Bug] GERONIMO-6787
  openapi.json
 should land in META-INF/resources by default not META-INF/classes
  Romain
 Manni-Bucau
 
 RESOLVED
 [image: Major] [image: Task] GERONIMO-6788
  Make JAXRS
 optional for schema processor + support BigDecimal/BigInteger and Object
  Romain
 Manni-Bucau
 
 RESOLVED
 [image: Major] [image: New Feature] GERONIMO-6790
  Enable to use
 SchemaProcessor without jaxrs
  Romain
 Manni-Bucau
 
 RESOLVED
 1–4 of 4

 Here is the staging repo:
 https://repository.apache.org/content/repositories/orgapachegeronimo-1135/
 Here is the dist area:
 https://dist.apache.org/repos/dist/dev/geronimo/openapi/
 Here is the tag:
 https://gitbox.apache.org/repos/asf?p=geronimo-openapi.git;a=commit;h=ed7112a2fea3c38b1bbe80d7ff534a0af49fa619
 My key is the same than last times.

 Please vote:

 [ ] +1 release it
 [ ] -1 ${cause}

 Vote will be opened for 3 days or until we get 3 +1 bindings.

 Romain Manni-Bucau
 @rmannibucau  |  Blog
  | Old Blog
  | Github
  | LinkedIn
  | Book
 


>>>
>>> --
>>> Daniel "soro" Cunha
>>> https://twitter.com/dvlc_
>>>
>>

-- 
Jean-Louis

Fwd: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?

[Jean-Louis Monteiro]

If someone has an idea
--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


-- Forwarded message -
From: Jean-Louis Monteiro 
Date: Tue, Dec 1, 2020 at 12:16 PM
Subject: Re: Geronimo Java Mail 1.6 in TomEE 8.0.5 -> TLS 1.2 / 1.3 Support?
To: 


Hey Richard,

Thanks for the detailed email.
I have contributed recently to Geronimo Mail 1.6 but to be honest I can't
answer out of my head.

Cesar also worked on it, so he might be able to help.
Other than that, I'm CC'ing Geronimo mailing list. Maybe Romain and others
can help there.

Jean-Louis

--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com


On Tue, Dec 1, 2020 at 10:55 AM Zowalla, Richard <
richard.zowa...@hs-heilbronn.de> wrote:

> Hi all,
>
> I have updated our TomEE instances to 8.0.5 as (Geronimo) Java Mail 1.6
> replaced the rather outdated (Geronimo) Java Mail 1.4 in this release.
>
> Up to now, we were using
>
> 
> com.sun.mail
> jakarta.mail
> 1.6.5
> provided
> 
>
> as our mail server is configured to only support TLS 1.2 or TLS 1.3.
> These protocols were not supported by Java Mail 1.4.
>
> I recently tried to migrate to the provided Geronimo Java Mail 1.6
> hoping for better protocol support, but I get java.net.SocketException
> due to a javax.net.ssl.SSLHandshakeException with "Received fatal
> alert: protocol_version".
>
> The full stack trace and related debug output can be found here:
> https://gist.github.com/rzo1/64c23a1d9be752eadf36cf3e1c719ffa)
>
> The mail session is configured as follows:
>
> 
> 
> 
> mail.debug=true
> mail.transport.protocol=smtp
> mail.smtp.starttls.enable=true
> mail.smtp.starttls.required=true
> mail.smtp.ssl.enable=false
> mail.smtp.host=mail.mail-server.com
> mail.smtp.port=587
> mail.smtp.auth=true
> mail.smtp.user=d...@mail-server.com
> 
> password=fancyPassword
> 
> 
>
> Question:
>
> - Does anybody have an idea how to get Geronimo Java Mail 1.6 talking
> via TLS 1.2 or TLS 1.3 to our mail server?
>
> - Is TLS 1.2 / TLS 1.3 supported in Geronimo Java Mail 1.6?
>
> If this is the wrong list, please give me an advice which list would be
> a better fit.
>
> Thanks in advance,
> Richard Z
>
>
>
>