Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Emmanuel: tomee does not use tomcat-dbcp, it facade any JDBC pool library
with its own code so any managed package usage is really legacy since ~10
years.

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



Le lun. 19 juin 2023 à 14:18, Richard Zowalla  a écrit :

> David wrote something similar on the tomee dev@ list [1].
> So perhaps it would be worth to just provide a jakarta capable package?
>
> [1] https://lists.apache.org/thread/gkmrdlwo1gpbzogqvrdyq1zqqt6pompc
>
> Am Montag, dem 19.06.2023 um 14:09 +0200 schrieb Emmanuel Bourg:
> > On 26/05/2023 12:20, Romain Manni-Bucau wrote:
> >
> > > TomEE can drop managed package legacy dependency now, was kept
> > > while the
> > > replacement was in test in 1.x version but makes years it is no
> > > more
> > > relevant and no more the default (since we switched to tomcat-
> > > jdbc).
> > > So no big deal if dbcp wants to drop it on TomEE side IMHO.
> >
> > Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use
> > the
> > managed package from tomcat-jdbc? If so we can't simply drop this
> > package from DBCP.
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

David wrote something similar on the tomee dev@ list [1].
So perhaps it would be worth to just provide a jakarta capable package?

[1] https://lists.apache.org/thread/gkmrdlwo1gpbzogqvrdyq1zqqt6pompc

Am Montag, dem 19.06.2023 um 14:09 +0200 schrieb Emmanuel Bourg:
> On 26/05/2023 12:20, Romain Manni-Bucau wrote:
> 
> > TomEE can drop managed package legacy dependency now, was kept
> > while the
> > replacement was in test in 1.x version but makes years it is no
> > more
> > relevant and no more the default (since we switched to tomcat-
> > jdbc).
> > So no big deal if dbcp wants to drop it on TomEE side IMHO.
> 
> Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use
> the 
> managed package from tomcat-jdbc? If so we can't simply drop this 
> package from DBCP.
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

On 26/05/2023 12:20, Romain Manni-Bucau wrote:


TomEE can drop managed package legacy dependency now, was kept while the
replacement was in test in 1.x version but makes years it is no more
relevant and no more the default (since we switched to tomcat-jdbc).
So no big deal if dbcp wants to drop it on TomEE side IMHO.


Ok but tomcat-jdbc contains a modified copy of DBCP. Does TomEE use the 
managed package from tomcat-jdbc? If so we can't simply drop this 
package from DBCP.


Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Hey Romain,

thanks for the info regarding the historic back story ;)
So perhaps time to drop it, i will take that on the TomEE list.

Gruß
Richard

Am Freitag, dem 26.05.2023 um 12:20 +0200 schrieb Romain Manni-Bucau:
> Hi Richard,
> 
> TomEE can drop managed package legacy dependency now, was kept while
> the
> replacement was in test in 1.x version but makes years it is no more
> relevant and no more the default (since we switched to tomcat-jdbc).
> So no big deal if dbcp wants to drop it on TomEE side IMHO.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-perfor
> mance>
> 
> 
> Le ven. 26 mai 2023 à 12:19, Richard Zowalla  a
> écrit :
> 
> > The current TomEE codebase still uses classes from the "managed"
> > package of dbcp2. (Thus, we are shading it for TomEE 9 / 10)
> > 
> > We might be able to drop that integration at some point but
> > currently
> > our focus is on getting a EE10 milestone out of the door, so I
> > don't
> > think, that it is a theoretical issue.
> > 
> > Gruß
> > Richard
> > 
> > 
> > Am Freitag, dem 26.05.2023 um 12:08 +0200 schrieb Emmanuel Bourg:
> > > Le 11/05/2023 à 15:56, Richard Zowalla a écrit :
> > > > Hi,
> > > > 
> > > > do we have any updates?
> > > > 
> > > > How can I help to get a dbcp version supporting Jakarta
> > > > namespace?
> > > > 
> > > > Emmanuel outlined a possible appraoch. How can we move forward
> > > > with
> > > > it?
> > > 
> > > I'm tempted to merge the dual-javax-jakarta branch, but Romain's
> > > comment
> > > about TomEE no longer using the managed package made me wonder if
> > > we
> > > really need to bother at all.
> > > 
> > > Are we trying to fix a theoretical issue or are there actual
> > > users of
> > > these classes expecting a fix?
> > > 
> > > Emmanuel Bourg
> > > 
> > > 
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > 
> > 
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> > 



signature.asc
Description: This is a digitally signed message part

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Hi Richard,

TomEE can drop managed package legacy dependency now, was kept while the
replacement was in test in 1.x version but makes years it is no more
relevant and no more the default (since we switched to tomcat-jdbc).
So no big deal if dbcp wants to drop it on TomEE side IMHO.

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



Le ven. 26 mai 2023 à 12:19, Richard Zowalla  a écrit :

> The current TomEE codebase still uses classes from the "managed"
> package of dbcp2. (Thus, we are shading it for TomEE 9 / 10)
>
> We might be able to drop that integration at some point but currently
> our focus is on getting a EE10 milestone out of the door, so I don't
> think, that it is a theoretical issue.
>
> Gruß
> Richard
>
>
> Am Freitag, dem 26.05.2023 um 12:08 +0200 schrieb Emmanuel Bourg:
> > Le 11/05/2023 à 15:56, Richard Zowalla a écrit :
> > > Hi,
> > >
> > > do we have any updates?
> > >
> > > How can I help to get a dbcp version supporting Jakarta namespace?
> > >
> > > Emmanuel outlined a possible appraoch. How can we move forward with
> > > it?
> >
> > I'm tempted to merge the dual-javax-jakarta branch, but Romain's
> > comment
> > about TomEE no longer using the managed package made me wonder if we
> > really need to bother at all.
> >
> > Are we trying to fix a theoretical issue or are there actual users of
> > these classes expecting a fix?
> >
> > Emmanuel Bourg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

The current TomEE codebase still uses classes from the "managed"
package of dbcp2. (Thus, we are shading it for TomEE 9 / 10)

We might be able to drop that integration at some point but currently
our focus is on getting a EE10 milestone out of the door, so I don't
think, that it is a theoretical issue.

Gruß
Richard


Am Freitag, dem 26.05.2023 um 12:08 +0200 schrieb Emmanuel Bourg:
> Le 11/05/2023 à 15:56, Richard Zowalla a écrit :
> > Hi,
> > 
> > do we have any updates?
> > 
> > How can I help to get a dbcp version supporting Jakarta namespace?
> > 
> > Emmanuel outlined a possible appraoch. How can we move forward with
> > it?
> 
> I'm tempted to merge the dual-javax-jakarta branch, but Romain's
> comment 
> about TomEE no longer using the managed package made me wonder if we 
> really need to bother at all.
> 
> Are we trying to fix a theoretical issue or are there actual users of
> these classes expecting a fix?
> 
> Emmanuel Bourg
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

Le 11/05/2023 à 15:56, Richard Zowalla a écrit :

Hi,

do we have any updates?

How can I help to get a dbcp version supporting Jakarta namespace?

Emmanuel outlined a possible appraoch. How can we move forward with it?


I'm tempted to merge the dual-javax-jakarta branch, but Romain's comment 
about TomEE no longer using the managed package made me wonder if we 
really need to bother at all.


Are we trying to fix a theoretical issue or are there actual users of 
these classes expecting a fix?


Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Hi,

do we have any updates? 

How can I help to get a dbcp version supporting Jakarta namespace? 

Emmanuel outlined a possible appraoch. How can we move forward with it?

Thanks & Gruß
Richard


On 2022/12/30 12:52:45 Richard Zowalla wrote:
> Thanks a lot, Emmanuel! 
> 
> It looks good to me!
> 
> Gruß
> Richard
> 
> 
> Am Donnerstag, dem 29.12.2022 um 22:02 +0100 schrieb Emmanuel Bourg:
> > Thank you, it works perfectly now.
> > 
> > I've pushed the changes to:
> > 
> >  https://github.com/ebourg/commons-dbcp/tree/jakarta
> > 
> > Comments are welcome before I create a dbcp3 branch on the ASF
> > repository.
> > 
> > I think the API should be kept identical to dbcp2 to ease porting 
> > changes and facilitate migrations. So no removal of deprecated
> > methods 
> > before dbcp4.
> > 
> > Emmanuel Bourg
> > 
> > 
> > On 28/12/2022 19:22, Romain Manni-Bucau wrote:
> > > Hi Emmanuel,
> > > 
> > > You have
> > > https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
> > > which is usable if you exclude transitive deps.
> > > 
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Great news, Gary!

Very much appreciated.

Gruß
Richard

Am Donnerstag, dem 19.01.2023 um 06:11 -0500 schrieb Gary Gregory:
> Patience ;-) I am in the middle of releasing Commons Crypto. I can
> take a
> look this weekend and see what our options are...
> 
> Gary
> 
> On Thu, Jan 19, 2023, 04:42 Richard Zowalla  wrote:
> 
> > So what do we need to move forward with this once? :-)
> > 
> > Gruß
> > Richard
> > 
> > Am Sonntag, dem 01.01.2023 um 17:09 +0100 schrieb Jean-Baptiste
> > Onofré:
> > > It looks good to me.
> > > 
> > > Thanks,
> > > Regards
> > > JB
> > > 
> > > On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg <
> > > ebo...@apache.org>
> > > wrote:
> > > > I've experimented with another approach, a single version
> > > > supporting both javax.transaction and jakarta.transaction:
> > > > 
> > > >  
> > > > https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> > > > 
> > > > The only classes using javax.transaction are in the
> > > > org.apache.commons.dbcp2.managed
> > > > package. This package is copied at build time to
> > > > org.apache.commons.dbcp2.managed.jakarta
> > > > with the javax imports replaced.
> > > > 
> > > > This solution is easier than maintaining two versions is
> > > > parallel.
> > > > 
> > > > What do you think?
> > > > 
> > > > Emmanuel Bourg
> > > > 
> > > > -
> > > > 
> > > > 
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > 
> > > 
> > > ---
> > > --
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > 


signature.asc
Description: This is a digitally signed message part

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

Patience ;-) I am in the middle of releasing Commons Crypto. I can take a
look this weekend and see what our options are...

Gary

On Thu, Jan 19, 2023, 04:42 Richard Zowalla  wrote:

> So what do we need to move forward with this once? :-)
>
> Gruß
> Richard
>
> Am Sonntag, dem 01.01.2023 um 17:09 +0100 schrieb Jean-Baptiste Onofré:
> > It looks good to me.
> >
> > Thanks,
> > Regards
> > JB
> >
> > On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg 
> > wrote:
> > > I've experimented with another approach, a single version
> > > supporting both javax.transaction and jakarta.transaction:
> > >
> > >  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> > >
> > > The only classes using javax.transaction are in the
> > > org.apache.commons.dbcp2.managed
> > > package. This package is copied at build time to
> > > org.apache.commons.dbcp2.managed.jakarta
> > > with the javax imports replaced.
> > >
> > > This solution is easier than maintaining two versions is parallel.
> > >
> > > What do you think?
> > >
> > > Emmanuel Bourg
> > >
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

So what do we need to move forward with this once? :-)

Gruß
Richard

