opinions about @NotNull and @Nullable ?

[Xeno Amess]

I want to know about your opinions about @NotNull and @Nullable.

Should we use it in every function?
Or we use it  only at some misleading places?
Or simply not use them at all?

thx.

Re: [crypto] Help Releasing new Commons Crypto

[Geoffrey Blake]

I figure everyone is a bit busy, but wanted to ask where we are all in
getting close to a new release of commons-crypto that contains the new
binaries, Alex, Gary?  Any other unit test areas that need attention
Alex that you may need help with?

-Geoff

On Wed, Apr 22, 2020 at 11:33 AM Adam Retter
 wrote:
>
> If you want to build on CentOS for releases that is fine - I can add
> Docker Build Environments as a Travis job that use older CentOS.
>
> On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake  
> wrote:
> >
> > I think it depends on whether using Ubuntu 14.04/16.04 as the base
> > distro for releases is ok.  It seems most projects like to build on
> > some variant of RHEL/CentOS as they typically use stable (read older)
> > compilers and libc.
> >
> > Does Travis allow building all the binaries then having a final
> > process that gathers all the artifacts up in the end to perform the
> > release?
> >
> > @garydgregory, thoughts on this?
> >
> > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter
> >  wrote:
> > >
> > > No that https://github.com/apache/commons-crypto/pull/96 has been
> > > merged, we have support for Arm64, ppc64le and x64 in Travis.
> > >
> > > I wondered if it was useful for the "Release Process" if we had Travis
> > > build and store release artifacts? I believe we can have Travis do
> > > this only when Git tags are created. So if there is a Tag for each
> > > release (which I assume there is) - then you could have the release
> > > binaries built and delivered automatically for you. It is possible to
> > > go as far as having them uploaded to Maven Central (staging) if you
> > > wished.
> > >
> > > On Sat, 18 Apr 2020 at 17:40, Adam Retter  
> > > wrote:
> > > >
> > > > As promised, I added support for further environments to Travis -
> > > > https://github.com/apache/commons-crypto/pull/96
> > > >
> > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily  wrote:
> > > > >
> > > > > I don't know whether it would help the build manager with the release
> > > > > process, but I think it would be a good idea to update the build 
> > > > > matrix
> > > > > regardless.  I made an attempt a while ago to add coverage for more
> > > > > environments, but ultimately I wasn't successful.  I don't recall if 
> > > > > the
> > > > > limitations were Travis's or my own, but I would certainly welcome 
> > > > > someone
> > > > > fleshing out the build matrix to test against OpenSSL 1.0 and 1.1 
> > > > > APIs in
> > > > > whatever Windows, Mac, Linux and Arm64 environments Travis supports.  
> > > > > My
> > > > > $0.02.
> > > > >
> > > > > Alex
> > > > >
> > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> > > > >  wrote:
> > > > >
> > > > > > Travis now offer Arm64 and Mac. I could setup a job to build 
> > > > > > binaries on
> > > > > > Travis and keep a copy either on every commit or when a tag is 
> > > > > > created.
> > > > > > Would that be helpful?
> > > > > >
> > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory,  
> > > > > > wrote:
> > > > > >
> > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily 
> > > > > > > 
> > > > > > wrote:
> > > > > > >
> > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so I'm 
> > > > > > > > happy to
> > > > > > > > provide whichever of those is required.  It seems that Geoff 
> > > > > > > > can do the
> > > > > > > > arm64 build.  Do we even bother supporting 32 bit architectures 
> > > > > > > > at this
> > > > > > > > point?
> > > > > > > >
> > > > > > >
> > > > > > > Unfortunately, we cannot just pick up bits from folks here and 
> > > > > > > there. It
> > > > > > > all has to be buildable from Maven by the release manager in 
> > > > > > > order to
> > > > > > > generate the file signatures properly.
> > > > > > >
> > > > > > > Based on what I see in the docs, it looks like this is buildable 
> > > > > > > using
> > > > > > > cross-compilation with MinGW on Windows. Not sure about the Mac 
> > > > > > > stuff
> > > > > > yet.
> > > > > > >
> > > > > > > I'm not sure what the use-case is for 32-bit at this point.
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > >
> > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin 
> > > > > > > > 
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Gary,
> > > > > > > > >
> > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory 
> > > > > > > > >  > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > The 1.0 release on maven central only included linux32 and
> > > > > > linux64
> > > > > > > > > native
> > > > > > > > > > > libs, even though the Makefile supports many more targets
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Please see the snapshot builds which now include more:
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-crypto/1.1.0-SNAPSHOT
> > > > > > > > >
> > > > > > > > > Here's the native stuff in your snapshot jar:
> > > > > > 

