date:20200630

Re: [crypto] New Release

2020-06-30 Thread Alex Remily

I'll see if I have any time this weekend, but this part is largely
unfamiliar to me, so not sure how far I'll get even if I have the time
to look at it.

On Tue, Jun 30, 2020 at 4:59 PM Geoffrey Blake
 wrote:
>
> I think you're right Alex.  I just happened to look at the Makefile
> and saw this above the win64 target:
>
> # for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package
>
> We could potentially build everything but MacOS on 1 Ubuntu 16.04LTS
> box.  Or even a 14.04 box if necessary.  Anybody have the time to try?
>
> On Thu, Jun 25, 2020 at 4:12 PM Alex Remily  wrote:
> >
> > Not sure if it's relevant or not, but to get the build to compile on
> > Windows with MinGW, I commented out line 137 of
> > https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:
> >
> > //#define inline __inline;
> >
> > I never did learn why it was there in the first place, but the broken
> > build was originally reported as
> >
> > https://issues.apache.org/jira/browse/CRYPTO-137.
> >
> > Now I'm wondering if it may have had something to do with
> > cross-compiling for the build.
> >
> > On Thu, Jun 25, 2020 at 1:13 PM Geoffrey Blake
> >  wrote:
> > >
> > > Is there anything needed to help move this release along?  From the
> > > looks of the Makefile, Windows was using GCC.  I don't think the
> > > compiler is going to have much of an impact since the JNI bindings are
> > > simply calling through to the OpenSSL library that is already
> > > precompiled for the environment.
> > >
> > > On Sat, Jun 13, 2020 at 6:14 PM Xeno Amess  wrote:
> > > >
> > > > I have a feeling about both mingw or cygwin build output will be slower
> > > > than microsoft-visual-studio build output...
> > > > Just a feeling, but no evidence.
> > > >
> > > > Alex Remily  于2020年6月14日周日 上午7:02写道：
> > > >
> > > > > I used MinGW64.  It does indeed ship with make.  I can provide a link
> > > > > to the distribution I used if there's interest.
> > > > >
> > > > > On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin  
> > > > > wrote:
> > > > > >
> > > > > > Pretty sure I remember comments in the code about building with 
> > > > > > mingw
> > > > > > on Windows (not cygwin). That should have a version of make, too,
> > > > > > IIRC.
> > > > > >
> > > > > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory 
> > > > > > 
> > > > > wrote:
> > > > > > >
> > > > > > > Except that you can't build on plain Windows because the build 
> > > > > > > uses
> > > > > make
> > > > > > > and Microsoft version is called nmake. I might have to cobble up 
> > > > > > > some
> > > > > > > cygwin thing...
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily  
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I can't speak to how the original developers did the build, but 
> > > > > > > > all
> > > > > > > > the Windows builds that I did were on a Windows machine.  I 
> > > > > > > > always
> > > > > > > > assumed that the original developers just manually packed the 
> > > > > > > > release
> > > > > > > > jar with artifacts from each supported environment.  I never 
> > > > > > > > did any
> > > > > > > > investigation into the process.  Is cobbling together a release 
> > > > > > > > in
> > > > > > > > that manner really a non-starter here?
> > > > > > > >
> > > > > > > > Alex
> > > > > > > >
> > > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory 
> > > > > > > >  > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi Matt:
> > > > > > > > >
> > > > > > > > > > I have:
> > > > > > > > > >
> > > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h
> > > > > > > > > > /usr/i686-w64-mingw32/include/windows.h
> > > > > > > > > > /usr/share/mingw-w64/include/windows.h
> > > > > > > > > > /usr/x86_64-w64-mingw32/include/windows.h
> > > > > > > > > >
> > > > > > > > > > Case matters here, so I wonder if the original others did 
> > > > > > > > > > not
> > > > > cross
> > > > > > > > > compile
> > > > > > > > > > from Linux and instead built a little here, a little there, 
> > > > > > > > > > and
> > > > > so on.
> > > > > > > > > >
> > > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure 
> > > > > > > > > > where
> > > > > that is
> > > > > > > > > > supposed to be...
> > > > > > > > >
> > > > > > > > > Gary
> > > > > > > > >
> > > > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker  
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Are the Windows headers even available when using Ming32 or
> > > > > Cygwin?
> > > > > > > > > > That sounds more like a Visual Studio compiler thing.
> > > > > > > > > >
> > > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory <
> > > > > garydgreg...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > The challenge is getting everything set up just right for
> > > > > building
> > > > > > > > the
> > > > > > > > > > >

[test] Bug in StringSubstitutor?

2020-06-30 Thread Gary Gregory

Hi All:

I think we might have a bug in StringSubstitutor exemplified in a comment I
just added in:

org.apache.commons.text.StringSubstitutorTest.testReplaceWeirdPattens()

doTestNoReplace("${");
// TODO this looks like a bug since a $ is removed but this is not
a variable.
// doTestNoReplace("$${");
// doTestNoReplace("$${a");
// doTestNoReplace("$$${");
// doTestNoReplace("$$${a");

I thought that we would only strip $ in front of a _complete_ variable, not
anywhere in front of a variable _prefix_.

Granted this is an edge case but still...

Any thoughts?

Gary

Re: [DBCP] poolPreparedStatements

2020-06-30 Thread Phil Steitz




> On Jun 30, 2020, at 2:36 PM, Gary Gregory  wrote:
> 
> How about clearStatementPoolOnReturn.

+1