Am Sonntag, dem 01.01.2023 um 17:09 +0100 schrieb Jean-Baptiste Onofré:
> It looks good to me.
> 
> Thanks,
> Regards
> JB
> 
> On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg 
> wrote:
> > I've experimented with another approach, a single version
> > supporting both javax.transaction and jakarta.transaction:
> > 
> >  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> > 
> > The only classes using javax.transaction are in the
> > org.apache.commons.dbcp2.managed
> > package. This package is copied at build time to
> > org.apache.commons.dbcp2.managed.jakarta
> > with the javax imports replaced.
> > 
> > This solution is easier than maintaining two versions is parallel.
> > 
> > What do you think?
> > 
> > Emmanuel Bourg
> > 
> > -
> > 
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Jean-Baptiste Onofré]

It looks good to me.

Thanks,
Regards
JB

On Sat, Dec 31, 2022 at 12:15 PM Emmanuel Bourg  wrote:
>
> I've experimented with another approach, a single version
> supporting both javax.transaction and jakarta.transaction:
>
>  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
>
> The only classes using javax.transaction are in the 
> org.apache.commons.dbcp2.managed
> package. This package is copied at build time to 
> org.apache.commons.dbcp2.managed.jakarta
> with the javax imports replaced.
>
> This solution is easier than maintaining two versions is parallel.
>
> What do you think?
>
> Emmanuel Bourg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Sounds good to me. Ultilately this managed package could also disappear I
guess since it was mainly for geronimo and tomee which disappeared or dont
use it anymore.

Le sam. 31 déc. 2022 à 12:25, Richard Zowalla  a écrit :

> I guess, that it would need some tests to show, that it is working
> correctly? Otherwise it would raise similar concerns as for the PR
> using Maven Shading to achieve the transition.
>
> Gruß
> Richard
>
> P.S. Build is currently failing for that one.
>
>
> Am Samstag, dem 31.12.2022 um 12:15 +0100 schrieb Emmanuel Bourg:
> > I've experimented with another approach, a single version
> > supporting both javax.transaction and jakarta.transaction:
> >
> >  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> >
> > The only classes using javax.transaction are in the
> > org.apache.commons.dbcp2.managed
> > package. This package is copied at build time to
> > org.apache.commons.dbcp2.managed.jakarta
> > with the javax imports replaced.
> >
> > This solution is easier than maintaining two versions is parallel.
> >
> > What do you think?
> >
> > Emmanuel Bourg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

I guess, that it would need some tests to show, that it is working
correctly? Otherwise it would raise similar concerns as for the PR
using Maven Shading to achieve the transition. 

Gruß
Richard

P.S. Build is currently failing for that one.


Am Samstag, dem 31.12.2022 um 12:15 +0100 schrieb Emmanuel Bourg:
> I've experimented with another approach, a single version
> supporting both javax.transaction and jakarta.transaction:
> 
>  https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta
> 
> The only classes using javax.transaction are in the
> org.apache.commons.dbcp2.managed
> package. This package is copied at build time to
> org.apache.commons.dbcp2.managed.jakarta
> with the javax imports replaced.
> 
> This solution is easier than maintaining two versions is parallel.
> 
> What do you think?
> 
> Emmanuel Bourg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

I've experimented with another approach, a single version
supporting both javax.transaction and jakarta.transaction:

https://github.com/ebourg/commons-dbcp/tree/dual-javax-jakarta

The only classes using javax.transaction are in the 
org.apache.commons.dbcp2.managed
package. This package is copied at build time to 
org.apache.commons.dbcp2.managed.jakarta
with the javax imports replaced.

This solution is easier than maintaining two versions is parallel.

What do you think?

Emmanuel Bourg

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Thanks a lot, Emmanuel! 

It looks good to me!

Gruß
Richard


Am Donnerstag, dem 29.12.2022 um 22:02 +0100 schrieb Emmanuel Bourg:
> Thank you, it works perfectly now.
> 
> I've pushed the changes to:
> 
>  https://github.com/ebourg/commons-dbcp/tree/jakarta
> 
> Comments are welcome before I create a dbcp3 branch on the ASF
> repository.
> 
> I think the API should be kept identical to dbcp2 to ease porting 
> changes and facilitate migrations. So no removal of deprecated
> methods 
> before dbcp4.
> 
> Emmanuel Bourg
> 
> 
> On 28/12/2022 19:22, Romain Manni-Bucau wrote:
> > Hi Emmanuel,
> > 
> > You have
> > https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
> > which is usable if you exclude transitive deps.
> > 
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> > https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Le jeu. 29 déc. 2022 à 22:02, Emmanuel Bourg  a écrit :

> Thank you, it works perfectly now.
>
> I've pushed the changes to:
>
>  https://github.com/ebourg/commons-dbcp/tree/jakarta





>
> Comments are welcome before I create a dbcp3 branch on the ASF repository.
>
> I think the API should be kept identical to dbcp2 to ease porting
> changes and facilitate migrations. So no removal of deprecated methods
> before dbcp4.
>

If it helps: jakarta broke its api anyway so apps are rarely 1-1 so can be
the opportunity to do it anyway if you have changes in minds?


> Emmanuel Bourg
>
>
> On 28/12/2022 19:22, Romain Manni-Bucau wrote:
> > Hi Emmanuel,
> >
> > You have
> >
> https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
> > which is usable if you exclude transitive deps.
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

Thank you, it works perfectly now.

I've pushed the changes to:

https://github.com/ebourg/commons-dbcp/tree/jakarta

Comments are welcome before I create a dbcp3 branch on the ASF repository.

I think the API should be kept identical to dbcp2 to ease porting 
changes and facilitate migrations. So no removal of deprecated methods 
before dbcp4.


Emmanuel Bourg


On 28/12/2022 19:22, Romain Manni-Bucau wrote:

Hi Emmanuel,

You have
https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
which is usable if you exclude transitive deps.

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




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Hi Emmanuel,

You have
https://repo1.maven.org/maven2/org/apache/geronimo/components/geronimo-transaction/3.1.5/geronimo-transaction-3.1.5-jakarta.jar
which is usable if you exclude transitive deps.

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



Le mer. 28 déc. 2022 à 19:09, Emmanuel Bourg  a écrit :

> Thank you for the pointers, the Narayana and JBoss artifacts look good,
> but I haven't found a replacement for geronimo-transaction. I tried
> replacing the Geronimo Transaction implementation with the one from
> Narayana but got 4 test failures.
>
> I'll try to process the geronimo-transaction jar at build time and see
> how it works.
>
> Emmanuel Bourg
>
> Le 28/12/2022 à 07:24, Richard Zowalla a écrit :
> > There is a Jakarta artifact available for Narayana: narayana-jta-jakarta
> >
> > For the SPI: jboss-transaction-spi-jakarta
> >
> > (because JBoss plays the namespace game with their app server ;-) )
> >
> > Geronimo most likely also provides a Jakarta version or (if it is only
> API) can be replaced by the Jakarta artifact.
> >
> > Gruß
> > Richard
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

Thank you for the pointers, the Narayana and JBoss artifacts look good, 
but I haven't found a replacement for geronimo-transaction. I tried 
replacing the Geronimo Transaction implementation with the one from 
Narayana but got 4 test failures.


I'll try to process the geronimo-transaction jar at build time and see 
how it works.


Emmanuel Bourg

Le 28/12/2022 à 07:24, Richard Zowalla a écrit :

There is a Jakarta artifact available for Narayana: narayana-jta-jakarta

For the SPI: jboss-transaction-spi-jakarta

(because JBoss plays the namespace game with their app server ;-) )

Geronimo most likely also provides a Jakarta version or (if it is only API) can 
be replaced by the Jakarta artifact.

Gruß
Richard




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Gary as mentionned there are matches but also notice several vendors
(most) abandonned the game due to the new governance so dont expect as much
choices as before.

Le mer. 28 déc. 2022 à 07:24, Richard Zowalla  a
écrit :

> There is a Jakarta artifact available for Narayana: narayana-jta-jakarta
>
> For the SPI: jboss-transaction-spi-jakarta
>
> (because JBoss plays the namespace game with their app server ;-) )
>
> Geronimo most likely also provides a Jakarta version or (if it is only
> API) can be replaced by the Jakarta artifact.
>
> Gruß
> Richard
>
>
> Am 27. Dezember 2022 22:54:40 MEZ schrieb Romain Manni-Bucau <
> rmannibu...@gmail.com>:
>>
>> @Emmanuel Bourg  you can use jakarta artifacts directly
>> for dbcp or tomee ones which provides jakarta namespace.
>>
>> Le mar. 27 déc. 2022 à 22:28, Emmanuel Bourg  a écrit :
>>
>>  I tried to replace javax with jakarta in DBCP, the less trivial part is
>>>  to find a replacement for the test dependencies:
>>>  - org.apache.geronimo.modules:geronimo-transaction
>>>  - org.jboss.narayana.jta:narayana-jta
>>>  - and maybe org.jboss:jboss-transaction-spi
>>>
>>>  Or we disable the transaction tests temporarily to publish quickly a
>>>  Jakarta variant.
>>>
>>>  Emmanuel Bourg
>>> --
>>>  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>  For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

There is a Jakarta artifact available for Narayana: narayana-jta-jakarta

For the SPI: jboss-transaction-spi-jakarta

(because JBoss plays the namespace game with their app server ;-) )

Geronimo most likely also provides a Jakarta version or (if it is only API) can 
be replaced by the Jakarta artifact.

Gruß
Richard 


Am 27. Dezember 2022 22:54:40 MEZ schrieb Romain Manni-Bucau 
:
>@Emmanuel Bourg  you can use jakarta artifacts directly
>for dbcp or tomee ones which provides jakarta namespace.
>
>Le mar. 27 déc. 2022 à 22:28, Emmanuel Bourg  a écrit :
>
>> I tried to replace javax with jakarta in DBCP, the less trivial part is
>> to find a replacement for the test dependencies:
>> - org.apache.geronimo.modules:geronimo-transaction
>> - org.jboss.narayana.jta:narayana-jta
>> - and maybe org.jboss:jboss-transaction-spi
>>
>> Or we disable the transaction tests temporarily to publish quickly a
>> Jakarta variant.
>>
>> Emmanuel Bourg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

There is non point in doing this "quickly", if there is no match in the
namespace game for the test dependencies, it only goes to prove that the
whole ecosystem has not progressed far enough or is mature enough.

Gary

On Tue, Dec 27, 2022, 16:28 Emmanuel Bourg  wrote:

> I tried to replace javax with jakarta in DBCP, the less trivial part is
> to find a replacement for the test dependencies:
> - org.apache.geronimo.modules:geronimo-transaction
> - org.jboss.narayana.jta:narayana-jta
> - and maybe org.jboss:jboss-transaction-spi
>
> Or we disable the transaction tests temporarily to publish quickly a
> Jakarta variant.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@Emmanuel Bourg  you can use jakarta artifacts directly
for dbcp or tomee ones which provides jakarta namespace.

Le mar. 27 déc. 2022 à 22:28, Emmanuel Bourg  a écrit :

> I tried to replace javax with jakarta in DBCP, the less trivial part is
> to find a replacement for the test dependencies:
> - org.apache.geronimo.modules:geronimo-transaction
> - org.jboss.narayana.jta:narayana-jta
> - and maybe org.jboss:jboss-transaction-spi
>
> Or we disable the transaction tests temporarily to publish quickly a
> Jakarta variant.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Emmanuel Bourg]