Re: [crypto] Help Releasing new Commons Crypto

[Alex Remily]

I hope to have a PR in this weekend sometime with an increase in code
coverage for streams.  I haven't touched anything else yet, so any other
package is fair game.

On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake 
wrote:

> I figure everyone is a bit busy, but wanted to ask where we are all in
> getting close to a new release of commons-crypto that contains the new
> binaries, Alex, Gary?  Any other unit test areas that need attention
> Alex that you may need help with?
>
> -Geoff
>
> On Wed, Apr 22, 2020 at 11:33 AM Adam Retter
>  wrote:
> >
> > If you want to build on CentOS for releases that is fine - I can add
> > Docker Build Environments as a Travis job that use older CentOS.
> >
> > On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake 
> wrote:
> > >
> > > I think it depends on whether using Ubuntu 14.04/16.04 as the base
> > > distro for releases is ok.  It seems most projects like to build on
> > > some variant of RHEL/CentOS as they typically use stable (read older)
> > > compilers and libc.
> > >
> > > Does Travis allow building all the binaries then having a final
> > > process that gathers all the artifacts up in the end to perform the
> > > release?
> > >
> > > @garydgregory, thoughts on this?
> > >
> > > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter
> > >  wrote:
> > > >
> > > > No that https://github.com/apache/commons-crypto/pull/96 has been
> > > > merged, we have support for Arm64, ppc64le and x64 in Travis.
> > > >
> > > > I wondered if it was useful for the "Release Process" if we had
> Travis
> > > > build and store release artifacts? I believe we can have Travis do
> > > > this only when Git tags are created. So if there is a Tag for each
> > > > release (which I assume there is) - then you could have the release
> > > > binaries built and delivered automatically for you. It is possible to
> > > > go as far as having them uploaded to Maven Central (staging) if you
> > > > wished.
> > > >
> > > > On Sat, 18 Apr 2020 at 17:40, Adam Retter <
> adam.ret...@googlemail.com> wrote:
> > > > >
> > > > > As promised, I added support for further environments to Travis -
> > > > > https://github.com/apache/commons-crypto/pull/96
> > > > >
> > > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily 
> wrote:
> > > > > >
> > > > > > I don't know whether it would help the build manager with the
> release
> > > > > > process, but I think it would be a good idea to update the build
> matrix
> > > > > > regardless.  I made an attempt a while ago to add coverage for
> more
> > > > > > environments, but ultimately I wasn't successful.  I don't
> recall if the
> > > > > > limitations were Travis's or my own, but I would certainly
> welcome someone
> > > > > > fleshing out the build matrix to test against OpenSSL 1.0 and
> 1.1 APIs in
> > > > > > whatever Windows, Mac, Linux and Arm64 environments Travis
> supports.  My
> > > > > > $0.02.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> > > > > >  wrote:
> > > > > >
> > > > > > > Travis now offer Arm64 and Mac. I could setup a job to build
> binaries on
> > > > > > > Travis and keep a copy either on every commit or when a tag is
> created.
> > > > > > > Would that be helpful?
> > > > > > >
> > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, <
> garydgreg...@gmail.com> wrote:
> > > > > > >
> > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily <
> alex.rem...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so
> I'm happy to
> > > > > > > > > provide whichever of those is required.  It seems that
> Geoff can do the
> > > > > > > > > arm64 build.  Do we even bother supporting 32 bit
> architectures at this
> > > > > > > > > point?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Unfortunately, we cannot just pick up bits from folks here
> and there. It
> > > > > > > > all has to be buildable from Maven by the release manager in
> order to
> > > > > > > > generate the file signatures properly.
> > > > > > > >
> > > > > > > > Based on what I see in the docs, it looks like this is
> buildable using
> > > > > > > > cross-compilation with MinGW on Windows. Not sure about the
> Mac stuff
> > > > > > > yet.
> > > > > > > >
> > > > > > > > I'm not sure what the use-case is for 32-bit at this point.
> > > > > > > >
> > > > > > > > Gary
> > > > > > > >
> > > > > > > >
> > > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin <
> van...@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Gary,
> > > > > > > > > >
> > > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory <
> garydgreg...@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > The 1.0 release on maven central only included
> linux32 and
> > > > > > > linux64
> > > > > > > > > > native
> > > > > > > > > > > > libs, even though the Makefile supports many more
> targets
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 