Phil
> 
> You do not need to say "Prepared" in the name IMO since we only pool
> prepared statements. The above name actual says what happens when.
> 
> The full version of that name if you want to be extra specific would be
> clearPreparedStatementPoolOnConnectionReturn.
> 
> Gary
> 
>> On Tue, Jun 30, 2020, 16:59 Robert Paschek 
>> wrote:
>> 
>> Thanks for the implementation hints. I'm willing to look into this.
>> 
>> Can you think of a better propertyname than
>> limitPreparedStatementPoolToConnectionUse? While the meaning is clear (at
>> least to me), it's also quite long.
>> 
>> Robert
>> 
>> 
>> From: Phil Steitz 
>> Sent: Dienstag, 30. Juni 2020 21:07
>> To: dev@commons.apache.org
>> Subject: Re: [DBCP] poolPreparedStatements
>> 
>> 
>>> On 6/29/20 12:17 PM, Robert Paschek wrote:
>>> Hello,
>>> 
>>> DBCP has a feature to pool PreparedStatements for the lifetime of a
>> connection.
>>> This results in cursors being open and locks in the database for a long
>> time, which could cause problems with administrative tasks in the database.
>> That why I would prefer this pool to be more short-living, that means that
>> the pool is filled while the application  is using the connection und
>> cleared when the application is returning the connection to the
>> ConnectionPool. This way the application can still benefit from the
>> Statement-cache in mass operations, without creating headaches for database
>> admins.
>>> 
>>> I would suggest an additional setting like
>> limitPreparedStatementPoolToConnectionUse or something similar.
>>> 
>>> What do you think?
>>> 
>>> Regards,
>>> Robert
>> 
>> One way to workaround the need to periodically clean up would be to
>> either set maximum lifetimes on connections or periodically invalidate
>> them.  That would force the underlying PoolingConnections to be closed,
>> which would in turn cause the statement pools to be closed.
>> 
>> The feature request sounds reasonable to me.  For anyone interested in
>> creating a patch to implement this, here is a way that might work to
>> implement it:
>> 
>> Connections that pool statements are PoolingConnections.  Add a property
>> to this class to determine whether or not to clear the statement pool
>> when a connection is returned to the pool. Override
>> DelegatingConnnection's passivate method to first call super() but then
>> examine the property and if so configured, clear (not close) the
>> statement pool.  Modify PoolableConnectionFactory to set the property
>> and BasicDataSource to pass it in.
>> 
>> Probably best to open a JIRA for this.  I don't have time to work on it
>> now, but I would be willing to review PRs.
>> 
>> Phil
>> 
>>> 
>> 
>> 

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

Re: [DBCP] poolPreparedStatements

2020-06-30 Thread Gary Gregory

How about clearStatementPoolOnReturn.

You do not need to say "Prepared" in the name IMO since we only pool
prepared statements. The above name actual says what happens when.

The full version of that name if you want to be extra specific would be
clearPreparedStatementPoolOnConnectionReturn.

Gary

On Tue, Jun 30, 2020, 16:59 Robert Paschek 
wrote:

> Thanks for the implementation hints. I'm willing to look into this.
>
> Can you think of a better propertyname than
> limitPreparedStatementPoolToConnectionUse? While the meaning is clear (at
> least to me), it's also quite long.
>
> Robert
>
>
> From: Phil Steitz 
> Sent: Dienstag, 30. Juni 2020 21:07
> To: dev@commons.apache.org
> Subject: Re: [DBCP] poolPreparedStatements
>
>
> On 6/29/20 12:17 PM, Robert Paschek wrote:
> > Hello,
> >
> > DBCP has a feature to pool PreparedStatements for the lifetime of a
> connection.
> > This results in cursors being open and locks in the database for a long
> time, which could cause problems with administrative tasks in the database.
> That why I would prefer this pool to be more short-living, that means that
> the pool is filled while the application  is using the connection und
> cleared when the application is returning the connection to the
> ConnectionPool. This way the application can still benefit from the
> Statement-cache in mass operations, without creating headaches for database
> admins.
> >
> > I would suggest an additional setting like
> limitPreparedStatementPoolToConnectionUse or something similar.
> >
> > What do you think?
> >
> > Regards,
> > Robert
>
> One way to workaround the need to periodically clean up would be to
> either set maximum lifetimes on connections or periodically invalidate
> them.  That would force the underlying PoolingConnections to be closed,
> which would in turn cause the statement pools to be closed.
>
> The feature request sounds reasonable to me.  For anyone interested in
> creating a patch to implement this, here is a way that might work to
> implement it:
>
> Connections that pool statements are PoolingConnections.  Add a property
> to this class to determine whether or not to clear the statement pool
> when a connection is returned to the pool. Override
> DelegatingConnnection's passivate method to first call super() but then
> examine the property and if so configured, clear (not close) the
> statement pool.  Modify PoolableConnectionFactory to set the property
> and BasicDataSource to pass it in.
>
> Probably best to open a JIRA for this.  I don't have time to work on it
> now, but I would be willing to review PRs.
>
> Phil
>
> >
>
>

Re: Apache Commons Geometry Release

2020-06-30 Thread Matt Juntunen

Alrighty! I will replace that model, save my tutorial changes for later, and 
see if I can start on a release later tonight.

-Matt

From: Gilles Sadowski 
Sent: Tuesday, June 30, 2020 2:35 PM
To: Commons Developers List 
Subject: Re: Apache Commons Geometry Release

Hello.

Le mar. 30 juin 2020 à 18:29, Matt Juntunen  a écrit :
>
> Hi Baljit,
>
> The only things keeping the release from happening at this time are
>
>   1.  the legal issue of including a 3D model which I opened a ticket for in 
> JIRA yesterday [1], and

It doesn't look like this site
https://s2018.siggraph.org/3d-model-portal/
tries hard to prevent use of their (?) data. ;-)

>   2.  the tutorial requested in GEOMETRY-95.
>
> The first issue I can solve easily by just not including that model and just 
> using one that I make myself. It won't be as good but it would work. As for 
> the second issue, I'm working on the tutorial right now and hope to be done 
> within the next week or so. However, I wouldn't have a problem releasing 
> beta1 without it, assuming that Gilles and others are on board with that.
>
> Gilles, WDYT?

It would be great to release "beta1"; the mentioned items can
of course be added later.

Best,
Gilles

>>> [...]

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