I tried to replace javax with jakarta in DBCP, the less trivial part is 
to find a replacement for the test dependencies:

- org.apache.geronimo.modules:geronimo-transaction
- org.jboss.narayana.jta:narayana-jta
- and maybe org.jboss:jboss-transaction-spi

Or we disable the transaction tests temporarily to publish quickly a 
Jakarta variant.


Emmanuel Bourg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

@Gary: I agree with the plan but as Romain outlined, it requires some
details / perspective.

Am Montag, dem 19.12.2022 um 21:33 +0100 schrieb Romain Manni-Bucau:
> @gary: you likely need to refine your plan to make it a plan and not
> a
> discussion proposal, ie put some date. If you want to release dbcp2
> this
> year and move to dbcp3 in january for a 1.0.0 (or whatever version)
> in
> early february I guess it works for everyone. If it is about waiting
> 1-2
> months to get 2 out, 3-4 months to get 3 out it means we loose one
> more
> year in terms of adoption and I guess we would be closer to my point
> that
> dbcp will never met jakarta as of today where hikaricp and tomcat-
> jdbc are
> used by default when upgrading stacks since jakarta adoption will
> accelerate next year with spring 6 hard move and related migrations.
> If it
> is the kind of time frame I guess the relocation - shade or tomcat
> tool -
> will be a better option for commons and the project (it is the option
> geronimo/openwebbeans/meecrowave/tomee adopted with success to ensure
> a
> single branch was to maintain before the final switch which should
> occur
> when javax branch is definitively dead for end users - should happen
> in a
> few years, maybe 2-3 due to first jakarta release time and usual
> adoption
> rate).
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-perfor
> mance>
> 
> 
> Le lun. 19 déc. 2022 à 21:23, Gary Gregory  a
> écrit :
> 
> > I feel like we're going around in circles. Do you not agree my the
> > path I previously outlined?
> > 
> > Gary
> > 
> > On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla 
> > wrote:
> > > 
> > > I can only say, that I fully agree with Romain here.
> > > 
> > > For example, we are shading dbcp2 with jakarta.* relocations in
> > > TomEE 9
> > (targeting EE9.1 / jakarta.*). I don't think, that it is a good
> > thing to
> > let the users fork/relocate or abandon dbcp2 in order to be able to
> > use the
> > jakarta.* namespace.
> > > 
> > > The EE ecosystem is moving and if we want to play a role in it,
> > > we need
> > to adapt a bit. That said, it isn't a huge effort to migrate /
> > create a
> > version to support jakarta.*
> > > 
> > > IMHO it is only a matter of available resources / time and
> > people/volunteers who want to contribute / help to make it happen.
> > If it
> > requires to make a dbcp3 due to commons rule set (binary compat)
> > and
> > relocation isn't an option, so be it.
> > > 
> > > Nevertheless, I would appreciate some perspective, so we can deal
> > > with
> > it on our side :-) (and as already said: I am happy to help /
> > contribute,
> > if needed)
> > > 
> > > Gruß
> > > Richard
> > > 
> > > 
> > > 
> > > On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> > > > Le dim. 18 déc. 2022 à 12:04, Gary Gregory
> > > >  a
> > > > écrit :
> > > > 
> > > > > What's the rush? Commons has never been on the bleeding edge
> > > > > of
> > anything.
> > > > > 
> > > > 
> > > > 
> > > > Java and EE release rates changed - as well as spring baseline.
> > > > If
> > commons
> > > > sticks to the old one it is harder (impossible) to use
> > > > directly.
> > > > Today dbcp is either forked/relocated or abandonned for that
> > > > reason so
> > > > guess we should either adapt the release rate and testing
> > > > coverage to
> > these
> > > > changes or freeze the project if it is no more matching end
> > > > users envs.
> > > > 
> > > > 
> > > > You saw the plan I proposed I presume.
> > > > > 
> > > > 
> > > > Yep but with no (even vague) date it does not mean much to me,
> > > > just "we
> > > > dont care of last two majors of EE" until something happens.
> > > > This is why I ask what does mean a little and when dbcp3 would
> > > > be a
> > thing.
> > > > Would also be important to document it and maybe recommend
> > > > tomcat-jdbc
> > for
> > > > user until we support jakarta.
> > > > 
> > > > 
> > > > 
> > > > > Gary
> > > > > 
> > > > > 
> > > > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau <
> > rmannibu...@gmail.com>
> > > > > wrote:
> > > > > 
> > > > > > Any idea on when it can occurs? We are quite late to the
> > > > > > party
> > already
> > > > > and
> > > > > > shade was a good solution to be in without additional cost
> > > > > > in
> > terms of
> > > > > > maintainance for the project so if not the picked option we
> > > > > > should
> > target
> > > > > > some point not too far in 2023 pby.
> > > > > > 
> > > > > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory
> > > > > > 
> > a
> > > > > > écrit :
> > > > > > 
> > > > > > > Hi Arun,
> > > > > > > 
> > > > > > > There's not going to be anything to pick up for a while
> > > > > > > ;-)
> > > > > > > 
> > > > > > > Gary

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

@gary: you likely need to refine your plan to make it a plan and not a
discussion proposal, ie put some date. If you want to release dbcp2 this
year and move to dbcp3 in january for a 1.0.0 (or whatever version) in
early february I guess it works for everyone. If it is about waiting 1-2
months to get 2 out, 3-4 months to get 3 out it means we loose one more
year in terms of adoption and I guess we would be closer to my point that
dbcp will never met jakarta as of today where hikaricp and tomcat-jdbc are
used by default when upgrading stacks since jakarta adoption will
accelerate next year with spring 6 hard move and related migrations. If it
is the kind of time frame I guess the relocation - shade or tomcat tool -
will be a better option for commons and the project (it is the option
geronimo/openwebbeans/meecrowave/tomee adopted with success to ensure a
single branch was to maintain before the final switch which should occur
when javax branch is definitively dead for end users - should happen in a
few years, maybe 2-3 due to first jakarta release time and usual adoption
rate).

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



Le lun. 19 déc. 2022 à 21:23, Gary Gregory  a
écrit :

> I feel like we're going around in circles. Do you not agree my the
> path I previously outlined?
>
> Gary
>
> On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla  wrote:
> >
> > I can only say, that I fully agree with Romain here.
> >
> > For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9
> (targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to
> let the users fork/relocate or abandon dbcp2 in order to be able to use the
> jakarta.* namespace.
> >
> > The EE ecosystem is moving and if we want to play a role in it, we need
> to adapt a bit. That said, it isn't a huge effort to migrate / create a
> version to support jakarta.*
> >
> > IMHO it is only a matter of available resources / time and
> people/volunteers who want to contribute / help to make it happen. If it
> requires to make a dbcp3 due to commons rule set (binary compat) and
> relocation isn't an option, so be it.
> >
> > Nevertheless, I would appreciate some perspective, so we can deal with
> it on our side :-) (and as already said: I am happy to help / contribute,
> if needed)
> >
> > Gruß
> > Richard
> >
> >
> >
> > On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> > > Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
> > > écrit :
> > >
> > > > What's the rush? Commons has never been on the bleeding edge of
> anything.
> > > >
> > >
> > >
> > > Java and EE release rates changed - as well as spring baseline. If
> commons
> > > sticks to the old one it is harder (impossible) to use directly.
> > > Today dbcp is either forked/relocated or abandonned for that reason so
> > > guess we should either adapt the release rate and testing coverage to
> these
> > > changes or freeze the project if it is no more matching end users envs.
> > >
> > >
> > > You saw the plan I proposed I presume.
> > > >
> > >
> > > Yep but with no (even vague) date it does not mean much to me, just "we
> > > dont care of last two majors of EE" until something happens.
> > > This is why I ask what does mean a little and when dbcp3 would be a
> thing.
> > > Would also be important to document it and maybe recommend tomcat-jdbc
> for
> > > user until we support jakarta.
> > >
> > >
> > >
> > > > Gary
> > > >
> > > >
> > > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Any idea on when it can occurs? We are quite late to the party
> already
> > > > and
> > > > > shade was a good solution to be in without additional cost in
> terms of
> > > > > maintainance for the project so if not the picked option we should
> target
> > > > > some point not too far in 2023 pby.
> > > > >
> > > > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory 
> a
> > > > > écrit :
> > > > >
> > > > > > Hi Arun,
> > > > > >
> > > > > > There's not going to be anything to pick up for a while ;-)
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan <
> arun.avanat...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can
> take it
> > > > > up.
> > > > > > >
> > > > > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla <
> rich...@zowalla.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Sure. Sounds like a plan :)
> > > > > > > >
> > > > > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > > > > garydgreg...@gmail.com>:
> > > > > > > >> I think we should wait for a little while: I'd want to
> release
> > > > > current
> > > > > > 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

I feel like we're going around in circles. Do you not agree my the
path I previously outlined?

Gary

On Mon, Dec 19, 2022 at 2:12 PM Richard Zowalla  wrote:
>
> I can only say, that I fully agree with Romain here.
>
> For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9 
> (targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to let 
> the users fork/relocate or abandon dbcp2 in order to be able to use the 
> jakarta.* namespace.
>
> The EE ecosystem is moving and if we want to play a role in it, we need to 
> adapt a bit. That said, it isn't a huge effort to migrate / create a version 
> to support jakarta.*
>
> IMHO it is only a matter of available resources / time and people/volunteers 
> who want to contribute / help to make it happen. If it requires to make a 
> dbcp3 due to commons rule set (binary compat) and relocation isn't an option, 
> so be it.
>
> Nevertheless, I would appreciate some perspective, so we can deal with it on 
> our side :-) (and as already said: I am happy to help / contribute, if needed)
>
> Gruß
> Richard
>
>
>
> On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> > Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
> > écrit :
> >
> > > What's the rush? Commons has never been on the bleeding edge of anything.
> > >
> >
> >
> > Java and EE release rates changed - as well as spring baseline. If commons
> > sticks to the old one it is harder (impossible) to use directly.
> > Today dbcp is either forked/relocated or abandonned for that reason so
> > guess we should either adapt the release rate and testing coverage to these
> > changes or freeze the project if it is no more matching end users envs.
> >
> >
> > You saw the plan I proposed I presume.
> > >
> >
> > Yep but with no (even vague) date it does not mean much to me, just "we
> > dont care of last two majors of EE" until something happens.
> > This is why I ask what does mean a little and when dbcp3 would be a thing.
> > Would also be important to document it and maybe recommend tomcat-jdbc for
> > user until we support jakarta.
> >
> >
> >
> > > Gary
> > >
> > >
> > > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
> > > wrote:
> > >
> > > > Any idea on when it can occurs? We are quite late to the party already
> > > and
> > > > shade was a good solution to be in without additional cost in terms of
> > > > maintainance for the project so if not the picked option we should 
> > > > target
> > > > some point not too far in 2023 pby.
> > > >
> > > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> > > > écrit :
> > > >
> > > > > Hi Arun,
> > > > >
> > > > > There's not going to be anything to pick up for a while ;-)
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > > > > wrote:
> > > > >
> > > > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> > > > up.
> > > > > >
> > > > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > > > > wrote:
> > > > > > >
> > > > > > > Sure. Sounds like a plan :)
> > > > > > >
> > > > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > > > garydgreg...@gmail.com>:
> > > > > > >> I think we should wait for a little while: I'd want to release
> > > > current
> > > > > > code
> > > > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> > > > make
> > > > > > sure
> > > > > > >> all is well, then see about going to DBCP 3, on Java 8 for now 
> > > > > > >> but
> > > > > > >> considering Java 11 maybe. Do consider that the Commons community
> > > is
> > > > > > small
> > > > > > >> and I would not want to support concurrent support and releases 
> > > > > > >> on
> > > > > bothe
> > > > > > >> DBCP 2 and 3.
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > > > > >> Gary
> > > > > > >>
> > > > > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> > > > wrote:
> > > > > > >>>
> > > > > > >>> For DBCP, it basically boils down to
> > > > > > >>>
> > > > > > >>> BasicManagedDataSource.java
> > > > > > >>> DataSourceXAConnectionFactory.java
> > > > > > >>> LocalXAConnectionFactory.java
> > > > > > >>> SynchronizationAdapter.java
> > > > > > >>> TransactionContext.java
> > > > > > >>> TransactionRegistry.java
> > > > > > >>>
> > > > > > >>> Looking at these classes, the move to jakarta definitley affects
> > > > > binary
> > > > > > >>> compatibility as we have changes in return types / arguments of
> > > > > public
> > > > > > >>> methods. Given that it breaks binary compatibility, we could 
> > > > > > >>> even
> > > > > > >>> increase the java level to 11 and drop deprecated things in a
> > > > > potential
> > > > > > >>> dbcp 3.
> > > > > > >>>
> > > > > > >>> In the end, I am happy with everything, which brings DBCP into
> > > the
> > > > > > >>> Jakarta world ;)
> > > > > > >>>
> > > > > > >>> If we have consensus for a route, I am happy to work on it / 
> > > > > > >>> make
> > > > it
> > > > > > >>> happen via related PRs but would need some 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