Re: [crypto] Help Releasing new Commons Crypto

[Gary Gregory]

On Fri, Apr 24, 2020 at 12:16 PM Geoffrey Blake 
wrote:

> I figure everyone is a bit busy, but wanted to ask where we are all in
> getting close to a new release of commons-crypto that contains the new
> binaries, Alex, Gary?  Any other unit test areas that need attention
> Alex that you may need help with?
>

I hope to take a look at the state of the component at the weekend, but I
am not thinking of being able to cut an RC yet. It seems we still have
build issues. I need to catch up on PRs and emails...

Gary


>
> -Geoff
>
> On Wed, Apr 22, 2020 at 11:33 AM Adam Retter
>  wrote:
> >
> > If you want to build on CentOS for releases that is fine - I can add
> > Docker Build Environments as a Travis job that use older CentOS.
> >
> > On Wed, 22 Apr 2020 at 18:02, Geoffrey Blake 
> wrote:
> > >
> > > I think it depends on whether using Ubuntu 14.04/16.04 as the base
> > > distro for releases is ok.  It seems most projects like to build on
> > > some variant of RHEL/CentOS as they typically use stable (read older)
> > > compilers and libc.
> > >
> > > Does Travis allow building all the binaries then having a final
> > > process that gathers all the artifacts up in the end to perform the
> > > release?
> > >
> > > @garydgregory, thoughts on this?
> > >
> > > On Wed, Apr 22, 2020 at 3:39 AM Adam Retter
> > >  wrote:
> > > >
> > > > No that https://github.com/apache/commons-crypto/pull/96 has been
> > > > merged, we have support for Arm64, ppc64le and x64 in Travis.
> > > >
> > > > I wondered if it was useful for the "Release Process" if we had
> Travis
> > > > build and store release artifacts? I believe we can have Travis do
> > > > this only when Git tags are created. So if there is a Tag for each
> > > > release (which I assume there is) - then you could have the release
> > > > binaries built and delivered automatically for you. It is possible to
> > > > go as far as having them uploaded to Maven Central (staging) if you
> > > > wished.
> > > >
> > > > On Sat, 18 Apr 2020 at 17:40, Adam Retter <
> adam.ret...@googlemail.com> wrote:
> > > > >
> > > > > As promised, I added support for further environments to Travis -
> > > > > https://github.com/apache/commons-crypto/pull/96
> > > > >
> > > > > On Mon, 13 Apr 2020 at 16:35, Alex Remily 
> wrote:
> > > > > >
> > > > > > I don't know whether it would help the build manager with the
> release
> > > > > > process, but I think it would be a good idea to update the build
> matrix
> > > > > > regardless.  I made an attempt a while ago to add coverage for
> more
> > > > > > environments, but ultimately I wasn't successful.  I don't
> recall if the
> > > > > > limitations were Travis's or my own, but I would certainly
> welcome someone
> > > > > > fleshing out the build matrix to test against OpenSSL 1.0 and
> 1.1 APIs in
> > > > > > whatever Windows, Mac, Linux and Arm64 environments Travis
> supports.  My
> > > > > > $0.02.
> > > > > >
> > > > > > Alex
> > > > > >
> > > > > > On Mon, Apr 13, 2020 at 2:53 AM Adam Retter
> > > > > >  wrote:
> > > > > >
> > > > > > > Travis now offer Arm64 and Mac. I could setup a job to build
> binaries on
> > > > > > > Travis and keep a copy either on every commit or when a tag is
> created.
> > > > > > > Would that be helpful?
> > > > > > >
> > > > > > > On Mon, 13 Apr 2020, 03:13 Gary Gregory, <
> garydgreg...@gmail.com> wrote:
> > > > > > >
> > > > > > > > On Sun, Apr 12, 2020 at 8:57 PM Alex Remily <
> alex.rem...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I can do the 64 bit builds on Mac, Linux and Windows, so
> I'm happy to
> > > > > > > > > provide whichever of those is required.  It seems that
> Geoff can do the
> > > > > > > > > arm64 build.  Do we even bother supporting 32 bit
> architectures at this
> > > > > > > > > point?
> > > > > > > > >
> > > > > > > >
> > > > > > > > Unfortunately, we cannot just pick up bits from folks here
> and there. It
> > > > > > > > all has to be buildable from Maven by the release manager in
> order to
> > > > > > > > generate the file signatures properly.
> > > > > > > >
> > > > > > > > Based on what I see in the docs, it looks like this is
> buildable using
> > > > > > > > cross-compilation with MinGW on Windows. Not sure about the
> Mac stuff
> > > > > > > yet.
> > > > > > > >
> > > > > > > > I'm not sure what the use-case is for 32-bit at this point.
> > > > > > > >
> > > > > > > > Gary
> > > > > > > >
> > > > > > > >
> > > > > > > > > On Sun, Apr 12, 2020 at 7:36 PM Marcelo Vanzin <
> van...@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Gary,
> > > > > > > > > >
> > > > > > > > > > On Sun, Apr 12, 2020 at 8:53 AM Gary Gregory <
> garydgreg...@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > The 1.0 release on maven central only included
> linux32 and
> > > > > > > linux64
> > > > > > > > > > native
> > > > > > > > > > > > libs, even though the Makefile supports many more
> targets
> > > > > > > > > > > >