Re: [DBCP] poolPreparedStatements

2020-06-30 Thread Robert Paschek

That would be quite difficult to handle on application side. 

Two connection pools means two datasources, which need to be selectively 
injected into the business logic. When the same business logic is handling 100 
or 10 rows, it's difficult to find a place to decide which datasource to 
use.

Robert

From: Gary Gregory 
Sent: Montag, 29. Juni 2020 23:37
To: Commons Developers List
Subject: Re: [DBCP] poolPreparedStatements

You can do this today by using two connection pools, one configured with
statement pooling, and the other not (which is the default).

Gary

On Mon, Jun 29, 2020, 16:36 Robert Paschek 
wrote:

> Hello,
>
> DBCP has a feature to pool PreparedStatements for the lifetime of a
> connection.
> This results in cursors being open and locks in the database for a long
> time, which could cause problems with administrative tasks in the database.
> That why I would prefer this pool to be more short-living, that means that
> the pool is filled while the application is using the connection und
> cleared when the application is returning the connection to the
> ConnectionPool. This way the application can still benefit from the
> Statement-cache in mass operations, without creating headaches for database
> admins.
>
> I would suggest an additional setting like
> limitPreparedStatementPoolToConnectionUse or something similar.
>
> What do you think?
>
> Regards,
> Robert
>

Re: [DBCP] poolPreparedStatements

2020-06-30 Thread Robert Paschek

Thanks for the implementation hints. I'm willing to look into this.

Can you think of a better propertyname than 
limitPreparedStatementPoolToConnectionUse? While the meaning is clear (at least 
to me), it's also quite long.

Robert

From: Phil Steitz 
Sent: Dienstag, 30. Juni 2020 21:07
To: dev@commons.apache.org
Subject: Re: [DBCP] poolPreparedStatements

On 6/29/20 12:17 PM, Robert Paschek wrote:
> Hello,
>
> DBCP has a feature to pool PreparedStatements for the lifetime of a 
> connection.
> This results in cursors being open and locks in the database for a long time, 
> which could cause problems with administrative tasks in the database. That 
> why I would prefer this pool to be more short-living, that means that the 
> pool is filled while the application  is using the connection und cleared 
> when the application is returning the connection to the ConnectionPool. This 
> way the application can still benefit from the Statement-cache in mass 
> operations, without creating headaches for database admins.
>
> I would suggest an additional setting like 
> limitPreparedStatementPoolToConnectionUse or something similar.
>
> What do you think?
>
> Regards,
> Robert

One way to workaround the need to periodically clean up would be to 
either set maximum lifetimes on connections or periodically invalidate 
them.  That would force the underlying PoolingConnections to be closed, 
which would in turn cause the statement pools to be closed.

The feature request sounds reasonable to me.  For anyone interested in 
creating a patch to implement this, here is a way that might work to 
implement it:

Connections that pool statements are PoolingConnections.  Add a property 
to this class to determine whether or not to clear the statement pool 
when a connection is returned to the pool. Override 
DelegatingConnnection's passivate method to first call super() but then 
examine the property and if so configured, clear (not close) the 
statement pool.  Modify PoolableConnectionFactory to set the property 
and BasicDataSource to pass it in.

Probably best to open a JIRA for this.  I don't have time to work on it 
now, but I would be willing to review PRs.

Phil

>

Re: [crypto] New Release

2020-06-30 Thread Geoffrey Blake

I think you're right Alex.  I just happened to look at the Makefile
and saw this above the win64 target:

# for cross-compilation on Ubuntu, install the g++-mingw-w64-x86-64 package

We could potentially build everything but MacOS on 1 Ubuntu 16.04LTS
box.  Or even a 14.04 box if necessary.  Anybody have the time to try?

On Thu, Jun 25, 2020 at 4:12 PM Alex Remily  wrote:
>
> Not sure if it's relevant or not, but to get the build to compile on
> Windows with MinGW, I commented out line 137 of
> https://github.com/apache/commons-crypto/blob/master/src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:
>
> //#define inline __inline;
>
> I never did learn why it was there in the first place, but the broken
> build was originally reported as
>
> https://issues.apache.org/jira/browse/CRYPTO-137.
>
> Now I'm wondering if it may have had something to do with
> cross-compiling for the build.
>
> On Thu, Jun 25, 2020 at 1:13 PM Geoffrey Blake
>  wrote:
> >
> > Is there anything needed to help move this release along?  From the
> > looks of the Makefile, Windows was using GCC.  I don't think the
> > compiler is going to have much of an impact since the JNI bindings are
> > simply calling through to the OpenSSL library that is already
> > precompiled for the environment.
> >
> > On Sat, Jun 13, 2020 at 6:14 PM Xeno Amess  wrote:
> > >
> > > I have a feeling about both mingw or cygwin build output will be slower
> > > than microsoft-visual-studio build output...
> > > Just a feeling, but no evidence.
> > >
> > > Alex Remily  于2020年6月14日周日 上午7:02写道：
> > >
> > > > I used MinGW64.  It does indeed ship with make.  I can provide a link
> > > > to the distribution I used if there's interest.
> > > >
> > > > On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin  wrote:
> > > > >
> > > > > Pretty sure I remember comments in the code about building with mingw
> > > > > on Windows (not cygwin). That should have a version of make, too,
> > > > > IIRC.
> > > > >
> > > > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory 
> > > > wrote:
> > > > > >
> > > > > > Except that you can't build on plain Windows because the build uses
> > > > make
> > > > > > and Microsoft version is called nmake. I might have to cobble up 
> > > > > > some
> > > > > > cygwin thing...
> > > > > >
> > > > > > Gary
> > > > > >
> > > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily  
> > > > > > wrote:
> > > > > >
> > > > > > > I can't speak to how the original developers did the build, but 
> > > > > > > all
> > > > > > > the Windows builds that I did were on a Windows machine.  I always
> > > > > > > assumed that the original developers just manually packed the 
> > > > > > > release
> > > > > > > jar with artifacts from each supported environment.  I never did 
> > > > > > > any
> > > > > > > investigation into the process.  Is cobbling together a release in
> > > > > > > that manner really a non-starter here?
> > > > > > >
> > > > > > > Alex
> > > > > > >
> > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory 
> > > > > > >  > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Matt:
> > > > > > > >
> > > > > > > > > I have:
> > > > > > > > >
> > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h
> > > > > > > > > /usr/i686-w64-mingw32/include/windows.h
> > > > > > > > > /usr/share/mingw-w64/include/windows.h
> > > > > > > > > /usr/x86_64-w64-mingw32/include/windows.h
> > > > > > > > >
> > > > > > > > > Case matters here, so I wonder if the original others did not
> > > > cross
> > > > > > > > compile
> > > > > > > > > from Linux and instead built a little here, a little there, 
> > > > > > > > > and
> > > > so on.
> > > > > > > > >
> > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where
> > > > that is
> > > > > > > > > supposed to be...
> > > > > > > >
> > > > > > > > Gary
> > > > > > > >
> > > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker  
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Are the Windows headers even available when using Ming32 or
> > > > Cygwin?
> > > > > > > > > That sounds more like a Visual Studio compiler thing.
> > > > > > > > >
> > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory <
> > > > garydgreg...@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > The challenge is getting everything set up just right for
> > > > building
> > > > > > > the
> > > > > > > > > > various OS profiles. This component is quite different in 
> > > > > > > > > > this
> > > > > > > regard,
> > > > > > > > > > getting help from the original contributors would be 
> > > > > > > > > > helpful.
> > > > > > > > > >
> > > > > > > > > > After much fiddling to install the proper packages, this
> > > > builds OK:
> > > > > > > > > >
> > > > > > > > > > mvn package -DskipTests -P linux64
> > > > > > > > > > mvn package -DskipTests -P linux32
> > > > > > > > > >
> > > > > > > > > > But these do not:
> > > > > > > > > > mvn package -DskipTests -P win64
> > > > > >