I can only say, that I fully agree with Romain here.

For example, we are shading dbcp2 with jakarta.* relocations in TomEE 9 
(targeting EE9.1 / jakarta.*). I don't think, that it is a good thing to let 
the users fork/relocate or abandon dbcp2 in order to be able to use the 
jakarta.* namespace.

The EE ecosystem is moving and if we want to play a role in it, we need to 
adapt a bit. That said, it isn't a huge effort to migrate / create a version to 
support jakarta.* 

IMHO it is only a matter of available resources / time and people/volunteers 
who want to contribute / help to make it happen. If it requires to make a dbcp3 
due to commons rule set (binary compat) and relocation isn't an option, so be 
it. 

Nevertheless, I would appreciate some perspective, so we can deal with it on 
our side :-) (and as already said: I am happy to help / contribute, if needed)

Gruß
Richard

 

On 2022/12/18 16:08:57 Romain Manni-Bucau wrote:
> Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
> écrit :
> 
> > What's the rush? Commons has never been on the bleeding edge of anything.
> >
> 
> 
> Java and EE release rates changed - as well as spring baseline. If commons
> sticks to the old one it is harder (impossible) to use directly.
> Today dbcp is either forked/relocated or abandonned for that reason so
> guess we should either adapt the release rate and testing coverage to these
> changes or freeze the project if it is no more matching end users envs.
> 
> 
> You saw the plan I proposed I presume.
> >
> 
> Yep but with no (even vague) date it does not mean much to me, just "we
> dont care of last two majors of EE" until something happens.
> This is why I ask what does mean a little and when dbcp3 would be a thing.
> Would also be important to document it and maybe recommend tomcat-jdbc for
> user until we support jakarta.
> 
> 
> 
> > Gary
> >
> >
> > On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
> > wrote:
> >
> > > Any idea on when it can occurs? We are quite late to the party already
> > and
> > > shade was a good solution to be in without additional cost in terms of
> > > maintainance for the project so if not the picked option we should target
> > > some point not too far in 2023 pby.
> > >
> > > Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> > > écrit :
> > >
> > > > Hi Arun,
> > > >
> > > > There's not going to be anything to pick up for a while ;-)
> > > >
> > > > Gary
> > > >
> > > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > > > wrote:
> > > >
> > > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> > > up.
> > > > >
> > > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > > > wrote:
> > > > > >
> > > > > > Sure. Sounds like a plan :)
> > > > > >
> > > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > > garydgreg...@gmail.com>:
> > > > > >> I think we should wait for a little while: I'd want to release
> > > current
> > > > > code
> > > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> > > make
> > > > > sure
> > > > > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > > > > >> considering Java 11 maybe. Do consider that the Commons community
> > is
> > > > > small
> > > > > >> and I would not want to support concurrent support and releases on
> > > > bothe
> > > > > >> DBCP 2 and 3.
> > > > > >>
> > > > > >> Gary
> > > > > >>
> > > > > >> Gary
> > > > > >>
> > > > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> > > wrote:
> > > > > >>>
> > > > > >>> For DBCP, it basically boils down to
> > > > > >>>
> > > > > >>> BasicManagedDataSource.java
> > > > > >>> DataSourceXAConnectionFactory.java
> > > > > >>> LocalXAConnectionFactory.java
> > > > > >>> SynchronizationAdapter.java
> > > > > >>> TransactionContext.java
> > > > > >>> TransactionRegistry.java
> > > > > >>>
> > > > > >>> Looking at these classes, the move to jakarta definitley affects
> > > > binary
> > > > > >>> compatibility as we have changes in return types / arguments of
> > > > public
> > > > > >>> methods. Given that it breaks binary compatibility, we could even
> > > > > >>> increase the java level to 11 and drop deprecated things in a
> > > > potential
> > > > > >>> dbcp 3.
> > > > > >>>
> > > > > >>> In the end, I am happy with everything, which brings DBCP into
> > the
> > > > > >>> Jakarta world ;)
> > > > > >>>
> > > > > >>> If we have consensus for a route, I am happy to work on it / make
> > > it
> > > > > >>> happen via related PRs but would need some guideance on the best
> > > way
> > > > to
> > > > > >>> move forward.
> > > > > >>>
> > > > > >>> Gruß
> > > > > >>> Richard
> > > > > >>>
> > > > > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain
> > > Manni-Bucau:
> > > > >  If not done in new classes (both can live in the same lib
> > > > >  technically),
> > > > >  sadly yes.
> > > > > 
> > > > >  Le ven. 16 déc. 2022 à 20:14, Richard Zowalla <
> > > rich...@zowalla.com>
> > > > a
> > > > > 

Re: Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Le lun. 19 déc. 2022 à 16:25, Eric Bresie  a écrit :

> I’ve not used it so not sure but would this help any in migrating the
> namespace?
>
> https://github.com/apache/tomcat-jakartaee-migration


It is strictly equivalent to the shade option but requires maven build
helper plugin to attach the relocated artifact so not sure since we fall in
the same option categories.


>
>
> Eric Bresie
> ebre...@gmail.com (mailto:ebre...@gmail.com)
>
> > On December 17, 2022 at 3:08:47 PM CST, Richard Zowalla <
> rich...@zowalla.com (mailto:rich...@zowalla.com)> wrote:
> > Sure. Sounds like a plan :)
> >
> > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> garydgreg...@gmail.com (mailto:garydgreg...@gmail.com)>:
> > > I think we should wait for a little while: I'd want to release current
> code
> > > from git for Commons Pool, then DBCP (which sits on top of Pool), make
> sure
> > > all is well, then see about going to DBCP 3, on Java 8 for now but
> > > considering Java 11 maybe. Do consider that the Commons community is
> small
> > > and I would not want to support concurrent support and releases on
> bothe
> > > DBCP 2 and 3.
> > >
> > > Gary
> > >
> > > Gary
> > >
> > > On Sat, Dec 17, 2022, 14:12 Richard Zowalla  r...@apache.org)> wrote:
> > >
> > > > For DBCP, it basically boils down to
> > > >
> > > > BasicManagedDataSource.java
> > > > DataSourceXAConnectionFactory.java
> > > > LocalXAConnectionFactory.java
> > > > SynchronizationAdapter.java
> > > > TransactionContext.java
> > > > TransactionRegistry.java
> > > >
> > > > Looking at these classes, the move to jakarta definitley affects
> binary
> > > > compatibility as we have changes in return types / arguments of
> public
> > > > methods. Given that it breaks binary compatibility, we could even
> > > > increase the java level to 11 and drop deprecated things in a
> potential
> > > > dbcp 3.
> > > >
> > > > In the end, I am happy with everything, which brings DBCP into the
> > > > Jakarta world ;)
> > > >
> > > > If we have consensus for a route, I am happy to work on it / make it
> > > > happen via related PRs but would need some guideance on the best way
> to
> > > > move forward.
> > > >
> > > > Gruß
> > > > Richard
> > > >
> > > > Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > > > > If not done in new classes (both can live in the same lib
> > > > > technically),
> > > > > sadly yes.
> > > > >
> > > > > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  (mailto:rich...@zowalla.com)> a
> > > > > écrit :
> > > > >
> > > > > > Thanks for your replies.
> > > > > >
> > > > > > I guess, that switching the namespace leads to binary
> > > > > > incompatibility (If
> > > > > > I take the definition from [1]). I cannot drop it in a running
> JVM
> > > > > > / app
> > > > > > and expect no issues with it as the related APIs are breaking
> > > > > > namespace
> > > > > > changes (at least at runtime if they aren't present) :-)
> > > > > >
> > > > > > Aside from that fact, method signatures might also change from
> > > > > > javax ->
> > > > > > jakarta, which would require a short investigation and usage of
> the
> > > > > > existing tooling to see if this happens.
> > > > > >
> > > > > > From a commons point of view that would mean to go for dbcp3,
> > > > > > right?
> > > > > >
> > > > > > Gruß
> > > > > > Richard
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > > > >
> > > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > > > mailto:ma...@apache.org)>:
> > > > > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > > > > Thank you Richard for starting this thread.
> > > > > > > >
> > > > > > > > My view is simpler perhaps: I would not make this about the
> > > > > > > > javax vs
> > > > > > > > Jakarta namespaces.
> > > > > > > >
> > > > > > > > I don't want to double the numbers of jars we produce from
> the
> > > > > > > > same
> > > > > > branch
> > > > > > > > for affected components as one of the scheme proposed. It
> feels
> > > > > > > > like a
> > > > > > > > burden to maintenance moving forward and a very brittle
> process
> > > > > > > > with
> > > > > > some
> > > > > > > > unforeseen side effects.
> > > > > > > >
> > > > > > > > This is just a code change IMO. For a given component, either
> > > > > > > > it is
> > > > > > binary
> > > > > > > > compatible, or it is not. You don't know until you try it and
> > > > > > > > see if
> > > > > > public
> > > > > > > > and protected elements break, using our existing
> configuration
> > > > > > > > of Maven
> > > > > > and
> > > > > > > > japicmp (or revapi).
> > > > > > > >
> > > > > > > > If it is binary compatible, then let's consider making the
> > > > > > > > change. If
> > > > > > not,
> > > > > > > > then do it in a major version, where the previous major
> version
> > > > > > > > is
> > > > > > > > maintained as we do now, as need be.
> > > > > 

