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

Re: [Dbutils] PR merges build

[Gary Gregory]

Ping.

Gary

On Fri, Dec 9, 2022, 06:50 Gary Gregory  wrote:

> -1 to the commit or PR that broke the build. To whomever merged it, please
> revert.
>
> Before you merge a PR, if you are uncertain that it is safe, test it
> locally.
>
> Gary
>