RE: [Text] do we have number to word converter ?

2020-06-30 Thread Jason Pyeron

> -Original Message-
> From: sebb 
> Sent: Tuesday, June 30, 2020 4:03 PM
> 
> On Tue, 30 Jun 2020 at 19:47, Jason Pyeron wrote:
> >
> > > -Original Message-
> > > From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM
> > >
> > > Hi,
> > >
> > > Does anyone know if apache commons have any utility which converts number
> > > to words ?
> > >
> > > Ex. 3957 = Three Thousand Nine Hundred and fifty seven.
> >
> > If not, can dig up the one we made for united states (English) checks and 
> > donate it to Apache.
> 
> Seems simple, but I think this is going to be a huge amount of work to 
> maintain.
> 
> Even English will require at least two versions as the US and UK don't agree.

Yep, that’s why I mentioned United States English on bank checks.

> 
> Also numbers are spoken differently depending on context.

That seems ignorable or selectable.

> For example quantities and dates.
> Then there are phone numbers.
> 
> I think this is out of scope for Commons.

Sadly, but likely due to the maintainability.

You cannot just translate the words and be done. The rules for construction 
change with languages too.


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

Re: [Text] do we have number to word converter ?

2020-06-30 Thread Amey Jadiye

On Wed, Jul 1, 2020 at 1:18 AM Gary Gregory  wrote:

> I am not sure we should have something so language dependent here. Making
> it plugable feels out of scope with one resource bundle per language and so
> on. Might be worth seeing how java.time deals with this kind of issue if at
> all.
>

java.time internally uses DateTimeFormatter[1] and that internally
uses  Locale[2]

I think we can create the Utility with default English and provision to
plugin different Locale.

[1]
https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html
[2]https://docs.oracle.com/javase/8/docs/api/java/util/Locale.html

Regards,
Amey

>
>
> Gary
>
> On Tue, Jun 30, 2020, 14:47 Jason Pyeron  wrote:
>
> > > -Original Message-
> > > From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM
> > >
> > > Hi,
> > >
> > > Does anyone know if apache commons have any utility which converts
> number
> > > to words ?
> > >
> > > Ex. 3957 = Three Thousand Nine Hundred and fifty seven.
> >
> > If not, can dig up the one we made for united states (English) checks and
> > donate it to Apache.
> >
> >
> >
> > -
> > 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: [Text] do we have number to word converter ?

2020-06-30 Thread Jason Pyeron

> -Original Message-
> From: Gary Gregory Sent: Tuesday, June 30, 2020 3:49 PM
> 
> I am not sure we should have something so language dependent here. Making
> it plugable feels out of scope with one resource bundle per language and so

Meh, it has no home on the internet.

Maybe org.apache.commons.text.translate or org.apache.commons.text as I found 
no better place on any other project.

> on. Might be worth seeing how java.time deals with this kind of issue if at
> all.

Grepping on my checkout of openjdk in java.time shows no instance of "twelve" 
or "thirteen". I have a grep on the entire code base, but I suspect there will 
be no useful hits.

> 
> Gary
> 
> On Tue, Jun 30, 2020, 14:47 Jason Pyeron  wrote:
> 
> > > -Original Message-
> > > From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM
> > >
> > > Hi,
> > >
> > > Does anyone know if apache commons have any utility which converts number
> > > to words ?
> > >
> > > Ex. 3957 = Three Thousand Nine Hundred and fifty seven.
> >
> > If not, can dig up the one we made for united states (English) checks and
> > donate it to Apache.
> >
> >
> >
> > -
> > 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: [Text] do we have number to word converter ?

2020-06-30 Thread Melloware




On 6/30/2020 4:02 PM, sebb wrote:

I think this is out of scope for Commons.


Agreed this feels like a good Stack Overflow post that people can then 
take and modify for their own language or needs.



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

Re: [Text] do we have number to word converter ?