Re: Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Eric Bresie]

I’ve not used it so not sure but would this help any in migrating the namespace?

https://github.com/apache/tomcat-jakartaee-migration

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 17, 2022 at 3:08:47 PM CST, Richard Zowalla  (mailto:rich...@zowalla.com)> wrote:
> Sure. Sounds like a plan :)
>
> Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory 
> mailto:garydgreg...@gmail.com)>:
> > I think we should wait for a little while: I'd want to release current code
> > from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
> > all is well, then see about going to DBCP 3, on Java 8 for now but
> > considering Java 11 maybe. Do consider that the Commons community is small
> > and I would not want to support concurrent support and releases on bothe
> > DBCP 2 and 3.
> >
> > Gary
> >
> > Gary
> >
> > On Sat, Dec 17, 2022, 14:12 Richard Zowalla  > (mailto:r...@apache.org)> wrote:
> >
> > > For DBCP, it basically boils down to
> > >
> > > BasicManagedDataSource.java
> > > DataSourceXAConnectionFactory.java
> > > LocalXAConnectionFactory.java
> > > SynchronizationAdapter.java
> > > TransactionContext.java
> > > TransactionRegistry.java
> > >
> > > Looking at these classes, the move to jakarta definitley affects binary
> > > compatibility as we have changes in return types / arguments of public
> > > methods. Given that it breaks binary compatibility, we could even
> > > increase the java level to 11 and drop deprecated things in a potential
> > > dbcp 3.
> > >
> > > In the end, I am happy with everything, which brings DBCP into the
> > > Jakarta world ;)
> > >
> > > If we have consensus for a route, I am happy to work on it / make it
> > > happen via related PRs but would need some guideance on the best way to
> > > move forward.
> > >
> > > Gruß
> > > Richard
> > >
> > > Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > > > If not done in new classes (both can live in the same lib
> > > > technically),
> > > > sadly yes.
> > > >
> > > > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  > > > (mailto:rich...@zowalla.com)> a
> > > > écrit :
> > > >
> > > > > Thanks for your replies.
> > > > >
> > > > > I guess, that switching the namespace leads to binary
> > > > > incompatibility (If
> > > > > I take the definition from [1]). I cannot drop it in a running JVM
> > > > > / app
> > > > > and expect no issues with it as the related APIs are breaking
> > > > > namespace
> > > > > changes (at least at runtime if they aren't present) :-)
> > > > >
> > > > > Aside from that fact, method signatures might also change from
> > > > > javax ->
> > > > > jakarta, which would require a short investigation and usage of the
> > > > > existing tooling to see if this happens.
> > > > >
> > > > > From a commons point of view that would mean to go for dbcp3,
> > > > > right?
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > >
> > > > > [1]
> > > > >
> > > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > > >
> > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > > mailto:ma...@apache.org)>:
> > > > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > > > Thank you Richard for starting this thread.
> > > > > > >
> > > > > > > My view is simpler perhaps: I would not make this about the
> > > > > > > javax vs
> > > > > > > Jakarta namespaces.
> > > > > > >
> > > > > > > I don't want to double the numbers of jars we produce from the
> > > > > > > same
> > > > > branch
> > > > > > > for affected components as one of the scheme proposed. It feels
> > > > > > > like a
> > > > > > > burden to maintenance moving forward and a very brittle process
> > > > > > > with
> > > > > some
> > > > > > > unforeseen side effects.
> > > > > > >
> > > > > > > This is just a code change IMO. For a given component, either
> > > > > > > it is
> > > > > binary
> > > > > > > compatible, or it is not. You don't know until you try it and
> > > > > > > see if
> > > > > public
> > > > > > > and protected elements break, using our existing configuration
> > > > > > > of Maven
> > > > > and
> > > > > > > japicmp (or revapi).
> > > > > > >
> > > > > > > If it is binary compatible, then let's consider making the
> > > > > > > change. If
> > > > > not,
> > > > > > > then do it in a major version, where the previous major version
> > > > > > > is
> > > > > > > maintained as we do now, as need be.
> > > > > > >
> > > > > > > A new major version also benefits from the usual dropping of
> > > > > > > deprecated
> > > > > > > elements and making any other changes with seem reasonable.
> > > > > >
> > > > > > +1. I don't see this as any different to increasing the minimum
> > > > > > version
> > > > > of Java and supported new JDBC methods.
> > > > > >
> > > > > > Mark
> > > > > >
> > > > > > -
> > > > > > 
> > > > > > To unsubscribe, e-mail: 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Le dim. 18 déc. 2022 à 12:04, Gary Gregory  a
écrit :

> What's the rush? Commons has never been on the bleeding edge of anything.
>


Java and EE release rates changed - as well as spring baseline. If commons
sticks to the old one it is harder (impossible) to use directly.
Today dbcp is either forked/relocated or abandonned for that reason so
guess we should either adapt the release rate and testing coverage to these
changes or freeze the project if it is no more matching end users envs.


You saw the plan I proposed I presume.
>

Yep but with no (even vague) date it does not mean much to me, just "we
dont care of last two majors of EE" until something happens.
This is why I ask what does mean a little and when dbcp3 would be a thing.
Would also be important to document it and maybe recommend tomcat-jdbc for
user until we support jakarta.