what became of beanshell in Apache commons?

[Peter Kovacs]

Hello all,

I hope I do not sound to stupid.
In Apache OpenOffice we still beanshell 2.0b6.
Now I figured that beanshell was included into apache copmmons, which we also 
use.

Can anyone help me, and guide on the transition so we can drop the old 
dependency for good?

Any information helps, links and so on. Sorry I am a bit lost having to bridge 
7 years gap.
Thanks a lot for any support! (I am subscribing, So no worries.)

All the Best
Peter

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

[geometry] API Design Feedback

[Matt Juntunen]

Hello,

Gilles and I have been working on polishing the API for commons-geometry and 
wrapping up a couple of last issues before the 1.0-beta1 release. We've been 
discussing the API design for some of the core classes in GEOMETRY-92 and 
GEOMETRY-94 and I'd like to get some feedback from the community on what we 
have. The goal is to create a mathematically correct and at the same time 
intuitive set of classes.

Below are 3 options for the names of some of the classes from the core 
(space-agnostic) module and the Euclidean module. I'm intentionally not 
explaining the meaning of any of the names since I'm interested in finding out 
how self-documenting they are. Please let me know if there is an option you 
prefer and if you have any suggestions for improvement. Any feedback whatsoever 
is greatly appreciated:-)

Note: The "::" characters below indicate some sort of inheritance, either by 
interface or class.

Option 1: Based on "Hyperplane/SubHyperplane" naming
- Core Module
- Hyperplane
- SubHyperplane
- ConvexSubHyperplane :: SubHyperplane
- Euclidean 2D
- Line :: Hyperplane
- SubLine :: SubHyperplane
- ConvexSubLine :: SubLine, ConvexSubHyperplane
- Line.Span :: ConvexSubLine
- Segment :: ConvexSubLine
- Ray :: ConvexSubLine
- ReverseRay :: ConvexSubLine
- Euclidean 3D
- Plane :: Hyperplane
- SubPlane :: SubHyperplane
- ConvexSubPlane :: SubPlane, ConvexSubHyperplane
- FiniteConvexSubPlane :: ConvexSubPlane
- Triangle3D :: FiniteConvexSubPlane
- Line3D
- SubLine3D
- ConvexSubLine3D :: SubLine3D
- Line3D.Span :: ConvexSubLine3D
- Segment3D :: ConvexSubLine3D
- Ray3D:: ConvexSubLine3D
- ReverseRay3D :: ConvexSubLine3D