2020-06-30 Thread sebb

On Tue, 30 Jun 2020 at 19:47, Jason Pyeron  wrote:
>
> > -Original Message-
> > From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM
> >
> > Hi,
> >
> > Does anyone know if apache commons have any utility which converts number
> > to words ?
> >
> > Ex. 3957 = Three Thousand Nine Hundred and fifty seven.
>
> If not, can dig up the one we made for united states (English) checks and 
> donate it to Apache.

Seems simple, but I think this is going to be a huge amount of work to maintain.

Even English will require at least two versions as the US and UK don't agree.

Also numbers are spoken differently depending on context.
For example quantities and dates.
Then there are phone numbers.

I think this is out of scope for Commons.

>
>
> -
> 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: [Text] do we have number to word converter ?

2020-06-30 Thread Gary Gregory

I am not sure we should have something so language dependent here. Making
it plugable feels out of scope with one resource bundle per language and so
on. Might be worth seeing how java.time deals with this kind of issue if at
all.

Gary

On Tue, Jun 30, 2020, 14:47 Jason Pyeron  wrote:

> > -Original Message-
> > From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM
> >
> > Hi,
> >
> > Does anyone know if apache commons have any utility which converts number
> > to words ?
> >
> > Ex. 3957 = Three Thousand Nine Hundred and fifty seven.
>
> If not, can dig up the one we made for united states (English) checks and
> donate it to Apache.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DBCP] poolPreparedStatements

2020-06-30 Thread Phil Steitz




On 6/29/20 12:17 PM, Robert Paschek wrote:

Hello,

DBCP has a feature to pool PreparedStatements for the lifetime of a connection.
This results in cursors being open and locks in the database for a long time, 
which could cause problems with administrative tasks in the database. That why 
I would prefer this pool to be more short-living, that means that the pool is 
filled while the application is using the connection und cleared when the 
application is returning the connection to the ConnectionPool. This way the 
application can still benefit from the Statement-cache in mass operations, 
without creating headaches for database admins.

I would suggest an additional setting like 
limitPreparedStatementPoolToConnectionUse or something similar.

What do you think?

Regards,
Robert


One way to workaround the need to periodically clean up would be to 
either set maximum lifetimes on connections or periodically invalidate 
them.  That would force the underlying PoolingConnections to be closed, 
which would in turn cause the statement pools to be closed.


The feature request sounds reasonable to me.  For anyone interested in 
creating a patch to implement this, here is a way that might work to 
implement it:


Connections that pool statements are PoolingConnections.  Add a property 
to this class to determine whether or not to clear the statement pool 
when a connection is returned to the pool. Override 
DelegatingConnnection's passivate method to first call super() but then 
examine the property and if so configured, clear (not close) the 
statement pool.  Modify PoolableConnectionFactory to set the property 
and BasicDataSource to pass it in.


Probably best to open a JIRA for this.  I don't have time to work on it 
now, but I would be willing to review PRs.


Phil





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

RE: [Text] do we have number to word converter ?

2020-06-30 Thread Jason Pyeron

> -Original Message-
> From: Amey Jadiye Sent: Tuesday, June 30, 2020 2:04 PM
> 
> Hi,
> 
> Does anyone know if apache commons have any utility which converts number
> to words ?
> 
> Ex. 3957 = Three Thousand Nine Hundred and fifty seven.

If not, can dig up the one we made for united states (English) checks and 
donate it to Apache.



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

Re: Apache Commons Geometry Release

2020-06-30 Thread Gilles Sadowski

Hello.

Le mar. 30 juin 2020 à 18:29, Matt Juntunen  a écrit :
>
> Hi Baljit,
>
> The only things keeping the release from happening at this time are
>
>   1.  the legal issue of including a 3D model which I opened a ticket for in 
> JIRA yesterday [1], and

It doesn't look like this site
https://s2018.siggraph.org/3d-model-portal/
tries hard to prevent use of their (?) data. ;-)

>   2.  the tutorial requested in GEOMETRY-95.
>
> The first issue I can solve easily by just not including that model and just 
> using one that I make myself. It won't be as good but it would work. As for 
> the second issue, I'm working on the tutorial right now and hope to be done 
> within the next week or so. However, I wouldn't have a problem releasing 
> beta1 without it, assuming that Gilles and others are on board with that.
>
> Gilles, WDYT?

It would be great to release "beta1"; the mentioned items can
of course be added later.

Best,
Gilles

>>> [...]

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

[Text] do we have number to word converter ?

2020-06-30 Thread Amey Jadiye

Hi,

Does anyone know if apache commons have any utility which converts number
to words ?

Ex. 3957 = Three Thousand Nine Hundred and fifty seven.

Regards,
Amey

Re: Apache Commons Geometry Release

2020-06-30 Thread Matt Juntunen

Hi Baljit,

The only things keeping the release from happening at this time are

  1.  the legal issue of including a 3D model which I opened a ticket for in 
JIRA yesterday [1], and
  2.  the tutorial requested in GEOMETRY-95.

The first issue I can solve easily by just not including that model and just 
using one that I make myself. It won't be as good but it would work. As for the 
second issue, I'm working on the tutorial right now and hope to be done within 
the next week or so. However, I wouldn't have a problem releasing beta1 without 
it, assuming that Gilles and others are on board with that.

Gilles, WDYT?

Regards,
Matt

[1] https://issues.apache.org/jira/projects/LEGAL/issues/LEGAL-525

From: Singh, Baljit (GE Aviation, US) 
Sent: Tuesday, June 30, 2020 10:59 AM
To: Matt Juntunen ; Gilles Sadowski 
; dev@commons.apache.org 
Subject: Re: Apache Commons Geometry Release

Matt,

Can someone release the beta? I can migrate our test environment, and report 
back if any new or known Math3 issues are still present.

Regards,
Baljit