> Gary
>
>
> On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
> wrote:
>
> > Any idea on when it can occurs? We are quite late to the party already
> and
> > shade was a good solution to be in without additional cost in terms of
> > maintainance for the project so if not the picked option we should target
> > some point not too far in 2023 pby.
> >
> > Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> > écrit :
> >
> > > Hi Arun,
> > >
> > > There's not going to be anything to pick up for a while ;-)
> > >
> > > Gary
> > >
> > > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > > wrote:
> > >
> > > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> > up.
> > > >
> > > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > > wrote:
> > > > >
> > > > > Sure. Sounds like a plan :)
> > > > >
> > > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > > garydgreg...@gmail.com>:
> > > > >> I think we should wait for a little while: I'd want to release
> > current
> > > > code
> > > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> > make
> > > > sure
> > > > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > > > >> considering Java 11 maybe. Do consider that the Commons community
> is
> > > > small
> > > > >> and I would not want to support concurrent support and releases on
> > > bothe
> > > > >> DBCP 2 and 3.
> > > > >>
> > > > >> Gary
> > > > >>
> > > > >> Gary
> > > > >>
> > > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> > wrote:
> > > > >>>
> > > > >>> For DBCP, it basically boils down to
> > > > >>>
> > > > >>> BasicManagedDataSource.java
> > > > >>> DataSourceXAConnectionFactory.java
> > > > >>> LocalXAConnectionFactory.java
> > > > >>> SynchronizationAdapter.java
> > > > >>> TransactionContext.java
> > > > >>> TransactionRegistry.java
> > > > >>>
> > > > >>> Looking at these classes, the move to jakarta definitley affects
> > > binary
> > > > >>> compatibility as we have changes in return types / arguments of
> > > public
> > > > >>> methods. Given that it breaks binary compatibility, we could even
> > > > >>> increase the java level to 11 and drop deprecated things in a
> > > potential
> > > > >>> dbcp 3.
> > > > >>>
> > > > >>> In the end, I am happy with everything, which brings DBCP into
> the
> > > > >>> Jakarta world ;)
> > > > >>>
> > > > >>> If we have consensus for a route, I am happy to work on it / make
> > it
> > > > >>> happen via related PRs but would need some guideance on the best
> > way
> > > to
> > > > >>> move forward.
> > > > >>>
> > > > >>> Gruß
> > > > >>> Richard
> > > > >>>
> > > > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain
> > Manni-Bucau:
> > > >  If not done in new classes (both can live in the same lib
> > > >  technically),
> > > >  sadly yes.
> > > > 
> > > >  Le ven. 16 déc. 2022 à 20:14, Richard Zowalla <
> > rich...@zowalla.com>
> > > a
> > > >  écrit :
> > > > 
> > > > > Thanks for your replies.
> > > > >
> > > > > I guess, that switching the namespace leads to binary
> > > > > incompatibility (If
> > > > > I take the definition from [1]). I cannot drop it in a running
> > JVM
> > > > > / app
> > > > > and expect no issues with it as the related APIs are breaking
> > > > > namespace
> > > > > changes (at least at runtime if they aren't present) :-)
> > > > >
> > > > > Aside from that fact, method signatures might also change from
> > > > > javax ->
> > > > > jakarta, which would require a short investigation and usage of
> > the
> > > > > existing tooling to see if this happens.
> > > > >
> > > > > From a commons point of view that would mean to go for dbcp3,
> > > > > right?
> > > > >
> > > > > Gruß
> > > > > Richard
> > > > >
> > > > > [1]
> > > > >
> > > > >>>
> > > >
> > >
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > > >
> > > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > > :
> > > > >> On 16/12/2022 13:24, 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

What's the rush? Commons has never been on the bleeding edge of anything.
You saw the plan I proposed I presume.

Gary


On Sun, Dec 18, 2022, 04:38 Romain Manni-Bucau 
wrote:

> Any idea on when it can occurs? We are quite late to the party already and
> shade was a good solution to be in without additional cost in terms of
> maintainance for the project so if not the picked option we should target
> some point not too far in 2023 pby.
>
> Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
> écrit :
>
> > Hi Arun,
> >
> > There's not going to be anything to pick up for a while ;-)
> >
> > Gary
> >
> > On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> > wrote:
> >
> > > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it
> up.
> > >
> > > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > > wrote:
> > > >
> > > > Sure. Sounds like a plan :)
> > > >
> > > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > > garydgreg...@gmail.com>:
> > > >> I think we should wait for a little while: I'd want to release
> current
> > > code
> > > >> from git for Commons Pool, then DBCP (which sits on top of Pool),
> make
> > > sure
> > > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > > >> considering Java 11 maybe. Do consider that the Commons community is
> > > small
> > > >> and I would not want to support concurrent support and releases on
> > bothe
> > > >> DBCP 2 and 3.
> > > >>
> > > >> Gary
> > > >>
> > > >> Gary
> > > >>
> > > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla 
> wrote:
> > > >>>
> > > >>> For DBCP, it basically boils down to
> > > >>>
> > > >>> BasicManagedDataSource.java
> > > >>> DataSourceXAConnectionFactory.java
> > > >>> LocalXAConnectionFactory.java
> > > >>> SynchronizationAdapter.java
> > > >>> TransactionContext.java
> > > >>> TransactionRegistry.java
> > > >>>
> > > >>> Looking at these classes, the move to jakarta definitley affects
> > binary
> > > >>> compatibility as we have changes in return types / arguments of
> > public
> > > >>> methods. Given that it breaks binary compatibility, we could even
> > > >>> increase the java level to 11 and drop deprecated things in a
> > potential
> > > >>> dbcp 3.
> > > >>>
> > > >>> In the end, I am happy with everything, which brings DBCP into the
> > > >>> Jakarta world ;)
> > > >>>
> > > >>> If we have consensus for a route, I am happy to work on it / make
> it
> > > >>> happen via related PRs but would need some guideance on the best
> way
> > to
> > > >>> move forward.
> > > >>>
> > > >>> Gruß
> > > >>> Richard
> > > >>>
> > > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain
> Manni-Bucau:
> > >  If not done in new classes (both can live in the same lib
> > >  technically),
> > >  sadly yes.
> > > 
> > >  Le ven. 16 déc. 2022 à 20:14, Richard Zowalla <
> rich...@zowalla.com>
> > a
> > >  écrit :
> > > 
> > > > Thanks for your replies.
> > > >
> > > > I guess, that switching the namespace leads to binary
> > > > incompatibility (If
> > > > I take the definition from [1]). I cannot drop it in a running
> JVM
> > > > / app
> > > > and expect no issues with it as the related APIs are breaking
> > > > namespace
> > > > changes (at least at runtime if they aren't present) :-)
> > > >
> > > > Aside from that fact, method signatures might also change from
> > > > javax ->
> > > > jakarta, which would require a short investigation and usage of
> the
> > > > existing tooling to see if this happens.
> > > >
> > > > From a commons point of view that would mean to go for dbcp3,
> > > > right?
> > > >
> > > > Gruß
> > > > Richard
> > > >
> > > > [1]
> > > >
> > > >>>
> > >
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > > >
> > > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > > :
> > > >> On 16/12/2022 13:24, Gary Gregory wrote:
> > > >>> Thank you Richard for starting this thread.
> > > >>>
> > > >>> My view is simpler perhaps: I would not make this about the
> > > >>> javax vs
> > > >>> Jakarta namespaces.
> > > >>>
> > > >>> I don't want to double the numbers of jars we produce from the
> > > >>> same
> > > > branch
> > > >>> for affected components as one of the scheme proposed. It feels
> > > >>> like a
> > > >>> burden to maintenance moving forward and a very brittle process
> > > >>> with
> > > > some
> > > >>> unforeseen side effects.
> > > >>>
> > > >>> This is just a code change IMO. For a given component, either
> > > >>> it is
> > > > binary
> > > >>> compatible, or it is not. You don't know until you try it and
> > > >>> see if
> > > > public
> > > >>> and protected elements break, using our existing configuration
> > > >>> of Maven
> > > > and
> > > >>> japicmp (or revapi).
> 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

Any idea on when it can occurs? We are quite late to the party already and
shade was a good solution to be in without additional cost in terms of
maintainance for the project so if not the picked option we should target
some point not too far in 2023 pby.

Le dim. 18 déc. 2022 à 01:44, Gary Gregory  a
écrit :

> Hi Arun,
>
> There's not going to be anything to pick up for a while ;-)
>
> Gary
>
> On Sat, Dec 17, 2022, 18:06 Arun Avanathan 
> wrote:
>
> > Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up.
> >
> > > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> > wrote:
> > >
> > > Sure. Sounds like a plan :)
> > >
> > > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> > garydgreg...@gmail.com>:
> > >> I think we should wait for a little while: I'd want to release current
> > code
> > >> from git for Commons Pool, then DBCP (which sits on top of Pool), make
> > sure
> > >> all is well, then see about going to DBCP 3, on Java 8 for now but
> > >> considering Java 11 maybe. Do consider that the Commons community is
> > small
> > >> and I would not want to support concurrent support and releases on
> bothe
> > >> DBCP 2 and 3.
> > >>
> > >> Gary
> > >>
> > >> Gary
> > >>
> > >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
> > >>>
> > >>> For DBCP, it basically boils down to
> > >>>
> > >>> BasicManagedDataSource.java
> > >>> DataSourceXAConnectionFactory.java
> > >>> LocalXAConnectionFactory.java
> > >>> SynchronizationAdapter.java
> > >>> TransactionContext.java
> > >>> TransactionRegistry.java
> > >>>
> > >>> Looking at these classes, the move to jakarta definitley affects
> binary
> > >>> compatibility as we have changes in return types / arguments of
> public
> > >>> methods. Given that it breaks binary compatibility, we could even
> > >>> increase the java level to 11 and drop deprecated things in a
> potential
> > >>> dbcp 3.
> > >>>
> > >>> In the end, I am happy with everything, which brings DBCP into the
> > >>> Jakarta world ;)
> > >>>
> > >>> If we have consensus for a route, I am happy to work on it / make it
> > >>> happen via related PRs but would need some guideance on the best way
> to
> > >>> move forward.
> > >>>
> > >>> Gruß
> > >>> Richard
> > >>>
> > >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> >  If not done in new classes (both can live in the same lib
> >  technically),
> >  sadly yes.
> > 
> >  Le ven. 16 déc. 2022 à 20:14, Richard Zowalla 
> a
> >  écrit :
> > 
> > > Thanks for your replies.
> > >
> > > I guess, that switching the namespace leads to binary
> > > incompatibility (If
> > > I take the definition from [1]). I cannot drop it in a running JVM
> > > / app
> > > and expect no issues with it as the related APIs are breaking
> > > namespace
> > > changes (at least at runtime if they aren't present) :-)
> > >
> > > Aside from that fact, method signatures might also change from
> > > javax ->
> > > jakarta, which would require a short investigation and usage of the
> > > existing tooling to see if this happens.
> > >
> > > From a commons point of view that would mean to go for dbcp3,
> > > right?
> > >
> > > Gruß
> > > Richard
> > >
> > > [1]
> > >
> > >>>
> >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > >
> > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > :
> > >> On 16/12/2022 13:24, Gary Gregory wrote:
> > >>> Thank you Richard for starting this thread.
> > >>>
> > >>> My view is simpler perhaps: I would not make this about the
> > >>> javax vs
> > >>> Jakarta namespaces.
> > >>>
> > >>> I don't want to double the numbers of jars we produce from the
> > >>> same
> > > branch
> > >>> for affected components as one of the scheme proposed. It feels
> > >>> like a
> > >>> burden to maintenance moving forward and a very brittle process
> > >>> with
> > > some
> > >>> unforeseen side effects.
> > >>>
> > >>> This is just a code change IMO. For a given component, either
> > >>> it is
> > > binary
> > >>> compatible, or it is not. You don't know until you try it and
> > >>> see if
> > > public
> > >>> and protected elements break, using our existing configuration
> > >>> of Maven
> > > and
> > >>> japicmp (or revapi).
> > >>>
> > >>> If it is binary compatible, then let's consider making the
> > >>> change. If
> > > not,
> > >>> then do it in a major version, where the previous major version
> > >>> is
> > >>> maintained as we do now, as need be.
> > >>>
> > >>> A new major version also benefits from the usual dropping of
> > >>> deprecated
> > >>> elements and making any other changes with seem reasonable.
> > >>
> > >> +1. I don't see this as any 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

Hi Arun,

There's not going to be anything to pick up for a while ;-)

Gary

On Sat, Dec 17, 2022, 18:06 Arun Avanathan  wrote:

> Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up.
>
> > On Dec 17, 2022, at 1:09 PM, Richard Zowalla 
> wrote:
> >
> > Sure. Sounds like a plan :)
> >
> > Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory <
> garydgreg...@gmail.com>:
> >> I think we should wait for a little while: I'd want to release current
> code
> >> from git for Commons Pool, then DBCP (which sits on top of Pool), make
> sure
> >> all is well, then see about going to DBCP 3, on Java 8 for now but
> >> considering Java 11 maybe. Do consider that the Commons community is
> small
> >> and I would not want to support concurrent support and releases on bothe
> >> DBCP 2 and 3.
> >>
> >> Gary
> >>
> >> Gary
> >>
> >>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
> >>>
> >>> For DBCP, it basically boils down to
> >>>
> >>> BasicManagedDataSource.java
> >>> DataSourceXAConnectionFactory.java
> >>> LocalXAConnectionFactory.java
> >>> SynchronizationAdapter.java
> >>> TransactionContext.java
> >>> TransactionRegistry.java
> >>>
> >>> Looking at these classes, the move to jakarta definitley affects binary
> >>> compatibility as we have changes in return types / arguments of public
> >>> methods. Given that it breaks binary compatibility, we could even
> >>> increase the java level to 11 and drop deprecated things in a potential
> >>> dbcp 3.
> >>>
> >>> In the end, I am happy with everything, which brings DBCP into the
> >>> Jakarta world ;)
> >>>
> >>> If we have consensus for a route, I am happy to work on it / make it
> >>> happen via related PRs but would need some guideance on the best way to
> >>> move forward.
> >>>
> >>> Gruß
> >>> Richard
> >>>
> >>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
>  If not done in new classes (both can live in the same lib
>  technically),
>  sadly yes.
> 
>  Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
>  écrit :
> 
> > Thanks for your replies.
> >
> > I guess, that switching the namespace leads to binary
> > incompatibility (If
> > I take the definition from [1]). I cannot drop it in a running JVM
> > / app
> > and expect no issues with it as the related APIs are breaking
> > namespace
> > changes (at least at runtime if they aren't present) :-)
> >
> > Aside from that fact, method signatures might also change from
> > javax ->
> > jakarta, which would require a short investigation and usage of the
> > existing tooling to see if this happens.
> >
> > From a commons point of view that would mean to go for dbcp3,
> > right?
> >
> > Gruß
> > Richard
> >
> > [1]
> >
> >>>
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> >
> > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > :
> >> On 16/12/2022 13:24, Gary Gregory wrote:
> >>> Thank you Richard for starting this thread.
> >>>
> >>> My view is simpler perhaps: I would not make this about the
> >>> javax vs
> >>> Jakarta namespaces.
> >>>
> >>> I don't want to double the numbers of jars we produce from the
> >>> same
> > branch
> >>> for affected components as one of the scheme proposed. It feels
> >>> like a
> >>> burden to maintenance moving forward and a very brittle process
> >>> with
> > some
> >>> unforeseen side effects.
> >>>
> >>> This is just a code change IMO. For a given component, either
> >>> it is
> > binary
> >>> compatible, or it is not. You don't know until you try it and
> >>> see if
> > public
> >>> and protected elements break, using our existing configuration
> >>> of Maven
> > and
> >>> japicmp (or revapi).
> >>>
> >>> If it is binary compatible, then let's consider making the
> >>> change. If
> > not,
> >>> then do it in a major version, where the previous major version
> >>> is
> >>> maintained as we do now, as need be.
> >>>
> >>> A new major version also benefits from the usual dropping of
> >>> deprecated
> >>> elements and making any other changes with seem reasonable.
> >>
> >> +1. I don't see this as any different to increasing the minimum
> >> version
> > of Java and supported new JDBC methods.
> >>
> >> Mark
> >>
> >> -
> >> 
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: 

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Arun Avanathan]

Gary - if we have a ticket to upgrade DBCP to java 11, I can take it up.

> On Dec 17, 2022, at 1:09 PM, Richard Zowalla  wrote:
> 
> Sure. Sounds like a plan :)
> 
> Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory 
> :
>> I think we should wait for a little while: I'd want to release current code
>> from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
>> all is well, then see about going to DBCP 3, on Java 8 for now but
>> considering Java 11 maybe. Do consider that the Commons community is small
>> and I would not want to support concurrent support and releases on bothe
>> DBCP 2 and 3.
>> 
>> Gary
>> 
>> Gary
>> 
>>> On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
>>> 
>>> For DBCP, it basically boils down to
>>> 
>>> BasicManagedDataSource.java
>>> DataSourceXAConnectionFactory.java
>>> LocalXAConnectionFactory.java
>>> SynchronizationAdapter.java
>>> TransactionContext.java
>>> TransactionRegistry.java
>>> 
>>> Looking at these classes, the move to jakarta definitley affects binary
>>> compatibility as we have changes in return types / arguments of public
>>> methods. Given that it breaks binary compatibility, we could even
>>> increase the java level to 11 and drop deprecated things in a potential
>>> dbcp 3.
>>> 
>>> In the end, I am happy with everything, which brings DBCP into the
>>> Jakarta world ;)
>>> 
>>> If we have consensus for a route, I am happy to work on it / make it
>>> happen via related PRs but would need some guideance on the best way to
>>> move forward.
>>> 
>>> Gruß
>>> Richard
>>> 
>>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
 If not done in new classes (both can live in the same lib
 technically),
 sadly yes.
 
 Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
 écrit :
 