Option 2: Based on "Hyperplane/HyperplaneSubset" naming
- Core Module
- Hyperplane
- HyperplaneSubset
- HyperplaneConvexSubset :: HyperplaneSubset
- Euclidean 2D
- Line :: Hyperplane
- LineSubset :: HyperplaneSubset
- LineConvexSubset :: LineSubset, HyperplaneConvexSubset
- LineSpanningSubset :: LineConvexSubset
- Segment :: LineConvexSubset
- Ray :: LineConvexSubset
- ReverseRay :: LineConvexSubset
- Euclidean 3D
- Plane :: Hyperplane
- PlaneSubset :: HyperplaneSubset
- PlaneConvexSubset :: PlaneSubset, HyperplaneConvexSubset
- PlaneFiniteConvexSubset :: PlaneConvexSubset
- Triangle3D :: PlaneFiniteConvexSubset
- Line3D
- LineSubset3D
- LineConvexSubset3D :: LineSubset3D
- LineSpanningSubset3D :: LineConvexSubset3D
- Segment3D :: LineConvexSubset3D
- Ray3D:: LineConvexSubset3D
- ReverseRay3D :: LineConvexSubset3D

Option 3: Same as #2 but with adjectives (eg "convex") coming before the 
hyperplane name
- Core Module
- Hyperplane
- HyperplaneSubset
- ConvexHyperplaneSubset :: HyperplaneSubset
- Euclidean 2D
- Line :: Hyperplane
- LineSubset :: HyperplaneSubset
- ConvexLineSubset :: LineSubset, ConvexHyperplaneSubset
- SpanningLineSubset :: ConvexLineSubset
- Segment :: ConvexLineSubset
- Ray :: ConvexLineSubset
- ReverseRay :: ConvexLineSubset
- Euclidean 3D
- Plane :: Hyperplane
- PlaneSubset :: HyperplaneSubset
- ConvexPlaneSubset :: PlaneSubset, ConvexHyperplaneSubset
- FiniteConvexPlaneSubset :: ConvexPlaneSubset
- Triangle3D :: FiniteConvexPlaneSubset
- Line3D
- LineSubset3D
- ConvexLineSubset3D :: LineSubset3D
- SpanningLineSubset3D :: ConvexLineSubset3D
- Segment3D :: ConvexLineSubset3D
- Ray3D:: ConvexLineSubset3D
- ReverseRay3D :: ConvexLineSubset3D


Regards,
Matt J

Re: [LANG] Porting to Kotlin

[Isira Seneviratne]

 
On Mon, Apr 20, 2020 at 8:41 PM Isira Seneviratne 
wrote:

> Hi all,
>
> I'm a new contributor, but I've been using Commons Lang for a while now,
> and I feel that porting Commons Lang to Kotlin would be very useful for
> Kotlin development, as a lot of its methods (particularly those in the
> Utils classes) are not present in the Kotlin standard library, and these
> could be written as extensions
> .
>
> What do you guys think?
> --
> Isira Seneviratne
> isirase...@gmail.com
>

I have attached some sample files if anyone is interested.
--
Isira Seneviratne
isirase...@gmail.com

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

Re: [LANG] Porting to Kotlin

[Paul King]

The attachments didn't seem to come through. I am not on the commons PMC
but I would be -1 for changing the existing functionality. They already
work fine for Java and work already as Apache Groovy extension methods:

@Grab('org.apache.commons:commons-lang3:3.10')
import org.apache.commons.lang3.StringUtils

use(StringUtils) {
assert 'The quick brown fox'.abbreviateMiddle('..', 8) == 'The..fox'
assert 'abcdef'.rotate(3) == 'defabc'
}

Rather than talking about "porting", why not just create a thin
re-purposing layer that provides additional functionality to Kotlin users.
That would be easy to do as a separate project and could be incorporated
into commons lang at a later date if there was sufficient interest?

Cheers, Paul.


On Sat, Apr 25, 2020 at 2:24 PM Isira Seneviratne 
wrote:

> 
> On Mon, Apr 20, 2020 at 8:41 PM Isira Seneviratne 
> wrote:
>
>> Hi all,
>>
>> I'm a new contributor, but I've been using Commons Lang for a while now,
>> and I feel that porting Commons Lang to Kotlin would be very useful for
>> Kotlin development, as a lot of its methods (particularly those in the
>> Utils classes) are not present in the Kotlin standard library, and these
>> could be written as extensions
>> .
>>
>> What do you guys think?
>> --
>> Isira Seneviratne
>> isirase...@gmail.com
>>
>
> I have attached some sample files if anyone is interested.
> --
> Isira Seneviratne
> isirase...@gmail.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org