From: Matt Juntunen 
Date: Tuesday, May 26, 2020 at 9:57 AM
To: "Singh, Baljit (GE Aviation, US)" , Gilles Sadowski 
, "dev@commons.apache.org" 
Subject: EXT: Re: Apache Commons Geometry Release

Hi Bajit,

My plan is to get a release of commons-geometry out as soon as possible, 
although I have been saying this for more than a year at this point:-) However, 
I actually believe we are very close now. There are only a few remaining issues 
for the beta1 release and I currently have branches ready to merge for most of 
them. The following issues are ready and waiting for merge:
-GEOMETRY-94: This adds Triangle3D and ConvexPolygon3D types, which are 
essentially required for working with 3D models. I have a PR in [1] and am just 
waiting another day or so to see if anyone has any feedback.
-GEOMETRY-77: Adds useful Bounds2D and Bounds3D classes. This is included in 
the PR mentioned above.
-GEOMETRY-97: Changes from using the term "barycenter" to "centroid" for 
describing the geometric center of objects. This is ready and waiting in the 
wings for when the PR above is merged.

The following issues are not complete:
-GEOMETRY-50: Bug report submitted by you quite a while ago regarding overflow 
in norm calculations. This is a tiny change in the code and I think we can just 
go ahead and do it. However, I did find one small issue that I'd like to 
discuss more that I put in the comments there yesterday.
-GEOMETRY-95: This is a request from Gilles to add a tutorial or more detailed 
step-by-step user guide on how to use the library to perform constructive solid 
geometry operations. We are currently discussing exactly what this means in the 
comments on the issue.  There would be some minor development work needed on 
this but it will most likely be in one of the examples modules and not in the 
main library. The main thing I can think of that we'd need would be a 3D model 
file reader for some format. I'm picturing using the obj format since we 
already have a writer for that.

These are the only remaining issues I see for the beta1 release, so things are 
very close. I would also like to use this library in my day job, so the sooner 
we can get it out the better.

Regards,
Matt J

[1] https://github.com/apache/commons-geometry/pull/77

From: Singh, Baljit (GE Aviation, US) 
Sent: Tuesday, May 26, 2020 9:20 AM
To: Gilles Sadowski ; dev@commons.apache.org 

Cc: mattjuntu...@apache.org 
Subject: Re: Apache Commons Geometry Release

Gilles,
Thanks for replying. I do not know (yet) if Commons Geometry has the same 
issues (or even other issues), but I would rather use something being actively 
developed vs. something that is EOL (Commons-Math3 v3.6.1 was released 4+ years 
ago). At least this way, I can report/fix any bugs and get the improvements 
with the new releases. And yes, I'm willing to be the first test subject. __  I 
would love to help with more improvements, but if there is no sight for the 
releases and the library thus cannot be used, I can't justify spending time on 
it.

Commons Devs,
Adding the Commons Dev ML per Gilles's request. In the email below, I asked 
when the first release of Commons Geometry will be. Some context (and intro): 
using Commons-Math3, I write geometry algorithms for our UAV flight management 
product at AiRXOS (part of GE Aviation). However, I'm discovering bugs in 
Commons-Math3, one of which I helped fix in Commons Geometry. I would like to 
use Commons Geometry instead (for reasons mentioned above).

Regards,
Baljit

On 5/21/20, 9:02 PM, "Gilles Sadowski"  wrote:

Hello.

2020-05-21 20:32 UTC+02:00, Singh, Baljit (GE Aviation, US) 
:
> Hi Matt, Gilles,
>
> Any updates on when the commons-geometry release is going to be?

The question is of general interest.  Could you please post it
to the "dev" ML?

> I’m finding
> more and more

Re: Apache Commons Geometry Release

2020-06-30 Thread Singh, Baljit (GE Aviation, US)

Matt,

Can someone release the beta? I can migrate our test environment, and report 
back if any new or known Math3 issues are still present.

Regards,
Baljit

From: Matt Juntunen 
Date: Tuesday, May 26, 2020 at 9:57 AM
To: "Singh, Baljit (GE Aviation, US)" , Gilles Sadowski 
, "dev@commons.apache.org" 
Subject: EXT: Re: Apache Commons Geometry Release

Hi Bajit,

My plan is to get a release of commons-geometry out as soon as possible, 
although I have been saying this for more than a year at this point:-) However, 
I actually believe we are very close now. There are only a few remaining issues 
for the beta1 release and I currently have branches ready to merge for most of 
them. The following issues are ready and waiting for merge:
-GEOMETRY-94: This adds Triangle3D and ConvexPolygon3D types, which are 
essentially required for working with 3D models. I have a PR in [1] and am just 
waiting another day or so to see if anyone has any feedback.
-GEOMETRY-77: Adds useful Bounds2D and Bounds3D classes. This is included in 
the PR mentioned above.
-GEOMETRY-97: Changes from using the term "barycenter" to "centroid" for 
describing the geometric center of objects. This is ready and waiting in the 
wings for when the PR above is merged.

The following issues are not complete:
-GEOMETRY-50: Bug report submitted by you quite a while ago regarding overflow 
in norm calculations. This is a tiny change in the code and I think we can just 
go ahead and do it. However, I did find one small issue that I'd like to 
discuss more that I put in the comments there yesterday.
-GEOMETRY-95: This is a request from Gilles to add a tutorial or more detailed 
step-by-step user guide on how to use the library to perform constructive solid 
geometry operations. We are currently discussing exactly what this means in the 
comments on the issue.  There would be some minor development work needed on 
this but it will most likely be in one of the examples modules and not in the 
main library. The main thing I can think of that we'd need would be a 3D model 
file reader for some format. I'm picturing using the obj format since we 
already have a writer for that.

These are the only remaining issues I see for the beta1 release, so things are 
very close. I would also like to use this library in my day job, so the sooner 
we can get it out the better.

Regards,
Matt J

[1] https://github.com/apache/commons-geometry/pull/77