> Thanks for your replies.
> 
> I guess, that switching the namespace leads to binary
> incompatibility (If
> I take the definition from [1]). I cannot drop it in a running JVM
> / app
> and expect no issues with it as the related APIs are breaking
> namespace
> changes (at least at runtime if they aren't present) :-)
> 
> Aside from that fact, method signatures might also change from
> javax ->
> jakarta, which would require a short investigation and usage of the
> existing tooling to see if this happens.
> 
> From a commons point of view that would mean to go for dbcp3,
> right?
> 
> Gruß
> Richard
> 
> [1]
> 
>>> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> 
> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> :
>> On 16/12/2022 13:24, Gary Gregory wrote:
>>> Thank you Richard for starting this thread.
>>> 
>>> My view is simpler perhaps: I would not make this about the
>>> javax vs
>>> Jakarta namespaces.
>>> 
>>> I don't want to double the numbers of jars we produce from the
>>> same
> branch
>>> for affected components as one of the scheme proposed. It feels
>>> like a
>>> burden to maintenance moving forward and a very brittle process
>>> with
> some
>>> unforeseen side effects.
>>> 
>>> This is just a code change IMO. For a given component, either
>>> it is
> binary
>>> compatible, or it is not. You don't know until you try it and
>>> see if
> public
>>> and protected elements break, using our existing configuration
>>> of Maven
> and
>>> japicmp (or revapi).
>>> 
>>> If it is binary compatible, then let's consider making the
>>> change. If
> not,
>>> then do it in a major version, where the previous major version
>>> is
>>> maintained as we do now, as need be.
>>> 
>>> A new major version also benefits from the usual dropping of
>>> deprecated
>>> elements and making any other changes with seem reasonable.
>> 
>> +1. I don't see this as any different to increasing the minimum
>> version
> of Java and supported new JDBC methods.
>> 
>> Mark
>> 
>> -
>> 
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>>> 

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Sure. Sounds like a plan :)

Am 17. Dezember 2022 22:06:48 MEZ schrieb Gary Gregory :
>I think we should wait for a little while: I'd want to release current code
>from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
>all is well, then see about going to DBCP 3, on Java 8 for now but
>considering Java 11 maybe. Do consider that the Commons community is small
>and I would not want to support concurrent support and releases on bothe
>DBCP 2 and 3.
>
>Gary
>
>Gary
>
>On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:
>
>> For DBCP, it basically boils down to
>>
>> BasicManagedDataSource.java
>> DataSourceXAConnectionFactory.java
>> LocalXAConnectionFactory.java
>> SynchronizationAdapter.java
>> TransactionContext.java
>> TransactionRegistry.java
>>
>> Looking at these classes, the move to jakarta definitley affects binary
>> compatibility as we have changes in return types / arguments of public
>> methods. Given that it breaks binary compatibility, we could even
>> increase the java level to 11 and drop deprecated things in a potential
>> dbcp 3.
>>
>> In the end, I am happy with everything, which brings DBCP into the
>> Jakarta world ;)
>>
>> If we have consensus for a route, I am happy to work on it / make it
>> happen via related PRs but would need some guideance on the best way to
>> move forward.
>>
>> Gruß
>> Richard
>>
>> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
>> > If not done in new classes (both can live in the same lib
>> > technically),
>> > sadly yes.
>> >
>> > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
>> > écrit :
>> >
>> > > Thanks for your replies.
>> > >
>> > > I guess, that switching the namespace leads to binary
>> > > incompatibility (If
>> > > I take the definition from [1]). I cannot drop it in a running JVM
>> > > / app
>> > > and expect no issues with it as the related APIs are breaking
>> > > namespace
>> > > changes (at least at runtime if they aren't present) :-)
>> > >
>> > > Aside from that fact, method signatures might also change from
>> > > javax ->
>> > > jakarta, which would require a short investigation and usage of the
>> > > existing tooling to see if this happens.
>> > >
>> > > From a commons point of view that would mean to go for dbcp3,
>> > > right?
>> > >
>> > > Gruß
>> > > Richard
>> > >
>> > > [1]
>> > >
>> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>> > >
>> > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
>> > > :
>> > > > On 16/12/2022 13:24, Gary Gregory wrote:
>> > > > > Thank you Richard for starting this thread.
>> > > > >
>> > > > > My view is simpler perhaps: I would not make this about the
>> > > > > javax vs
>> > > > > Jakarta namespaces.
>> > > > >
>> > > > > I don't want to double the numbers of jars we produce from the
>> > > > > same
>> > > branch
>> > > > > for affected components as one of the scheme proposed. It feels
>> > > > > like a
>> > > > > burden to maintenance moving forward and a very brittle process
>> > > > > with
>> > > some
>> > > > > unforeseen side effects.
>> > > > >
>> > > > > This is just a code change IMO. For a given component, either
>> > > > > it is
>> > > binary
>> > > > > compatible, or it is not. You don't know until you try it and
>> > > > > see if
>> > > public
>> > > > > and protected elements break, using our existing configuration
>> > > > > of Maven
>> > > and
>> > > > > japicmp (or revapi).
>> > > > >
>> > > > > If it is binary compatible, then let's consider making the
>> > > > > change. If
>> > > not,
>> > > > > then do it in a major version, where the previous major version
>> > > > > is
>> > > > > maintained as we do now, as need be.
>> > > > >
>> > > > > A new major version also benefits from the usual dropping of
>> > > > > deprecated
>> > > > > elements and making any other changes with seem reasonable.
>> > > >
>> > > > +1. I don't see this as any different to increasing the minimum
>> > > > version
>> > > of Java and supported new JDBC methods.
>> > > >
>> > > > Mark
>> > > >
>> > > > -
>> > > > 
>> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > > > For additional commands, e-mail: dev-h...@commons.apache.org
>> > > >
>> > >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

I think we should wait for a little while: I'd want to release current code
from git for Commons Pool, then DBCP (which sits on top of Pool), make sure
all is well, then see about going to DBCP 3, on Java 8 for now but
considering Java 11 maybe. Do consider that the Commons community is small
and I would not want to support concurrent support and releases on bothe
DBCP 2 and 3.

Gary

Gary

On Sat, Dec 17, 2022, 14:12 Richard Zowalla  wrote:

> For DBCP, it basically boils down to
>
> BasicManagedDataSource.java
> DataSourceXAConnectionFactory.java
> LocalXAConnectionFactory.java
> SynchronizationAdapter.java
> TransactionContext.java
> TransactionRegistry.java
>
> Looking at these classes, the move to jakarta definitley affects binary
> compatibility as we have changes in return types / arguments of public
> methods. Given that it breaks binary compatibility, we could even
> increase the java level to 11 and drop deprecated things in a potential
> dbcp 3.
>
> In the end, I am happy with everything, which brings DBCP into the
> Jakarta world ;)
>
> If we have consensus for a route, I am happy to work on it / make it
> happen via related PRs but would need some guideance on the best way to
> move forward.
>
> Gruß
> Richard
>
> Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> > If not done in new classes (both can live in the same lib
> > technically),
> > sadly yes.
> >
> > Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
> > écrit :
> >
> > > Thanks for your replies.
> > >
> > > I guess, that switching the namespace leads to binary
> > > incompatibility (If
> > > I take the definition from [1]). I cannot drop it in a running JVM
> > > / app
> > > and expect no issues with it as the related APIs are breaking
> > > namespace
> > > changes (at least at runtime if they aren't present) :-)
> > >
> > > Aside from that fact, method signatures might also change from
> > > javax ->
> > > jakarta, which would require a short investigation and usage of the
> > > existing tooling to see if this happens.
> > >
> > > From a commons point of view that would mean to go for dbcp3,
> > > right?
> > >
> > > Gruß
> > > Richard
> > >
> > > [1]
> > >
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > >
> > > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > > :
> > > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > > Thank you Richard for starting this thread.
> > > > >
> > > > > My view is simpler perhaps: I would not make this about the
> > > > > javax vs
> > > > > Jakarta namespaces.
> > > > >
> > > > > I don't want to double the numbers of jars we produce from the
> > > > > same
> > > branch
> > > > > for affected components as one of the scheme proposed. It feels
> > > > > like a
> > > > > burden to maintenance moving forward and a very brittle process
> > > > > with
> > > some
> > > > > unforeseen side effects.
> > > > >
> > > > > This is just a code change IMO. For a given component, either
> > > > > it is
> > > binary
> > > > > compatible, or it is not. You don't know until you try it and
> > > > > see if
> > > public
> > > > > and protected elements break, using our existing configuration
> > > > > of Maven
> > > and
> > > > > japicmp (or revapi).
> > > > >
> > > > > If it is binary compatible, then let's consider making the
> > > > > change. If
> > > not,
> > > > > then do it in a major version, where the previous major version
> > > > > is
> > > > > maintained as we do now, as need be.
> > > > >
> > > > > A new major version also benefits from the usual dropping of
> > > > > deprecated
> > > > > elements and making any other changes with seem reasonable.
> > > >
> > > > +1. I don't see this as any different to increasing the minimum
> > > > version
> > > of Java and supported new JDBC methods.
> > > >
> > > > Mark
> > > >
> > > > -
> > > > 
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > >
> > >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

For DBCP, it basically boils down to

BasicManagedDataSource.java
DataSourceXAConnectionFactory.java
LocalXAConnectionFactory.java
SynchronizationAdapter.java
TransactionContext.java
TransactionRegistry.java

Looking at these classes, the move to jakarta definitley affects binary
compatibility as we have changes in return types / arguments of public
methods. Given that it breaks binary compatibility, we could even
increase the java level to 11 and drop deprecated things in a potential
dbcp 3.

In the end, I am happy with everything, which brings DBCP into the
Jakarta world ;)

If we have consensus for a route, I am happy to work on it / make it
happen via related PRs but would need some guideance on the best way to
move forward. 

Gruß
Richard