From: Singh, Baljit (GE Aviation, US) 
Sent: Tuesday, May 26, 2020 9:20 AM
To: Gilles Sadowski ; dev@commons.apache.org 

Cc: mattjuntu...@apache.org 
Subject: Re: Apache Commons Geometry Release

Gilles,
Thanks for replying. I do not know (yet) if Commons Geometry has the same 
issues (or even other issues), but I would rather use something being actively 
developed vs. something that is EOL (Commons-Math3 v3.6.1 was released 4+ years 
ago). At least this way, I can report/fix any bugs and get the improvements 
with the new releases. And yes, I'm willing to be the first test subject. __  I 
would love to help with more improvements, but if there is no sight for the 
releases and the library thus cannot be used, I can't justify spending time on 
it.

Commons Devs,
Adding the Commons Dev ML per Gilles's request. In the email below, I asked 
when the first release of Commons Geometry will be. Some context (and intro): 
using Commons-Math3, I write geometry algorithms for our UAV flight management 
product at AiRXOS (part of GE Aviation). However, I'm discovering bugs in 
Commons-Math3, one of which I helped fix in Commons Geometry. I would like to 
use Commons Geometry instead (for reasons mentioned above).

Regards,
Baljit

On 5/21/20, 9:02 PM, "Gilles Sadowski"  wrote:

Hello.

2020-05-21 20:32 UTC+02:00, Singh, Baljit (GE Aviation, US) 
:
> Hi Matt, Gilles,
>
> Any updates on when the commons-geometry release is going to be?

The question is of general interest.  Could you please post it
to the "dev" ML?

> I’m finding
> more and more issues with the package
> org.apache.commons.math3.geometry.spherical.twod, and its causing issues
> with our product.

Is the code in "Commons Geometry" free of those issues?
It would be nice to have unit tests that check those cases.

> I would like to upgrade to something that is actively
> being developed.

Sure.
So, you are user number "1" (?). ;-)

> Looking at JIRA, it looks like the release is almost ready,
> only 3 (minor) issues to go.

If you can help with those...

Thanks,
Gilles

> Regards,
> Baljit
>
>
>

Re: JDK 15 is in Rampdown Phase One

2020-06-30 Thread Xeno Amess

Great, thanks!

Rory O'Donnell  于2020年6月30日周二 下午4:25写道：

> Hi Xeno,
>
> The bug has moved into the Java Bug System (JBS) - JDK-8248434
> 
>
> I have added the "apache-maven-found" label to the bug.
>
> Rgds,Rory
> On 26/06/2020 13:18, Rory O'Donnell wrote:
>
> Thanks Xeno!
>
> Will let you know if anything else required.
>
> Rgds,Rory
>
> On 26/06/2020 13:15, Xeno Amess wrote:
>
> Hi.
> I submitted the bug(or issue) on bugs.java.com 
>  as you requested.
> And it said internal review ID : 9065633. on the wabpage.
> If there anything else I should do please let me know.
>
> Rory O'Donnell mailto:rory.odonn...@oracle.com>
> > 于2020年6月26日周五 下午7:27写道：
>
> Hi Rob,
>
> Thanks, we are waiting for a bug report to be logged by Xeno.
>
> Rgds,Rory
>
> On 26/06/2020 11:10, Rob Tompkins wrote:
> > Hi Rory,
> >
> > @XenoAmess (GitHub) found an error in our DateParser related to
> the addition of a locale called “ff_LR#Adlm,” which we’re tracking
> here: https://github.com/apache/commons-lang/pull/558
> 
> 
> >
> > We wanted to let you know.
> >
> > Cheers,
> > -Rob
> >
> >> On Jun 22, 2020, at 11:46 AM, Rory O'Donnell
> mailto:rory.odonn...@oracle.com>
> > wrote:
> >>
> >>
> >> Hi Benedikt,
> >>
> >> *Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] *
> >>
> >> *Please advise if you find any issues while testing the latest
> Early Access builds.
> >> *
> >>
> >> * Schedule for JDK 15
> >>  o *2020/06/11 Rampdown Phase One*
> >>  o 2020/07/16 Rampdown Phase Two
> >>  o 2020/08/06 Initial Release Candidate
> >>  o 2020/08/20 Final Release Candidate
> >>  o 2020/09/15 General Availability
> >>
> >> * Features included in JDK 15:
> >>  o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
> >>
> 
> >>  o JEP 360: Sealed Classes (Preview)
>  
> >>  o JEP 371: Hidden Classes 
> 
> >>  o JEP 372: Remove the Nashorn JavaScript Engine
> >>
> 
> >>  o JEP 373: Reimplement the Legacy DatagramSocket API
> >>
> 
> >>  o JEP 374: Disable and Deprecate Biased Locking
> >>
> 
> >>  o JEP 375: Pattern Matching for instanceof (Second Preview)
> >>
> 
> >>  o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
> >>
> 
> >>  o JEP 378: Text Blocks 
> 
> >>  o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
> >>
> 
> >>  o JEP 381: Remove the Solaris and SPARC Ports
> >>
> 
> >>  o JEP 383: Foreign-Memory Access API (Second Incubator)
> >>
> 
> >>  o JEP 384: Records (Second Preview)
> >>
> 
> >>  o JEP 385: Deprecate RMI Activation for Removal
> >>
> 
> >>
> >> *JDK 15 **Early Access build 28 **is available**at : -
> jdk.java.net/15/* 
> 
> >>
> >> These early-access, open-source builds are provided under the
> GNU General Public License, version 2, with the Classpath
> Exception**Release notes
> >>
> >> * Release notes
> >>  o http://jdk.java.net/15/release-notes
> >> * Recent fixes that might be of interest
> >>  o Build 27
> >>  + JDK-8233215: jpackage doesn't allow enough
> flexibility for
> >>file type binding
> >>  + JDK-8244582: Remove terminally deprecated
> Solaris-specific
> >>SO_FLOW_SLA socket option
> >>  + JDK-8245068: Implement Deprecation of RMI Activation
> >>  + JDK-8246770: Atomic::add() with 64 bit value fails
> to link
> >>on 32-bit

Re: JDK 15 is in Rampdown Phase One

2020-06-30 Thread Rory O'Donnell


Hi Xeno,

The bug has moved into the Java Bug System (JBS) - JDK-8248434 



I have added the "apache-maven-found" label to the bug.

Rgds,Rory

On 26/06/2020 13:18, Rory O'Donnell wrote:

Thanks Xeno!

Will let you know if anything else required.

Rgds,Rory

On 26/06/2020 13:15, Xeno Amess wrote:

Hi.
I submitted the bug(or issue) on bugs.java.com 
 as you requested.

And it said internal review ID : 9065633. on the wabpage.
If there anything else I should do please let me know.

Rory O'Donnell > 于2020年6月26日周五 下午7:27写道：


    Hi Rob,

    Thanks, we are waiting for a bug report to be logged by Xeno.

    Rgds,Rory

    On 26/06/2020 11:10, Rob Tompkins wrote:
    > Hi Rory,
    >
    > @XenoAmess (GitHub) found an error in our DateParser related to
    the addition of a locale called “ff_LR#Adlm,” which we’re tracking
    here: https://github.com/apache/commons-lang/pull/558
    
    >
    > We wanted to let you know.
    >
    > Cheers,
    > -Rob
    >
    >> On Jun 22, 2020, at 11:46 AM, Rory O'Donnell
    mailto:rory.odonn...@oracle.com>> wrote:
    >>
    >>
    >> Hi Benedikt,
    >>
    >> *Per the JDK 15 schedule , we are in Rampdown Phase One* *[1] *
    >>
    >> *Please advise if you find any issues while testing the latest
    Early Access builds.
    >> *
    >>
    >> * Schedule for JDK 15
    >>      o *2020/06/11 Rampdown Phase One*
    >>      o 2020/07/16 Rampdown Phase Two
    >>      o 2020/08/06 Initial Release Candidate
    >>      o 2020/08/20 Final Release Candidate
    >>      o 2020/09/15 General Availability
    >>
    >> * Features included in JDK 15:
    >>      o JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)
    >>        
    >>      o JEP 360: Sealed Classes (Preview)
    
    >>      o JEP 371: Hidden Classes 
    >>      o JEP 372: Remove the Nashorn JavaScript Engine
    >>        
    >>      o JEP 373: Reimplement the Legacy DatagramSocket API
    >>        
    >>      o JEP 374: Disable and Deprecate Biased Locking
    >>        
    >>      o JEP 375: Pattern Matching for instanceof (Second Preview)
    >>        
    >>      o JEP 377: ZGC: A Scalable Low-Latency Garbage Collector
    >>        
    >>      o JEP 378: Text Blocks 
    >>      o JEP 379: Shenandoah: A Low-Pause-Time Garbage Collector
    >>        
    >>      o JEP 381: Remove the Solaris and SPARC Ports
    >>        
    >>      o JEP 383: Foreign-Memory Access API (Second Incubator)
    >>        
    >>      o JEP 384: Records (Second Preview)
    >>        
    >>      o JEP 385: Deprecate RMI Activation for Removal
    >>        
    >>
    >> *JDK 15 **Early Access build 28 **is available**at : -
    jdk.java.net/15/* 
    >>
    >> These early-access, open-source builds are provided under the
    GNU General Public License, version 2, with the Classpath
    Exception**Release notes
    >>
    >> * Release notes
    >>      o http://jdk.java.net/15/release-notes
    >> * Recent fixes that might be of interest
    >>      o Build 27
    >>          + JDK-8233215: jpackage doesn't allow enough
    flexibility for
    >>            file type binding
    >>          + JDK-8244582: Remove terminally deprecated
    Solaris-specific
    >>            SO_FLOW_SLA socket option
    >>          + JDK-8245068: Implement Deprecation of RMI Activation
    >>          + JDK-8246770: Atomic::add() with 64 bit value fails
    to link
    >>            on 32-bit platforms
    >>              # Reported by JaCoCo
    >>      o Build 26
    >>          + JDK-8240871: SSLEngine handshake status immediately
    after
    >>            the handshake can be NOT_HANDSHAKING rather than
    FINISHED
    >>            with TLSv1.3
    >>              # Reported by Apache Tomcat
    >>      o Build 25
    >>          + JDK-8206925: Support the certificate_authorities
    extension
    >>          + JDK-8239480: Support for CLDR version 37
    >>          + JDK-8243925: Toolkit#getScreenInsets() returns wrong
    value
    >>            on HiDPI screens (Windows)
    >>
    >> *JDK 16 Early Access build 2 is available**at : -
    jdk.java.net/16/* 
    >>
    >> These early-access, open-source builds are provided under the
    GNU General Public License, version 2, with the Classpath 
Exception.*

    >> *
    >>
    >>

Re: [crypto] New Release

[test] Bug in StringSubstitutor?

Re: [DBCP] poolPreparedStatements

Re: [DBCP] poolPreparedStatements

Re: Apache Commons Geometry Release

Re: [DBCP] poolPreparedStatements

Re: [DBCP] poolPreparedStatements

Re: [crypto] New Release

RE: [Text] do we have number to word converter ?

Re: [Text] do we have number to word converter ?

RE: [Text] do we have number to word converter ?

Re: [Text] do we have number to word converter ?

Re: [Text] do we have number to word converter ?

Re: [Text] do we have number to word converter ?

Re: [DBCP] poolPreparedStatements

RE: [Text] do we have number to word converter ?

Re: Apache Commons Geometry Release

[Text] do we have number to word converter ?

Re: Apache Commons Geometry Release

Re: Apache Commons Geometry Release

Re: JDK 15 is in Rampdown Phase One

Re: JDK 15 is in Rampdown Phase One

22 matches

Site Navigation

Mail list logo

Footer information