Am Freitag, dem 16.12.2022 um 20:56 +0100 schrieb Romain Manni-Bucau:
> If not done in new classes (both can live in the same lib
> technically),
> sadly yes.
> 
> Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
> écrit :
> 
> > Thanks for your replies.
> > 
> > I guess, that switching the namespace leads to binary
> > incompatibility (If
> > I take the definition from [1]). I cannot drop it in a running JVM
> > / app
> > and expect no issues with it as the related APIs are breaking
> > namespace
> > changes (at least at runtime if they aren't present) :-)
> > 
> > Aside from that fact, method signatures might also change from
> > javax ->
> > jakarta, which would require a short investigation and usage of the
> > existing tooling to see if this happens.
> > 
> > From a commons point of view that would mean to go for dbcp3,
> > right?
> > 
> > Gruß
> > Richard
> > 
> > [1]
> > https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
> > 
> > Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas
> > :
> > > On 16/12/2022 13:24, Gary Gregory wrote:
> > > > Thank you Richard for starting this thread.
> > > > 
> > > > My view is simpler perhaps: I would not make this about the
> > > > javax vs
> > > > Jakarta namespaces.
> > > > 
> > > > I don't want to double the numbers of jars we produce from the
> > > > same
> > branch
> > > > for affected components as one of the scheme proposed. It feels
> > > > like a
> > > > burden to maintenance moving forward and a very brittle process
> > > > with
> > some
> > > > unforeseen side effects.
> > > > 
> > > > This is just a code change IMO. For a given component, either
> > > > it is
> > binary
> > > > compatible, or it is not. You don't know until you try it and
> > > > see if
> > public
> > > > and protected elements break, using our existing configuration
> > > > of Maven
> > and
> > > > japicmp (or revapi).
> > > > 
> > > > If it is binary compatible, then let's consider making the
> > > > change. If
> > not,
> > > > then do it in a major version, where the previous major version
> > > > is
> > > > maintained as we do now, as need be.
> > > > 
> > > > A new major version also benefits from the usual dropping of
> > > > deprecated
> > > > elements and making any other changes with seem reasonable.
> > > 
> > > +1. I don't see this as any different to increasing the minimum
> > > version
> > of Java and supported new JDBC methods.
> > > 
> > > Mark
> > > 
> > > -
> > > 
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > 
> > 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

If not done in new classes (both can live in the same lib technically),
sadly yes.

Le ven. 16 déc. 2022 à 20:14, Richard Zowalla  a
écrit :

> Thanks for your replies.
>
> I guess, that switching the namespace leads to binary incompatibility (If
> I take the definition from [1]). I cannot drop it in a running JVM / app
> and expect no issues with it as the related APIs are breaking namespace
> changes (at least at runtime if they aren't present) :-)
>
> Aside from that fact, method signatures might also change from javax ->
> jakarta, which would require a short investigation and usage of the
> existing tooling to see if this happens.
>
> From a commons point of view that would mean to go for dbcp3, right?
>
> Gruß
> Richard
>
> [1]
> https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/
>
> Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas :
> >On 16/12/2022 13:24, Gary Gregory wrote:
> >> Thank you Richard for starting this thread.
> >>
> >> My view is simpler perhaps: I would not make this about the javax vs
> >> Jakarta namespaces.
> >>
> >> I don't want to double the numbers of jars we produce from the same
> branch
> >> for affected components as one of the scheme proposed. It feels like a
> >> burden to maintenance moving forward and a very brittle process with
> some
> >> unforeseen side effects.
> >>
> >> This is just a code change IMO. For a given component, either it is
> binary
> >> compatible, or it is not. You don't know until you try it and see if
> public
> >> and protected elements break, using our existing configuration of Maven
> and
> >> japicmp (or revapi).
> >>
> >> If it is binary compatible, then let's consider making the change. If
> not,
> >> then do it in a major version, where the previous major version is
> >> maintained as we do now, as need be.
> >>
> >> A new major version also benefits from the usual dropping of deprecated
> >> elements and making any other changes with seem reasonable.
> >
> >+1. I don't see this as any different to increasing the minimum version
> of Java and supported new JDBC methods.
> >
> >Mark
> >
> >-
> >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >For additional commands, e-mail: dev-h...@commons.apache.org
> >
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Thanks for your replies. 

I guess, that switching the namespace leads to binary incompatibility (If I 
take the definition from [1]). I cannot drop it in a running JVM / app and 
expect no issues with it as the related APIs are breaking namespace changes (at 
least at runtime if they aren't present) :-) 

Aside from that fact, method signatures might also change from javax -> 
jakarta, which would require a short investigation and usage of the existing 
tooling to see if this happens.

From a commons point of view that would mean to go for dbcp3, right?

Gruß
Richard 

[1] 
https://garygregory.wordpress.com/2020/06/14/how-we-handle-binary-compatibility-at-apache-commons/

Am 16. Dezember 2022 15:53:53 MEZ schrieb Mark Thomas :
>On 16/12/2022 13:24, Gary Gregory wrote:
>> Thank you Richard for starting this thread.
>> 
>> My view is simpler perhaps: I would not make this about the javax vs
>> Jakarta namespaces.
>> 
>> I don't want to double the numbers of jars we produce from the same branch
>> for affected components as one of the scheme proposed. It feels like a
>> burden to maintenance moving forward and a very brittle process with some
>> unforeseen side effects.
>> 
>> This is just a code change IMO. For a given component, either it is binary
>> compatible, or it is not. You don't know until you try it and see if public
>> and protected elements break, using our existing configuration of Maven and
>> japicmp (or revapi).
>> 
>> If it is binary compatible, then let's consider making the change. If not,
>> then do it in a major version, where the previous major version is
>> maintained as we do now, as need be.
>> 
>> A new major version also benefits from the usual dropping of deprecated
>> elements and making any other changes with seem reasonable.
>
>+1. I don't see this as any different to increasing the minimum version of 
>Java and supported new JDBC methods.
>
>Mark
>
>-
>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Mark Thomas]

On 16/12/2022 13:24, Gary Gregory wrote:

Thank you Richard for starting this thread.

My view is simpler perhaps: I would not make this about the javax vs
Jakarta namespaces.

I don't want to double the numbers of jars we produce from the same branch
for affected components as one of the scheme proposed. It feels like a
burden to maintenance moving forward and a very brittle process with some
unforeseen side effects.

This is just a code change IMO. For a given component, either it is binary
compatible, or it is not. You don't know until you try it and see if public
and protected elements break, using our existing configuration of Maven and
japicmp (or revapi).

If it is binary compatible, then let's consider making the change. If not,
then do it in a major version, where the previous major version is
maintained as we do now, as need be.

A new major version also benefits from the usual dropping of deprecated
elements and making any other changes with seem reasonable.


+1. I don't see this as any different to increasing the minimum version 
of Java and supported new JDBC methods.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Gary Gregory]

Thank you Richard for starting this thread.

My view is simpler perhaps: I would not make this about the javax vs
Jakarta namespaces.

I don't want to double the numbers of jars we produce from the same branch
for affected components as one of the scheme proposed. It feels like a
burden to maintenance moving forward and a very brittle process with some
unforeseen side effects.

This is just a code change IMO. For a given component, either it is binary
compatible, or it is not. You don't know until you try it and see if public
and protected elements break, using our existing configuration of Maven and
japicmp (or revapi).

If it is binary compatible, then let's consider making the change. If not,
then do it in a major version, where the previous major version is
maintained as we do now, as need be.

A new major version also benefits from the usual dropping of deprecated
elements and making any other changes with seem reasonable.

Gary


On Fri, Dec 16, 2022, 04:35 Richard Zowalla  wrote:

> Hi all,
>
> based on the discussion [1] for DBCP, I wanted to start a discussion
> whether and how the Apache Commons project might/want to support the
> Jakarta namespace changes.
>
> I know, that not all commons projects are impacted by the namespaces
> change, but we should make sure, that users can use related projects
> like DBCP with the emerging presense of Jakarta EE 9 / 10 in the near
> future.
>
> Other EE-related projects decided to use a relocation approach as shown
> in [1], which might not be a feasable option for every project impacted
> by the change. As suggested by @garydgregory in [1], the sanest way
> would be to change the source code. This might break binary
> compatibility and requires new major versions and effort to maintain
> both worlds (javax, jakarta) as javax will be still around for some
> time.
>
> Ideally, we find some sort of agreement to move on, so depending
> projects like TomEE or users can use jakarta ready artifacts. I am
> happy to contribute / be part of that journey.
>
> So the question boils down to:
>
> (a) Switch to jakarta (and provide javax artifacts via relocation)
> (b) Stay on javax (and provide jakarta artifacts via relocation)
> (c) Maintain two branches (jakarta & javax) and cherry pick changes
> between them.
> (d) Abandon javax and move on
> (e) Something else?
>
>
> Any thoughts, ideas, visions regarding that topic?
>
> Gruß
> Richard
>
>
> [1] https://github.com/apache/commons-dbcp/pull/248
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: Jakarta namespace in commons like dbcp - thoughts / ideas?

[Romain Manni-Bucau]

-1 for c and d, +1 for a, guess b can still be an option for ~2 years
before switching to a

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



Le ven. 16 déc. 2022 à 10:35, Richard Zowalla  a écrit :

> Hi all,
>
> based on the discussion [1] for DBCP, I wanted to start a discussion
> whether and how the Apache Commons project might/want to support the
> Jakarta namespace changes.
>
> I know, that not all commons projects are impacted by the namespaces
> change, but we should make sure, that users can use related projects
> like DBCP with the emerging presense of Jakarta EE 9 / 10 in the near
> future.
>
> Other EE-related projects decided to use a relocation approach as shown
> in [1], which might not be a feasable option for every project impacted
> by the change. As suggested by @garydgregory in [1], the sanest way
> would be to change the source code. This might break binary
> compatibility and requires new major versions and effort to maintain
> both worlds (javax, jakarta) as javax will be still around for some
> time.
>
> Ideally, we find some sort of agreement to move on, so depending
> projects like TomEE or users can use jakarta ready artifacts. I am
> happy to contribute / be part of that journey.
>
> So the question boils down to:
>
> (a) Switch to jakarta (and provide javax artifacts via relocation)
> (b) Stay on javax (and provide jakarta artifacts via relocation)
> (c) Maintain two branches (jakarta & javax) and cherry pick changes
> between them.
> (d) Abandon javax and move on
> (e) Something else?
>
>
> Any thoughts, ideas, visions regarding that topic?
>
> Gruß
> Richard
>
>
> [1] https://github.com/apache/commons-dbcp/pull/248
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Jakarta namespace in commons like dbcp - thoughts / ideas?

[Richard Zowalla]

Hi all,

based on the discussion [1] for DBCP, I wanted to start a discussion
whether and how the Apache Commons project might/want to support the
Jakarta namespace changes.

I know, that not all commons projects are impacted by the namespaces
change, but we should make sure, that users can use related projects
like DBCP with the emerging presense of Jakarta EE 9 / 10 in the near
future.

Other EE-related projects decided to use a relocation approach as shown
in [1], which might not be a feasable option for every project impacted
by the change. As suggested by @garydgregory in [1], the sanest way
would be to change the source code. This might break binary
compatibility and requires new major versions and effort to maintain
both worlds (javax, jakarta) as javax will be still around for some
time. 

Ideally, we find some sort of agreement to move on, so depending
projects like TomEE or users can use jakarta ready artifacts. I am
happy to contribute / be part of that journey.

So the question boils down to:

(a) Switch to jakarta (and provide javax artifacts via relocation) 
(b) Stay on javax (and provide jakarta artifacts via relocation)
(c) Maintain two branches (jakarta & javax) and cherry pick changes
between them.
(d) Abandon javax and move on
(e) Something else?


Any thoughts, ideas, visions regarding that topic?

Gruß
Richard


[1] https://github.com/apache/commons-dbcp/pull/248


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org