Re: [Collections] Suppliers, Iterables, and Producers

[Alex Herbert]

On Tue, 30 Apr 2024 at 14:45, Gary D. Gregory  wrote:

> Hi Claude,
>
> Thank you for the detailed reply :-) A few comments below.
>
> On 2024/04/30 06:29:38 Claude Warren wrote:
> > I will see if I can clarify the javadocs and make things clearer.
> >
> > What I think I specifically heard is:
> >
> >- Be clear that producers are fast fail iterators with predicate
> tests.
> >- Rename CellConsumer to CellPredicate (?)
>
> Agreed (as suggested by Albert)
>
> >- The semantic nomenclature:
> >   - Bitmaps are arrays of bits not a BitMap object.
> >   - Indexes are ints and not an instance of a Collection object.
> >   - Cells are pairs of ints representing an index and a value.  They
> >   are not Pair<> objects.
> >   - Producers iterate over collections of the object (Bitmap, Index,
> >   Cell) applying a predicate to do work and stop the iteration early
> if
> >   necessary.  They are carriers/transporters of Bloom filter enabled
> bits.
> >   They allow us to query the contents of the Bloom filter in an
> >   implementation agnostic way.
>
> As you say naming is hard. The above is a great example and a good
> exercise I've gone through at work and in other FOSS projects: "Producers
> iterate over collections of the object...". In general when I see or write
> a Javadoc of the form "Foo bars" or "Runners walk" or "Walkers run", you
> get the idea ;-) I know that either the class (or method) name is bad or
> the Javadoc/documentation is bad; not _wrong_, just bad in the sense that
> it's confusing (to me).
>
> I am not advocating for a specific change ATM but I want to discuss the
> option because it is possible the current name is not as good as it could
> be. It could end up as an acceptable compromise if we cannot use more Java
> friendly terms though.
>
> Whenever I see a class that implements a "forEach"-kind of method, I think
> "Iterable".
>

Here we should think "Collection", or generally more than 1. In the Java
sense an Iterable is something you can walk through to the
end, possibly removing elements as you go using the Iterator interface. We
would not require supporting removal, and we want to control a
short-circuit. We could make this distinction by including it in the name:
forEachUntil(Predicate ...), forEachUnless, ...


>
> Note the difference with "Iterator", and I had to lookup the difference
> since the former implements "forEach" and the  later "forEachRemaining"!
> "Iterable" is also a factory of "Iterator"s.
>
> Should the Producers ever be implementations of Iterable or Iterator?
> Right now, the answer is no because of the short-circuit aspect of using a
> predicate. I'm not using the term fail-fast here because I don't think of
> the iteration being in error (please tell me if I'm wrong).
>
> If not iterable, then we should not use that name as part of the class
> name. Generally, the short-circuit aspect of Producers do not make a bad
> candidates for implementations of Iterable since it can throw (unchecked)
> exceptions. Different for call sites granted, but I'm just mentioning it
> for fun.
>

I already mentioned throwing runtime exceptions for the short-circuit
functionality, and that it was ruled out on the basis of performance (given
a lot of short-circuiting is expected) and convenience for the caller. I
don't think we should go there. Design the API for the intended purpose,
and not push it into a box that is easily recognisable.


>
> So maybe there's nothing to do. I just want to be clear about it. For
> example, I think of "factory" and "producer" as synonyms but in this case,
> this is not a traditional application of the factory pattern.
>
> As an aside I can see that Producers would not be Streams out of the box
> because Stream#filter(Predicate) filters but does not short-circuit
> iteration. While Stream#findAny() and #findFirst() don't fit the
> short-circuit bill, we could implement a #findLast() in a Stream
> implementation. What I do not know is if Streams otherwise fit the bill of
> Bloom filters.
>

In the case of small loops with few instructions per loop, the overhead of
Streams is significant. Unfortunately we don't have any performance tests
for this library, but I wouldn't change to Streams without knowing it does
not impact performance. Performance is a key feature of Bloom filters.
Otherwise you can achieve some of their functionality with conventional
collections.


>
> >
> > Does that basically cover the confusion?   If there are better terms,
> let's
> > hash them out now before I update the javadocs.
> >
> > As an aside, Cells and Bitmaps are referenced in the literature.  For the
> > most part the rest is made up out of whole cloth.  So we could change
> > "Producer" to something else but we would need a good name.
>
> We have a class called BitMap and methods that use "BitMap" in the same
> but I think I am more comfortable with the term reuse now.
>
> The question that remains is must it be 

Re: [Collections] Suppliers, Iterables, and Producers

[Alex Herbert]

Hi Gary,

I am in favour of using nomenclature and patterns that will be familiar to
a Java developer. But only if they match the familiar JDK use patterns. The
Bloom filter package has some atypical use patterns that have driven the
current API to where it is. I'll try and describe these below.

On Sun, 28 Apr 2024 at 14:16, Gary Gregory  wrote:

> Hi Clause, Albert, and all,
>
> Since the introduction of lambdas in Java 8, Java has a well-defined
> terminology around the classic producer-consumer paradigm but (for
> reasons unknown to me) realized in the functional interfaces *Supplier
> and *Consumer. In addition, as of Java 5, we have the Iterable
> interface.
>
> In our new Bloom filter package we have new interfaces called
> *Producer (as opposed to *Supplier), where some of these new
> interfaces are formally annotated with @FunctionalInterface and some
> not (for example, BloomFilterProducer).
>
> My question is: Why call these "Producers" instead of "Suppliers"? Is
> the formal Bloom filter literature tied to the "Producer" terminology
> in a way that would make adapting to the Java term confusing? I know I
> brought up a similar topic recently, but I would like to revisit it
> now that I've started to read Claude's blog drafts. Even without
> making the current "Producers" formal suppliers by extending Supplier,
> would it be worth using the Java terminology?
>

Claude is familiar with the literature and can comment on that. I would
defer to the literature if it is a common term.

There is one notable distinction to JDK suppliers. Suppliers only supply 1
element and must be repeatedly called to generate more. The Producers in
the BloomFilter package will supply multiple values. They are invoked using
a forEach pattern with the intention of supplying all the elements to a
predicate, not a consumer. If any of those elements is rejected by the
predicate then the rest of the elements are not supplied. So this is a
fail-fast bulk supplier.


>
> My second observation is that some might neither be "Producers" or
> "Suppliers" but instead be extensions of Iterable. For example,
> BitMapProducer is not a factory for instances of BitMap; the BitMap
> does not appear in the signatures of BitMapProducer methods. From a
> strict Java POV, this is (slightly) perplexing.
>

Iterable was suggested in an earlier API, particular for the IndexProducer.
IIRC it was rejected on the basis of simplifying the code for the caller in
the fail-fast case. Otherwise every user of the iterator must implement
fail-fast loops over the elements. There may have been other reasons so it
could be worth a check in the mailing list archives. It would require going
back a few years but it was discussed on the dev list.

The term BitMap refers to a long that holds 64-consecutive indices as
either present or absent. You can consider the sequential bitmaps
containing all indices from [0, n) as the serialized state of a Bloom
filter with n bits. This is essentially a BitSet as you can see from the
SimpleBloomFilter implementation. This originally wrapped a BitSet; it was
converted to directly implement the required read/write bit functionality
on the grounds of performance (no memory reallocation; no index checks).

We do not have a BitMap class since we use a long primitive. A rename would
be to LongProducer causing a name clash with the JDK. Renaming to something
else is possible but I believe BitMap is a term from the literature.


>
> Instead (forgetting the class name issue for now), we could have:
>
> @FunctionalInterface
> public interface BitMapProducer extends Iterable {...}
>
> Which would let implementations define:
>
> Iterator iterator();
>
> Instead of:
>
> boolean forEachBitMap(LongPredicate predicate);
>

The BitMapProducer is not iterating LongPredicates. It is iterating longs
to be accepted by a single LongPredicate. The boolean return allows
signalling to stop the forEach loop. There is no primitive specialisation
of Iterator for long. There is a Spliterator.OfLong but that bundles some
other API that we do not wish to support, namely parallel streaming via
split and the ability to advance element by element (tryAdvance). Currently
we only implement the equivalent of the forEachRemaining pattern from
Spliterator. That accepts a consumer and so fail-fast would be done via
raising a runtime exception. Given that fail-fast is a key feature of a
Bloom filter then we do not want this to be implemented via exceptions.

The primary use case for fail-fast is to stop as soon as a bit index is
found, or not found (case dependent). Consider a Bloom filter that has 20
indices per hashed item. You have populated the filter with items, each has
20 random indices. You then check if a new item is not contained in the
filter by creating indices for the new item with your hash function and
checking each index against those already in the filter. If your new
element has an index not in the filter, then you have not seen this element

Re: [Collections] Bloom filter package's Hasher to extend Function

[Alex Herbert]

On Thu, 25 Apr 2024 at 21:47, Gary D. Gregory  wrote:

> Hi Clause, Albert, and all,
>
> Why not make Hasher more functional like so:
>
> public interface Hasher extends Function
>
> It would implement the standard `apply` instead of `indices`.
>
> WDYT?
>
> Gary
>

I do not see any problems with this. However it may have little benefit
other than being consistent with the Java API. Once you have an
IndexProducer you typically put all the indices into a Bloom filter. But
you cannot construct a BloomFilter from an IndexProducer alone as you
require the Shape. So at present I cannot see a common use case for the
chaining methods (compose, apply) that come with the Function interface.

Alex

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

On Sat, 20 Apr 2024 at 11:36, Claude Warren  wrote:

>  The LayerdBloomFilter has a method find() that returns an array of ints
> that are the indices into the layer array.  This is easily reproducible
> using an iterator.
> There is also get() method that takes an integer argument (an index of the
> bloom filter) and returns the Bloom filter from the layer.  This is
> reproducible but not as efficient using an iterator.
>

Note that using an iterator is how the LinkedList would do this. We are not
using an ArrayList with Order(1) retrieval time.
So performance of the current implementation here is already Order(n).


> I think the array is the proper structure.
>

If an array is the correct structure then we should type to List. Typing to
an interface allows changing the implementation with no effect on the API.
For example changing to a concurrent data structure.

The question is what is the most important functionality? Order(1) add and
remove from the head and tail of the layers (Deque) or Order(1) retrieval
of layers by depth index (List).

Re: find

It currently returns the layer index. What would you do with this other
than call get(index) to get the BloomFilter. We could support this with a
different find method:

// find each bloom filter layer that contains the IndexProducer
// API can be changed if this is required to return as soon as a filter is
found that satisfies some requirement (Predicate vs Consumer).
public void findEach(IndexProducer indexProducer, Consumer
result)

Why else do you require indices of layers? If there is no use case
other than layer retrieval then this seems to be the wrong API.

Alex



> Claude
>
> On Fri, Apr 19, 2024 at 11:06 AM Alex Herbert 
> wrote:
>
> > On Fri, 19 Apr 2024 at 08:26, Claude Warren  wrote:
> >
> > > While the Deque makes clear the idea of enqueueing and dequeueing  the
> > > layers it does not have the method to natively traverse and extract
> > entries
> > > from the middle of the queue.  Nor would I expect it to.  So I think
> the
> > > Deque does not accurately reflect how the collection of Bloom filters
> is
> > > utilized.
> > >
> >
> > You can traverse and remove entries with the Iterator of the Deque:
> >
> > Deque d = new LinkedList<>();
> > d.addAll(Arrays.asList(1, 2, 3, 4, 5));
> > for (Iterator it = d.iterator(); it.hasNext();) {
> > int i = it.next();
> > if (i == 3) {
> > it.remove();
> > }
> > }
> > System.out.println(d);
> >
> > prints:
> >
> > [1, 2, 4, 5]
> >
> > So it is easy to iterate the layers and remove them in Order(1) time (per
> > removal).
> >
> > Alex
> >
> >
> > >
> > > On Wed, Apr 17, 2024 at 2:17 PM Alex Herbert  >
> > > wrote:
> > >
> > > > Looks good to me.
> > > >
> > > > Any opinions on changing the LayerManager to keep the layers in a
> Deque
> > > > rather than a LinkedList. I think it would only require a change to
> the
> > > > following method:
> > > >
> > > > public final BloomFilter get(int depth)
> > > >
> > > > Performance will be the same as the Deque can be a LinkedList. This
> is
> > > more
> > > > about how any custom downstream code is currently using the
> collection
> > of
> > > > layers.
> > > >
> > > > Alex
> > >
> > >
> >
>
>
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

On Fri, 19 Apr 2024 at 08:26, Claude Warren  wrote:

> While the Deque makes clear the idea of enqueueing and dequeueing  the
> layers it does not have the method to natively traverse and extract entries
> from the middle of the queue.  Nor would I expect it to.  So I think the
> Deque does not accurately reflect how the collection of Bloom filters is
> utilized.
>

You can traverse and remove entries with the Iterator of the Deque:

Deque d = new LinkedList<>();
d.addAll(Arrays.asList(1, 2, 3, 4, 5));
for (Iterator it = d.iterator(); it.hasNext();) {
int i = it.next();
if (i == 3) {
it.remove();
}
}
System.out.println(d);

prints:

[1, 2, 4, 5]

So it is easy to iterate the layers and remove them in Order(1) time (per
removal).

Alex


>
> On Wed, Apr 17, 2024 at 2:17 PM Alex Herbert 
> wrote:
>
> > Looks good to me.
> >
> > Any opinions on changing the LayerManager to keep the layers in a Deque
> > rather than a LinkedList. I think it would only require a change to the
> > following method:
> >
> > public final BloomFilter get(int depth)
> >
> > Performance will be the same as the Deque can be a LinkedList. This is
> more
> > about how any custom downstream code is currently using the collection of
> > layers.
> >
> > Alex
>
>

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

Looks good to me.

Any opinions on changing the LayerManager to keep the layers in a Deque
rather than a LinkedList. I think it would only require a change to the
following method:

public final BloomFilter get(int depth)

Performance will be the same as the Deque can be a LinkedList. This is more
about how any custom downstream code is currently using the collection of
layers.

Alex

On Wed, 17 Apr 2024 at 10:00, Claude Warren  wrote:

> I have an open pull request to fix this problem.  I could use another
> review: https://github.com/apache/commons-collections/pull/476
>
>
> On Tue, Apr 9, 2024 at 11:29 AM Claude Warren  wrote:
>
> > Alex,
> >
> > I like your solution.  To answer your question. We create a BloomFilter
> > that has a timestamp associated with it.  When the timestamp is greater
> > than System.currentTimeMillis() the filter is removed.  The custom
> cleanup
> > calls Cleanup.removeEmptyTarget().andThen()
> >
> > I think that creating a cleanup() or clean() method on the
> > LayeredBloomFilter is the appropriate solution and that it should call
> > cleanup() on the LayerManager. (so 2 new methods, one exposed).
> >
> > The next() method is used when external circumstances dictate that a new
> > layer should be created.  I think a StableBloomFilter I implemented
> > required it,  but I do not have the code to hand at the moment.
> >
> > Claude
> >
> >
> > On Tue, Apr 9, 2024 at 10:38 AM Alex Herbert 
> > wrote:
> >
> >> Hi Claude,
> >>
> >> Q. What is your current clean-up filter, i.e.
> >> the Consumer>? I assume you are using a custom
> >> one.
> >>
> >> The current collections code only has 2 functional implementations. One
> >> will remove the newest filter if it is empty, one will remove the oldest
> >> filters until the size is below a limit. Since neither of those will
> >> iterate the list and purge stale objects then I assume you are using a
> >> custom clean-up filter. So you had to have created the layer manager
> with
> >> your custom filter. Assuming this then there are at least two solutions
> >> for
> >> the current code:
> >>
> >> 1. The current implementation always calls the clean-up filter with the
> >> same LinkedList since it is final. So you can capture the list and do
> what
> >> you want with it:
> >>
> >> @SuppressWarnings("rawtypes")
> >> LinkedList[] captured = new LinkedList[1];
> >> Consumer> cleanup = list -> {
> >> captured[0] = list;
> >> // ... do clean-up
> >> };
> >>
> >> // Once you have captured the list, you can clean it when you
> >> want:
> >> // unchecked conversion
> >> cleanup.accept(captured[0]);
> >>
> >> Obviously this is not ideal as you have to manage the captured list to
> >> call
> >> cleanup. But it delivers exactly what you require in terms of being able
> >> to
> >> call cleanup at any time.
> >>
> >> 2. The call to next() will clean the layers but also add a new layer. So
> >> your custom clean method could clean stale objects and also any empty
> >> filters not at the end of the list. This will avoid building up lots of
> >> empty filters when you frequently trigger next() to purge stale filters.
> >> You can call next() directly on the LayeredBloomFilter. I do not know
> what
> >> extend check you are using so there is some management to be done with
> the
> >> other settings of the LayerManager to avoid removing any functional
> layers
> >> which are currently empty.
> >>
> >> --
> >>
> >> As to exposing the LayerManager and adding a clean() method to the
> >> LayerManager, I think this is not in keeping with the current design.
> The
> >> LayerManager is used during construction and then never used again. So
> >> functionality to act on the layers is public through the
> >> LayeredBloomFilter
> >> (e.g. calling next()). So perhaps the change to the API should be to
> add a
> >> cleanup() method to LayeredBloomFilter. This does the same as next(),
> but
> >> does not add a new layer.
> >>
> >> I cannot recall the use case for next() in the LayeredBloomFilter. Would
> >> the addition of cleanup() make the next() method redundant?
> >>
> >> --
> >>
> >> Note: The typing against LinkedList could be updated to java.ut

Re: [Collections-BloomFilter][Discuss] missing functionality?

[Alex Herbert]

Hi Claude,

Q. What is your current clean-up filter, i.e.
the Consumer>? I assume you are using a custom one.

The current collections code only has 2 functional implementations. One
will remove the newest filter if it is empty, one will remove the oldest
filters until the size is below a limit. Since neither of those will
iterate the list and purge stale objects then I assume you are using a
custom clean-up filter. So you had to have created the layer manager with
your custom filter. Assuming this then there are at least two solutions for
the current code:

1. The current implementation always calls the clean-up filter with the
same LinkedList since it is final. So you can capture the list and do what
you want with it:

@SuppressWarnings("rawtypes")
LinkedList[] captured = new LinkedList[1];
Consumer> cleanup = list -> {
captured[0] = list;
// ... do clean-up
};

// Once you have captured the list, you can clean it when you want:
// unchecked conversion
cleanup.accept(captured[0]);

Obviously this is not ideal as you have to manage the captured list to call
cleanup. But it delivers exactly what you require in terms of being able to
call cleanup at any time.

2. The call to next() will clean the layers but also add a new layer. So
your custom clean method could clean stale objects and also any empty
filters not at the end of the list. This will avoid building up lots of
empty filters when you frequently trigger next() to purge stale filters.
You can call next() directly on the LayeredBloomFilter. I do not know what
extend check you are using so there is some management to be done with the
other settings of the LayerManager to avoid removing any functional layers
which are currently empty.

--

As to exposing the LayerManager and adding a clean() method to the
LayerManager, I think this is not in keeping with the current design. The
LayerManager is used during construction and then never used again. So
functionality to act on the layers is public through the LayeredBloomFilter
(e.g. calling next()). So perhaps the change to the API should be to add a
cleanup() method to LayeredBloomFilter. This does the same as next(), but
does not add a new layer.

I cannot recall the use case for next() in the LayeredBloomFilter. Would
the addition of cleanup() make the next() method redundant?

--

Note: The typing against LinkedList could be updated to java.util.Deque.
The only issue with this is the method:
public final BloomFilter get(int depth)

This is not supported by the Deque interface. However the LinkedList
implementation of get(int) will use the iterator from the start or end of
the list (whichever is closer) to find the element. This can use the
iterator/descendingIterator method of Deque for the same performance (but
the code to do this has to be written).

Alex


On Tue, 9 Apr 2024 at 08:45, Claude Warren  wrote:

> Greetings,
>
> I am attempting to use the Bloomfilter code in Kafka to manage PID
> generation.  The requirement is to remove pid tracking after a period of
> time.  This is possible with the LayeredBloomFilter but it has an edge case
> problem.
>
> The LayeredBloomFilter uses the LayerManager to manage the filters that
> comprise the layers of the LayerdBloomFilter.
> The LayerManager uses a Consumer> called
> filterCleanup to remove old layers.
> The filterCleanup is only called when a new layer is added to the layered
> filter.
>
> This solution works well in the general case where data is flowing through
> the layered filter.  However if nothing is added to the filter,
> filterCleanup is not called.
>
> In the Kafka case we have a LayeredBloomFilter for PIDs for each producer.
> As long as a producer is producing PIDs the filter gets updated.
>
> However, if a producer drops from the system or goes offline for a period
> of time, then they will no longer be producing PIDs and their old expired
> data will remain.
>
> We want to remove the producer from the collection when there are no more
> PIDs being tracked.
>
> I think this can be solved by adding a clean() method to the LayerManager
> that simply calls the existing filterCleanup.
> It would be easier to access this method if the LayeredBloomFilter had a
> method to return the LayerManager that was passed in the constructor.
>
> Does anyone see any issues with this approach?  Are there other solutions
> to be had?
>
> Questions and comments welcomed.
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>

Re: [Collections] New release candidate for 4.5.0-beta1 or -M1 and new Bloom Filter package

[Alex Herbert]

On Mon, 25 Mar 2024 at 13:12, Gary Gregory  wrote:

> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
> giving us the change to make breaking API changes if needed.
>
> Gary
>

+1

I have not looked at the Bloom filter package for a while. It is on my todo
list to check the API is consistently and correctly implemented by the
underlying classes.

The package also does not have any performance tests. It would be nice to
have some since Bloom filters are probabilistic structures that offer
speed-up over other data structures to track occurrences of objects whilst
compromising on the exactness of results, i.e they are configured with a
desired false-positive rate. At present the code is rather complex and it
would be nice to have some figures to show the advantages.

We should also get some closure on COLLECTIONS-842 [1] which is an
incompatibility between collections and default methods added to List in
JDK 21. I looked at this for a while but did not change anything in the
codebase. TLDR: you cannot compile collections with JDK 21 but you can run
it with JDK 21 if the binary is compiled for an earlier target. It affects
any class extending AbstractLinkedList (there are 3 in Collections). The
minimum effort would be to mark the AbstractLinkedList methods as
deprecated and in future to be changed to the same API as JDK 21. This
would leave the 4.X branch compile time limited to LTS JDKs up to 17.

Alex

[1] https://issues.apache.org/jira/browse/COLLECTIONS-842

Re: [Net] JUnit 5 migration discussion

[Alex Herbert]

Use of abstract classes does work in JUnit 5. I've written a lot of JUnit 5
tests that use abstract test classes which define the
@ParameterizedTest/@Test fixtures and then concrete child classes that are
run by the framework. It is supported but IIRC it is not recommended in the
JUnit 5 documentation. It has been a while since I looked to see
what alternatives are provided.

IMO the use of an abstract base class that has all the tests is still a
useful pattern. It is used in Commons Collections for the Bloom filter
package to test that implementations of the BloomFilter interfaces all
provide the required functionality. A more convoluted abstract test class
structure is used in Commons Statistics in the distribution and descriptive
packages. These abstract classes define methods to test interface
implementations. The child classes then provide instances of the interface
to test with standard data, and can provide custom data to test them with.
I do not think it is as configurable to have a single class with
@ParameterizedTest methods to test lots of different implementations. It
requires a very large method to stream all the different instances to test
and their data. This pattern is used in Commons RNG to test instances of a
random generator interface, or distribution samplers.

A quick browse of the API finds @TestTemplate which requires registering
providers and a lot more setup. Note that @ParameterizedTest is a built-in
specialization of @TestTemplate. So this is a JUnit5 way to create more
configurable tests which provide combinations of parameters for the test.

I found that using an abstract class I was able to create a test framework
that tested what was required and allowed testing of each implementation
individually. So I could do what I wanted. However I cannot state if it
would be better with @TestTemplate or some other JUnit 5 way to achieve the
same result. I remember trying a few other options but cannot remember why
I gave up and resorted to the abstract class pattern.

Note that it would be better to have VFS on JUnit 5 using abstract classes
than on JUnit 3 or 4. I would try and upgrade one test and see if it works.

Alex


On Thu, 29 Feb 2024 at 20:43, Gary Gregory  wrote:

> Thank you for digging into this Eric.
>
> Another component to consider for JUnit 5 migration is Commons VFS. This
> one is challenging due to some similar JUnit 3 and 4 heritage issues.
>
> It is possible that between Net and VFS, what we need are custom JUnit
> extensions. I had started a Commons Testing repository a long time ago but
> never got far with adding what at the time were JUnit 4 rules.
>
> I too find some of the JUnit 5 changes baffling but that's what we got...
> unless we want to switch to TextNG or some other test framework which would
> be a big change.
>
> Gary
>
>
> On Thu, Feb 29, 2024, 3:13 PM Elric V  wrote:
>
> > Hi folks,
> >
> > I recently made some changes to commons-cli to move it from JUnit 4 to
> > JUnit 5. This was mostly straightforward, and I think it went pretty
> well.
> >
> > Currently looking into doing the same for commons-net, but there are a
> > couple of tricky tests that probably require some up front discussion,
> > mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
> >
> > In previous versions, test classes could be extended and their test
> > methods would be executed as part of the child class' execution. This
> > was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
> > test-prefix naming convention.
> >
> > Unfortunately, this is no longer the case in JUnit 5. I think this is a
> > poor design decision on their part, as it makes it significantly harder
> > to move to JUnit 5, and it makes certain types of tests just plain
> > difficult. There is some discussion about this in the JUnit community
> > [1], but I can't predict whether this will ever be resolved in a way to
> > makes commons-net's upgrade any easier.
> >
> > One of those cases is AbstractFTPParseTest and its children. This
> > abstract base class has 11 concrete test classes. I'm struggling to see
> > a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
> > heavy handed approach there.
> >
> > A second tricky case is FTPSClientTest, which is a Parameterized test of
> > a form that no longer exists in JUnit 5. It basically creates two
> > instances of a test class with a boolean flag (once true, once false).
> >
> > JUnit 5's @ParameterizedTest annotation operates on the **test method**
> > level, not on the class level, which I think would make the test case
> > slower and harded to read.
> >
> > An alternative approach would be to use Dynamic Tests, which basically
> > generate test cases programmatically, but again, that makes grokking the
> > test a lot more difficult as it requires a greater understanding of
> > JUnit's features.
> >
> > Any insights into this would be greatly appreciated.
> >
> > Best,
> >
> > Elric
> >
> > [1] 

Re: New to community-Introducing myself

[Alex Herbert]

On Sun, 31 Dec 2023 at 20:54, Narasimha asuri
 wrote:
>
> Hi,
>
> Chary here, I am a beginner java developer and I used many components
> of Apache commons library in my previous project, Lang, IO, Math. Saw the
> commons - math library and am on looking to help solve some issues.
>
>
>
> Chary.

Welcome.

You can find all of the Commons components from the homepage [1].

Each Commons component has its own Jira tracker for issues [2]. Please
look at the component you are interested in to see outstanding issues
and find ideas for issues to work on. The README in the component
repository (mirrored through GitHub) has a link to the relevant Jira
project, e.g. [3, 4], or you can find it from the component homepage
under the 'Issue Management' section [5].

Any discussion on development for a specific component can be started
as a discussion on this mailing list using the component as a message
subject prefix in square brackets, e.g. [math] my idea is ...

Alex

[1] https://commons.apache.org/
[2] https://issues.apache.org/jira
[3] https://github.com/apache/commons-math
[4] https://issues.apache.org/jira/projects/MATH
[5] https://commons.apache.org/proper/commons-math/issue-management.html

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

Re: (commons-numbers) branch master updated: Simplify conversion of numbers to unsigned

[Alex Herbert]

On Sun, 24 Dec 2023 at 17:51, sebb  wrote:
>
> On Sun, 24 Dec 2023 at 16:58,  wrote:
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > aherbert pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> >  new a15b3e68 Simplify conversion of numbers to unsigned
> > a15b3e68 is described below
> >
> > commit a15b3e68136dd94ea20e4085afc45aa73d46362e
> > Author: Alex Herbert 
> > AuthorDate: Sun Dec 24 16:57:58 2023 +
> >
> > Simplify conversion of numbers to unsigned
> > ---
> >  .../java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java | 8 
> > ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git 
> > a/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> >  
> > b/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> > index 4063f440..0b4aa797 100644
> > --- 
> > a/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> > +++ 
> > b/commons-numbers-core/src/test/java/org/apache/commons/numbers/core/ArithmeticUtilsTest.java
> > @@ -28,6 +28,8 @@ import org.junit.jupiter.api.Test;
> >   *
> >   */
> >  class ArithmeticUtilsTest {
> > +/** 2^63. */
> > +private static final BigInteger TWO_POW_63 = 
> > BigInteger.ONE.shiftLeft(63);
> >
> >  @Test
> >  void testGcd() {
> > @@ -538,7 +540,7 @@ class ArithmeticUtilsTest {
> >  }
> >
> >  private static long toUnsignedLong(int number) {
> > -return number < 0 ? 0x1L + (long)number : (long)number;
> > +return Integer.toUnsignedLong(number);
> >  }
>
> The private method could now be dropped.

I did this, then reverted. IMO it creates more noise in the source
where the method is called as it must be prefixed by "Integer.". This
makes one-liner code go over 120 chars.


>
> >  private static int remainderUnsignedExpected(int dividend, int 
> > divisor) {
> > @@ -550,7 +552,9 @@ class ArithmeticUtilsTest {
> >  }
> >
> >  private static BigInteger toUnsignedBigInteger(long number) {
> > -return number < 0L ? 
> > BigInteger.ONE.shiftLeft(64).add(BigInteger.valueOf(number)) : 
> > BigInteger.valueOf(number);
> > +return number < 0 ?
> > +TWO_POW_63.or(BigInteger.valueOf(number & Long.MAX_VALUE)) :
> > +BigInteger.valueOf(number);
> >  }
> >
> >  private static long remainderUnsignedExpected(long dividend, long 
> > divisor) {
> >
>
> -
> 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: [MATH][NUMBERS] Method to convert unsigned long to BigInteger

[Alex Herbert]

On Sun, 24 Dec 2023 at 16:31, sebb  wrote:
>
> On Sun, 24 Dec 2023 at 16:14, Alex Herbert  wrote:
> >
> > On Sun, 24 Dec 2023 at 13:58, sebb  wrote:
> > >
> > > On Sun, 24 Dec 2023 at 13:16, Alex Herbert  
> > > wrote:
> > > >
> > > > On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold 
> > > >  wrote:
> > > > >
> > > > > On Sun, Dec 24, 2023 at 9:59 AM sebb  wrote:
> > > > > >
> > > > > > Both Numbers and Statistics have implementations of
> > > > > >
> > > > > > BigInteger toUnsignedBigInteger(long treatedAsUnsigned)
> > > > > >
> > > > >
> > > > > Can you describe a use case for this? That might help decide where it
> > > > > belongs. I wouldn't be surprised if this is more suitable for lang
> > > > > than Math or Numbers.
> > > > >
> > > > > I'd also suggest a different method name. There's no such thing as an
> > > > > UnsignedBigInteger in Java. All BigIntegers are signed. Maybe
> > > > > something like toBigIntegerFromUnsigned
> > > >
> > > > The method is effectively (but without expensive string conversions):
> > > >
> > > > new BigInteger(Long.toUnsignedString(v));
> > > >
> > > > I do not have a use case for it other than testing unsigned integer
> > > > math implementations. It could be used to create a valid number when
> > > > using a long counter that has overflowed to negative.
> > > >
> > > > A possible home is in [Lang]:
> > > >
> > > > org.apache.commons.lang3.math.NumberUtils
> > > >
> > > > That class has some conversion methods to BigDecimal for
> > > > floating-point numbers with rounding to a number of significant
> > > > digits. So creating BigInteger beyond the support of the JDK methods
> > > > is in scope.
> > > >
> > > > Without a use case it would just be code bloat.
> > >
> > > If it were added to MATH, the implementations could be dropped from
> > > NUMBERS and STATISTICS...
> >
> > Math depends on Numbers and Statistics. So that would be a circular 
> > dependency.
> >
> > It is a simple two line method. I think this is fine duplicated across
> > test codebases.
>
> I've just noticed that the methods are slightly different.
> One uses add, the other or and a mask.
>
> Numbers:
> return number < 0L ?
> BigInteger.ONE.shiftLeft(64).add(BigInteger.valueOf(number)) :
> BigInteger.valueOf(number);
>
> Statistics:
> return v < 0 ? TWO_POW_63.or(BigInteger.valueOf(v & Long.MAX_VALUE)) :
> BigInteger.valueOf(v);

Yes. I wrote the one with the or method today as I realised my
original using the add was not required. Here we are combining
non-overlapping bits. Doing an add will create the same result. But it
will do extra work to compute the carry (of zero) up through the
number.

E.g.

a000 + 0bcd = abcd
a000 | 0bcd = abcd

I'll update the original.

>
> > We could make the method public in the Numbers test class and have the
> > relevant test Statistics code depend on the Numbers test jar. But that
> > seems overly convoluted for the simple method.
>
> > Alex
> >
> > -
> > 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: [MATH][NUMBERS] Method to convert unsigned long to BigInteger

[Alex Herbert]

On Sun, 24 Dec 2023 at 13:58, sebb  wrote:
>
> On Sun, 24 Dec 2023 at 13:16, Alex Herbert  wrote:
> >
> > On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold  
> > wrote:
> > >
> > > On Sun, Dec 24, 2023 at 9:59 AM sebb  wrote:
> > > >
> > > > Both Numbers and Statistics have implementations of
> > > >
> > > > BigInteger toUnsignedBigInteger(long treatedAsUnsigned)
> > > >
> > >
> > > Can you describe a use case for this? That might help decide where it
> > > belongs. I wouldn't be surprised if this is more suitable for lang
> > > than Math or Numbers.
> > >
> > > I'd also suggest a different method name. There's no such thing as an
> > > UnsignedBigInteger in Java. All BigIntegers are signed. Maybe
> > > something like toBigIntegerFromUnsigned
> >
> > The method is effectively (but without expensive string conversions):
> >
> > new BigInteger(Long.toUnsignedString(v));
> >
> > I do not have a use case for it other than testing unsigned integer
> > math implementations. It could be used to create a valid number when
> > using a long counter that has overflowed to negative.
> >
> > A possible home is in [Lang]:
> >
> > org.apache.commons.lang3.math.NumberUtils
> >
> > That class has some conversion methods to BigDecimal for
> > floating-point numbers with rounding to a number of significant
> > digits. So creating BigInteger beyond the support of the JDK methods
> > is in scope.
> >
> > Without a use case it would just be code bloat.
>
> If it were added to MATH, the implementations could be dropped from
> NUMBERS and STATISTICS...

Math depends on Numbers and Statistics. So that would be a circular dependency.

It is a simple two line method. I think this is fine duplicated across
test codebases.

We could make the method public in the Numbers test class and have the
relevant test Statistics code depend on the Numbers test jar. But that
seems overly convoluted for the simple method.

Alex

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

Re: (commons-numbers) 01/01: Use Java 1.8 methods to simplify the ArithmeticUtils methods remainderUnsigned and divideUnsigned (both int and long)

[Alex Herbert]

I would be wary of this simplification without a performance test.

In the Numbers class the int methods do not use long arithmetic. The
long methods do not use BigInteger. This is unlike those methods in my
JDK 8 source code which do and are likely much slower. A quick check
in JDK 21 finds this is still not an intrinsic method [1]. My only
issue with the Numbers methods is they are based on the Hacker's
Delight book which is not free, thus it is not easy to check the
implementation against the source.

Alex

[1] https://chriswhocodes.com/hotspot_intrinsics_openjdk21.html

On Sun, 24 Dec 2023 at 13:20,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch java8-simplify
> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
>
> commit 2f60d424725ca619abf324858593368e66dd5fc2
> Author: Sebb 
> AuthorDate: Sun Dec 24 13:20:13 2023 +
>
> Use Java 1.8 methods to simplify the ArithmeticUtils methods 
> remainderUnsigned and divideUnsigned (both int and long)
> ---
>  .../commons/numbers/core/ArithmeticUtils.java  | 68 
> +++---
>  src/changes/changes.xml|  3 +
>  2 files changed, 11 insertions(+), 60 deletions(-)
>
> diff --git 
> a/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
>  
> b/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
> index d34d7e2b..7afde103 100644
> --- 
> a/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
> +++ 
> b/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/ArithmeticUtils.java
> @@ -470,7 +470,7 @@ public final class ArithmeticUtils {
>   * Returns the unsigned remainder from dividing the first argument
>   * by the second where each argument and the result is interpreted
>   * as an unsigned value.
> - * This method does not use the {@code long} datatype.
> + * This method uses the Java 1.8+ method {@link 
> Integer#remainderUnsigned(int, int)}.
>   *
>   * @param dividend the value to be divided
>   * @param divisor the value doing the dividing
> @@ -478,27 +478,14 @@ public final class ArithmeticUtils {
>   * the second argument.
>   */
>  public static int remainderUnsigned(int dividend, int divisor) {
> -if (divisor >= 0) {
> -if (dividend >= 0) {
> -return dividend % divisor;
> -}
> -// The implementation is a Java port of algorithm described in 
> the book
> -// "Hacker's Delight" (section "Unsigned short division from 
> signed division").
> -final int q = ((dividend >>> 1) / divisor) << 1;
> -dividend -= q * divisor;
> -if (dividend < 0 || dividend >= divisor) {
> -dividend -= divisor;
> -}
> -return dividend;
> -}
> -return dividend >= 0 || dividend < divisor ? dividend : dividend - 
> divisor;
> +return Integer.remainderUnsigned(dividend, divisor);
>  }
>
>  /**
>   * Returns the unsigned remainder from dividing the first argument
>   * by the second where each argument and the result is interpreted
>   * as an unsigned value.
> - * This method does not use the {@code BigInteger} datatype.
> + * This method uses the Java 1.8+ method {@link 
> Long#remainderUnsigned(int, int)}.
>   *
>   * @param dividend the value to be divided
>   * @param divisor the value doing the dividing
> @@ -506,20 +493,7 @@ public final class ArithmeticUtils {
>   * the second argument.
>   */
>  public static long remainderUnsigned(long dividend, long divisor) {
> -if (divisor >= 0L) {
> -if (dividend >= 0L) {
> -return dividend % divisor;
> -}
> -// The implementation is a Java port of algorithm described in 
> the book
> -// "Hacker's Delight" (section "Unsigned short division from 
> signed division").
> -final long q = ((dividend >>> 1) / divisor) << 1;
> -dividend -= q * divisor;
> -if (dividend < 0L || dividend >= divisor) {
> -dividend -= divisor;
> -}
> -return dividend;
> -}
> -return dividend >= 0L || dividend < divisor ? dividend : dividend - 
> divisor;
> +return Long.remainderUnsigned(dividend, divisor);
>  }
>
>  /**
> @@ -531,7 +505,7 @@ public final class ArithmeticUtils {
>   * bit-wise identical if the two operands are regarded as both
>   * being signed or both being unsigned. Therefore separate {@code
>   * addUnsigned}, etc. methods are not provided.
> - * This method does not use the {@code long} datatype.
> + * This method uses the Java 1.8+ method {@link 
> Integer#divideUnsigned(int, int)}.
>   *
>   * @param dividend the value to be 

Re: (commons-numbers) branch java8-simplify created (now 2f60d424)

[Alex Herbert]

On Sun, 24 Dec 2023 at 13:20,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a change to branch java8-simplify
> in repository https://gitbox.apache.org/repos/asf/commons-numbers.git
>
>
>   at 2f60d424 Use Java 1.8 methods to simplify the ArithmeticUtils 
> methods remainderUnsigned and divideUnsigned (both int and long)
>
> This branch includes the following new commits:
>
>  new 2f60d424 Use Java 1.8 methods to simplify the ArithmeticUtils 
> methods remainderUnsigned and divideUnsigned (both int and long)
>
> The 1 revisions listed above as "new" are entirely new to this
> repository and will be described in separate emails.  The revisions
> listed as "add" were already present in the repository and have only
> been added to this reference.

I would be wary of this simplification without a performance test.

In the Numbers class the int methods do not use long arithmetic. The
long methods do not use BigInteger. This is unlike those methods in my
JDK 8 source code which do and are likely much slower. A quick check
in JDK 21 finds this is still not an intrinsic method [1]. My only
issue with the Numbers methods is they are based on the Hacker's
Delight book which is not free, thus it is not easy to check the
implementation against the source.

Alex

[1] https://chriswhocodes.com/hotspot_intrinsics_openjdk21.html

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

Re: [MATH][NUMBERS] Method to convert unsigned long to BigInteger

[Alex Herbert]

On Sun, 24 Dec 2023 at 11:45, Elliotte Rusty Harold  wrote:
>
> On Sun, Dec 24, 2023 at 9:59 AM sebb  wrote:
> >
> > Both Numbers and Statistics have implementations of
> >
> > BigInteger toUnsignedBigInteger(long treatedAsUnsigned)
> >
>
> Can you describe a use case for this? That might help decide where it
> belongs. I wouldn't be surprised if this is more suitable for lang
> than Math or Numbers.
>
> I'd also suggest a different method name. There's no such thing as an
> UnsignedBigInteger in Java. All BigIntegers are signed. Maybe
> something like toBigIntegerFromUnsigned

The method is effectively (but without expensive string conversions):

new BigInteger(Long.toUnsignedString(v));

I do not have a use case for it other than testing unsigned integer
math implementations. It could be used to create a valid number when
using a long counter that has overflowed to negative.

A possible home is in [Lang]:

org.apache.commons.lang3.math.NumberUtils

That class has some conversion methods to BigDecimal for
floating-point numbers with rounding to a number of significant
digits. So creating BigInteger beyond the support of the JDK methods
is in scope.

Without a use case it would just be code bloat.

Alex

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

Re: [ALL] Deploying SNAPSHOTS from GH workflows

[Alex Herbert]

On Wed, 20 Dec 2023 at 17:15, sebb  wrote:
>
> Numbers is now deploying OK, as does Crypto.

I cannot see anything in the GH action config that specifies that
deploy should be only on the master/main branch in the original Apache
repo.

How is the deploy goal handled in forked repos and subsequently PRs?

Alex

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

Re: [NUMBERS] GH deploy snapshot test

[Alex Herbert]

On Wed, 20 Dec 2023 at 13:19, sebb  wrote:
>
> On Tue, 19 Dec 2023 at 16:08, Alex Herbert  wrote:
> >
> > Thanks Sebb,
> >
> > Note that previously the GH action was running the default goal:
> > 'clean verify javadoc:javadoc'.
> >
> > Since we now need to specify the 'deploy' goal as well the above
> > defaults can be switched in for your additions when Infra have created
> > the credentials.
>
> I added javadoc:javadoc to the goals, but I left out the verify goal
> as it should be part of deploy.
>
> The build mostly succeeded, but the BOM module failed, as it requires
> a GPG secret key.
> Is that needed for SNAPSHOT builds?

TLDR; No. Try '-Dgpg.skip'.

The BOM module is a bit of a fudge to create a minimal BOM. It would
be nice if this has a dedicated plugin to build a bom with some more
control over build and deploy. As it is I had to do a lot of Maven
config to get it to work.

It looks like the GPG profiles are being activated by presence/absence
of the gpg.skip property. Since this is for a snapshot deployment it
should work if you update the maven goal to include '-Dgpg.skip'.

Alex


>
> > Alex
> >
> > On Tue, 19 Dec 2023 at 14:29, sebb  wrote:
> > >
> > > Created https://issues.apache.org/jira/browse/INFRA-25297 to get
> > > access to credentials
> > >
> > > Added code to maven.yml to deploy the snapshot (needs to be enabled
> > > when creds are granted)
> > >
> > > -
> > > 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
>

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

Re: [NUMBERS] GH deploy snapshot test

[Alex Herbert]

Thanks Sebb,

Note that previously the GH action was running the default goal:
'clean verify javadoc:javadoc'.

Since we now need to specify the 'deploy' goal as well the above
defaults can be switched in for your additions when Infra have created
the credentials.

Alex

On Tue, 19 Dec 2023 at 14:29, sebb  wrote:
>
> Created https://issues.apache.org/jira/browse/INFRA-25297 to get
> access to credentials
>
> Added code to maven.yml to deploy the snapshot (needs to be enabled
> when creds are granted)
>
> -
> 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: [ALL] Deploying SNAPSHOTS from GH workflows

[Alex Herbert]

On Tue, 19 Dec 2023 at 10:41, sebb  wrote:
>
> Crypto now has a workflow [4] that deploys a SNAPSHOT version.
>
> I don't know if we want to do this for all components, but if so, the
> process is:
> - raise INFRA Jira to request access to the secrets that hold the
> credentials [1]
> - use the java-settings action to create a settings.xml which
> references the variables holding the credentials [2]
> - pass the secrets as environment variables in the job-step that needs
> them [3] (Note:: we don't need the GPG variable)
>
> The Crypto workflow is rather complicated because it needs to build
> the code on several different OSes and then piece the bits together.
> Other components will be much simpler.
>
> Are there any other components that would benefit from/need snapshots?

Multi-module components are useful to deploy as snapshots if modules
depend on each other. This allows a developer to perform maven build
tasks in the module directory for the code they are working on. Maven
will download the latest snapshot for all the dependencies on other
component modules. It also allows a component to use a snapshot
dependency on another component outside the repo. This allows two
components to be developed in parallel without the developers having
to perform local installs for each change in the main branch.

Snapshots are deployed for the RNG, Statistics, Numbers, Math and
Geometry components via Jenkins running at ci-builds.apache.org. The
use of snapshots was very useful when bugs in Numbers were found when
developing Statistics. The bugs could be fixed in the Numbers snapshot
and Statistics developers automatically obtained the fix. When dev
work is complete the components can be released in order and SNAPSHOT
dependencies removed.

One advantage of the Jenkins set-up is that builds can be triggered by
builds in other repos. We have configured downstream projects to build
when the upstream project is updated. However this has yet to discover
an incompatibility or bug in downstream projects in the 4+ years they
have been running. So this feature is not essential.

I would be happy to trial a simpler (than Crypto) deploy of snapshots
using GH for one of these components, e.g. Numbers/RNG which have no
dependencies.

Alex

>
> Sebb
> [1] e.g. https://issues.apache.org/jira/browse/INFRA-25296
> [2] https://github.com/actions/setup-java#maven-options
> [3] 
> https://github.com/actions/setup-java/blob/main/docs/advanced-usage.md#yaml-example
> [4] 
> https://github.com/apache/commons-crypto/blob/master/.github/workflows/maven_crosstest.yml
>
> -
> 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: Apache Common Lang -- How do I compile or did I find a bug

[Alex Herbert]

On Tue, 12 Dec 2023 at 13:20, Gary Gregory  wrote:
>
> What's the best way to document this do you think?

That lang is tested (and so should be built) with the latest JDK of
the respective stable release (8, 11, 17, 21)?

This could live on the README in the GH repo. This would require an
update to the commons-build-plugin that generates it. But for a start
we can add a few sentences to the lang README under the building
section:

"The code is tested using the latest revision of the JDK for supported
LTS releases. Please ensure your build environment is up-to-date and
kindly report any build issues."

This should provide a first indicator to a user that the JDK must be
up-to-date and welcomes any feedback on building. This text may not be
suitable for all repos if they do not test across all LTS versions of
the JDK so may need some revision for the build-plugin.

Alex

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

Re: Apache Common Lang -- How do I compile or did I find a bug

[Alex Herbert]

I updated JDK 17.0.6 to 17.0.9 and lang now builds on my mac:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Java version: 17.0.9, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

So this is a JDK issue.

Alex

On Tue, 12 Dec 2023 at 11:51, Gary Gregory  wrote:
>
> See the GutHub builds as well. Make sure you have the latest Java version
> of the major release line you are using, which is not the case here, and
> might not matter.
>
> Note that some of the tests make allowances for bugs in the JDK date
> classes.
>
> Gary
>
> On Tue, Dec 12, 2023, 6:18 AM Alex Herbert  wrote:
>
> > I can confirm I see 3 test failures in the FastDateParser using:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
> > /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"
> >
> > ---
> > [ERROR]
> >  
> > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
> > java.text.ParseException: Unparseable date: Tempo universale
> > coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo
> > universale coordinato', parser = 'FastDateParser[z, it, GMT]'
> > [ERROR]
> >  
> > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
> > java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko,
> > zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko,
> > GMT]'
> > [ERROR]
> >  
> > FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172
> > java.text.ParseException: Unparseable date: normaltid – Kanton: with
> > locale = nb, id = 'Pacific/Kanton', timeZone =
> >
> > sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null]
> > ...
> > ---
> >
> > Build is fine using on MacOS using:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Java version: 11.0.18, vendor: Eclipse Adoptium, runtime:
> > /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"
> >
> > Build is fine on Linux JDK 17 using:
> >
> > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
> > Java version: 17.0.4.1, vendor: Oracle Corporation, runtime:
> > /usr/lib/jvm/jdk-17.0.4.1
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family:
> > "unix"
> >
> > The GH actions builds are green for MacOS latest on all JDKs. I see
> > you are using a similar OS version to my mac. So this may be a MacOS
> > Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else
> > can replicate it on MacOS.
> >
> > Alex
> >
> > On Tue, 12 Dec 2023 at 08:52, Charles Stockman
> >  wrote:
> > >
> > > Hello and thanks for your help.
> > >
> > >
> > > How do I compile or did I find a bug ?
> > >
> > >
> > > I have been been attempting to build the latest version of Apache
> > >
> > > Common-Lang.
> > >
> > >
> > > The GitHub repository that I have used is
> > >
> > > https://github.com/apache/commons-lang.git
> > >
> > >
> > > I have the billed instructions mentioned in the following section :
> > >
> > > https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building
> > >
> > >
> > > The maven and java version that I have used is:
> > >
> > >
> > > Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
> > >
> > > Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
> > >
> > > Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: =
> > >
> > > /Users/charlesstockman/.sdkma

Re: Apache Common Lang -- How do I compile or did I find a bug

[Alex Herbert]

I can confirm I see 3 test failures in the FastDateParser using:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

---
[ERROR]   
FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
java.text.ParseException: Unparseable date: Tempo universale
coordinato: with locale = it, zIndex = 3, tzDisplay = 'Tempo
universale coordinato', parser = 'FastDateParser[z, it, GMT]'
[ERROR]   
FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_DateFormatSymbols:82->testTimeZoneStrategyPattern_DateFormatSymbols_getZoneStrings:147
java.text.ParseException: Unparseable date: 세계 표준시: with locale = ko,
zIndex = 3, tzDisplay = '세계 표준시', parser = 'FastDateParser[z, ko,
GMT]'
[ERROR]   
FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategy_TimeZone:88->testTimeZoneStrategyPattern_TimeZone_getAvailableIDs:172
java.text.ParseException: Unparseable date: normaltid – Kanton: with
locale = nb, id = 'Pacific/Kanton', timeZone =
sun.util.calendar.ZoneInfo[id="Pacific/Kanton",offset=4680,dstSavings=0,useDaylight=false,transitions=5,lastRule=null]
...
---

Build is fine using on MacOS using:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Java version: 11.0.18, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

Build is fine on Linux JDK 17 using:

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
Java version: 17.0.4.1, vendor: Oracle Corporation, runtime:
/usr/lib/jvm/jdk-17.0.4.1
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-167-generic", arch: "amd64", family: "unix"

The GH actions builds are green for MacOS latest on all JDKs. I see
you are using a similar OS version to my mac. So this may be a MacOS
Sonoma 14 vs MacOS Ventura 13 issue. It would be good if someone else
can replicate it on MacOS.

Alex

On Tue, 12 Dec 2023 at 08:52, Charles Stockman
 wrote:
>
> Hello and thanks for your help.
>
>
> How do I compile or did I find a bug ?
>
>
> I have been been attempting to build the latest version of Apache
>
> Common-Lang.
>
>
> The GitHub repository that I have used is
>
> https://github.com/apache/commons-lang.git
>
>
> I have the billed instructions mentioned in the following section :
>
> https://github.com/apache/commons-lang?tab=3Dreadme-ov-file#building
>
>
> The maven and java version that I have used is:
>
>
> Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
>
> Maven home: /opt/homebrew/Cellar/maven/3.9.6/libexec
>
> Java version: 17.0.7, vendor: Eclipse Adoptium, runtime: =
>
> /Users/charlesstockman/.sdkman/candidates/java/17.0.7-tem
>
> Default locale: en_US, platform encoding: UTF-8
>
> OS name: "mac os x", version: "13.4", arch: "aarch64", family: =
>
> "mac"
>
>
> The steps were
>
>
> 1. git clone https://github.com/apache/commons-lang.git
>
> 1. cd commons-lang
>
> 2. mvn
>
>
> I have received the following error and attached the output
>
>
>
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.2.2:test (default-test) on 
> project commons-lang3: There are test failures.
>
> [ERROR]
>
> [ERROR] Please refer to 
> /Users/charlesstockman/otherGit/commons-lang/target/surefire-reports for the 
> individual test results.
>
> [ERROR] Please refer to dump files (if any exist) [date].dump, 
> [date]-jvmRun[N].dump and [date].dumpstream.
>
> [ERROR] -> [Help 1]
>
> [ERROR]
>
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
>
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
> [ERROR]
>
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
>
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
>
> charlesstockman@Charless-Mini commons-lang %
>
>
>

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

Re: [LAZY] was: [VOTE] Release Apache Commons Parent 65 based on RC1

[Alex Herbert]

On Sat, 18 Nov 2023 at 12:49, Gary Gregory  wrote:
>
> On Sat, Nov 18, 2023 at 3:36 AM Alex Herbert  wrote:
> >
> > Installed from the maven tag.
> >
> > Built lang and statistics using JDK 8 and 11:
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Maven home: /Users/ah403/mvn/mvn
> > Java version: 1.8.0_362, vendor: Temurin, runtime:
> > /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/jre
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac"
> >
> > Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> > Maven home: /Users/ah403/mvn/mvn
> > Java version: 11.0.18, vendor: Eclipse Adoptium, runtime:
> > /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"
> >
> > lang:
> > Fails on SpotBugs with 9 errors. Rerunning with -Dspotbugs.skip works.
> > I did not fix the source.
> >
> > statistics:
> > Fails on SpotBugs with 1 error in the inference module. Fixed in the source.
> > Fails on checkstyle under JDK 11 with errors due to private final
> > classes not declared as final. This is a strange one as IIRC other
> > tools state that the keyword is redundant. I have corrected in source
> > for now.
>
> The keyword cannot be redundant, otherwise, this would not work:
>
> public class Root {
>
> private static class SP1 {
> }
>
> private static class SP2 extends SP1 {
> }
>
> private class P1 {
> }
>
> private class P2 extends P1 {
> }
> }
>
> Or am I missing something?

The fact that it is private means that the final keyword to prevent
extension by others is mute. It does of course prevent extension by
yourself. But since you control the source then you can add or drop it
as desired. It makes no difference to downstream consumers of the
class.

Alex

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

Re: [LAZY] was: [VOTE] Release Apache Commons Parent 65 based on RC1

[Alex Herbert]

Installed from the maven tag.

Built lang and statistics using JDK 8 and 11:

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /Users/ah403/mvn/mvn
Java version: 1.8.0_362, vendor: Temurin, runtime:
/Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac"

Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
Maven home: /Users/ah403/mvn/mvn
Java version: 11.0.18, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"

lang:
Fails on SpotBugs with 9 errors. Rerunning with -Dspotbugs.skip works.
I did not fix the source.

statistics:
Fails on SpotBugs with 1 error in the inference module. Fixed in the source.
Fails on checkstyle under JDK 11 with errors due to private final
classes not declared as final. This is a strange one as IIRC other
tools state that the keyword is redundant. I have corrected in source
for now.

+1

Alex

On Sat, 18 Nov 2023 at 03:42, Gary Gregory  wrote:
>
> I should have said this is a LAZY VOTE.
>
> Gary
>
> On Fri, Nov 17, 2023, 9:22 PM Gary Gregory  wrote:
>
> > We have made some enhancements since Apache Commons Parent 64 was
> > released, so I would like to release Apache Commons Parent 65.
> >
> > Apache Commons Parent 65 RC1 is available for review here:
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1 (svn
> > revision 65392)
> >
> > The Git tag commons-parent-65-RC1 commit for this RC is
> > d6b68690bead91ce5ac31347df2d56f48aa97489 which you can browse here:
> >
> > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=d6b68690bead91ce5ac31347df2d56f48aa97489
> > You may checkout this tag using:
> > git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> > --branch 
> > commons-parent-65-RC1 commons-parent-65-RC1
> >
> > Maven artifacts are here:
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1673/org/apache/commons/commons-parent/65/
> >
> > These are the artifacts and their hashes:
> >
> > #Release SHA-512s
> > #Fri Nov 17 21:03:32 EST 2023
> >
> > commons-parent-65-bom.json=b2f18d4e4da464cb3b677d6f474da13b3c728cbbdeed82dda6a0d21c903352da4220635557e6d08d4240b0cb4f67268759bcddc037cc80f9976dea69f072f09e
> >
> > commons-parent-65-bom.xml=5b59a00e18ed0a71dbbc8b47eaf9f84f35ac066ea94ee47ff1fc0580c8dd602b74cd122b909e97e5359e74bc6b164025da9858d53ed14e382a97edde7ac17a14
> >
> > commons-parent-65-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c
> >
> > commons-parent-65-src.tar.gz=afc826950640e31bf61a16d61a953ddbf479a5ed8018a1051246802364c1eeef9aeb523233086837963db236ccc812b0007a381ef1394362a54c92031c9ce82e
> >
> > commons-parent-65-src.zip=8ae1a2a7e97d39f231aac0e20cc16724d5aecee62256c472496058d1fcd11e07f3c92d1515d5a42f41a0ce5d8282db734b6c21a9dd996861b5b7336f68fcdce6
> >
> > org.apache.commons_commons-parent-65.spdx.json=a9814adf2044737f18936037ef5427e7b3d2ce01d5e1f5516d4efcd411f7b532f97f5225da640667dc4fcf286bda1052f274875653698630fcde6458d74faa68
> >
> > I have tested this with
> >
> > mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site
> > deploy
> >
> > Using:
> >
> > Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546)
> > Maven home: /usr/local/Cellar/maven/3.9.5/libexec
> > Java version: 21.0.1, vendor: Homebrew, runtime:
> > /usr/local/Cellar/openjdk/21.0.1/libexec/openjdk.jdk/Contents/Home
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "14.1.1", arch: "x86_64", family: "mac"
> > Darwin gdg-mac-mini.local 23.1.0 Darwin Kernel Version 23.1.0: Mon Oct
> >  9 21:27:27 PDT 2023; root:xnu-10002.41.9~6/RELEASE_X86_64 x86_64
> >
> > Details of changes since 64 are in the release notes:
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/RELEASE-NOTES.txt
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/site/changes-report.html
> >
> > Site:
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/site/index.html
> > (note some *relative* links are broken and the 65 directories are
> > not yet created - these will be OK once the site is deployed.)
> >
> > RAT Report:
> >
> > https://dist.apache.org/repos/dist/dev/commons/parent/65-RC1/site/rat-report.html
> >
> > KEYS:
> >   https://downloads.apache.org/commons/KEYS
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner than 72 hours from now.
> >
> >   [ ] +1 Release these artifacts
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > Thank you,
> >
> > Gary Gregory,
> > 

Re: (commons-rng) branch master updated: Normalize spelling to US English

[Alex Herbert]

Note:

On Tue, 31 Oct 2023 at 10:21,  wrote:
> Normalize spelling to US English

>  .../commons/rng/examples/stress/RNGUtils.java  | 30 
> ++

> +/** Message for an unrecognized source64 mode. */
> +private static final String UNRECOGNISED_SOURCE_64_MODE = "Unrecognized 
> source64 mode: ";

Change the constant name too.

> +/** Message for an unrecognized native output type. */
> +private static final String UNRECOGNISED_NATIVE_TYPE = "Unrecognized 
> native output type: ";

Change the constant name too.

Alex

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

Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot

[Alex Herbert]

I opened a PR after changing the expected failure probability to 1e-5.

I had an old version of the GH build file when I estimated it used 4
runs. The latest CI runs 4 JDKs on 3 platforms plus CodeQL and
coverage. So this is 14 runs. We should see failures with a
probability of:

(1 - (1 - 1e-5)**14) = 0.0001399, or approximately 1 in 7143.

Compare that to previously:

(1 - (1 - 1e-3)**14) = 0.01391, or approximately 1 in 71.89.

If this is still a problem moving forward then we can replace with a
fixed random number generator calling the underlying method and test
coverage of the original method by other means.

Alex

On Fri, 20 Oct 2023 at 20:16, Gary D. Gregory  wrote:
>
> Hi Alex,
>
> I'd prefer if you could give a shot at adjusting this test when you can take 
> the time.
>
> TY,
> Gary
>
> On 2023/10/20 18:17:35 Alex Herbert wrote:
> > On Fri, 20 Oct 2023 at 18:55, Alex Herbert  wrote:
> > >
> > > The chi-square critical value (13.82) is correct:
> > >
> > > >>> from scipy.stats import chi2
> > > >>> chi2(2).isf(0.001)
> > > 13.815510557964274
> > >
> > > The test seems to fail with the expected frequency when run locally. I
> > > annotated with:
> > >
> > > @RepeatedTest(value = 10)
> > >
> > > I observe 93 failures (just under 1 in 1000). So it is strange this
> > > fails a lot on the GH CI build.
> > >
> > > We could just use a fixed Random argument to the call that is
> > > ultimately performing the random string generation:
> > >
> > > random(count, 0, chars.length, false, false, chars, random());
> > >
> > > Switch the test to:
> > >
> > > Random rng = new Random(0xdeadbeef)
> > >
> > > gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng);
> > >
> > > You will see a drop in coverage by not exercising the public API.
> > >
> > > The alternative is to change the chi-square critical value:
> > >
> > > 1 in 10,000: 18.420680743952364
> > > 1 in 100,000: 23.025850929940457
> > > 1 in 1,000,000: 27.631021115928547
> > >
> > > Alex
> >
> > Also note that although the test fails 1 in 1000 times, we run 4
> > builds in CI (coverage + 3 JDKS). So we expect to see failure with a
> > p-value of:
> >
> > 1 - (1 - 0.001)^4 = 0.00399
> >
> > This is the probability of not seeing a failure subtracted from 1. It
> > is approximately 1 in 250.
> >
> > I did check the computation of the chi-square statistic and AFAIK it is 
> > correct.
> >
> > My suggestion for a first change is to bump the critical value to the
> > level for 1 in 100,000. We should then see failures every 25,000 GH
> > builds. If the frequency is more than that then we have to assume that
> > the ThreadLocalRandom instance is not uniformly sampling from the set
> > of size 3. I find this unlikely as the underlying algorithm for
> > ThreadLocalRandom is good [1].
> >
> > Alex
> >
> > [1] IIRC it passes the Test U01 BigCrush test for random generators
> >
> > -
> > 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: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot

[Alex Herbert]

On Fri, 20 Oct 2023 at 18:55, Alex Herbert  wrote:
>
> The chi-square critical value (13.82) is correct:
>
> >>> from scipy.stats import chi2
> >>> chi2(2).isf(0.001)
> 13.815510557964274
>
> The test seems to fail with the expected frequency when run locally. I
> annotated with:
>
> @RepeatedTest(value = 10)
>
> I observe 93 failures (just under 1 in 1000). So it is strange this
> fails a lot on the GH CI build.
>
> We could just use a fixed Random argument to the call that is
> ultimately performing the random string generation:
>
> random(count, 0, chars.length, false, false, chars, random());
>
> Switch the test to:
>
> Random rng = new Random(0xdeadbeef)
>
> gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng);
>
> You will see a drop in coverage by not exercising the public API.
>
> The alternative is to change the chi-square critical value:
>
> 1 in 10,000: 18.420680743952364
> 1 in 100,000: 23.025850929940457
> 1 in 1,000,000: 27.631021115928547
>
> Alex

Also note that although the test fails 1 in 1000 times, we run 4
builds in CI (coverage + 3 JDKS). So we expect to see failure with a
p-value of:

1 - (1 - 0.001)^4 = 0.00399

This is the probability of not seeing a failure subtracted from 1. It
is approximately 1 in 250.

I did check the computation of the chi-square statistic and AFAIK it is correct.

My suggestion for a first change is to bump the critical value to the
level for 1 in 100,000. We should then see failures every 25,000 GH
builds. If the frequency is more than that then we have to assume that
the ThreadLocalRandom instance is not uniformly sampling from the set
of size 3. I find this unlikely as the underlying algorithm for
ThreadLocalRandom is good [1].

Alex

[1] IIRC it passes the Test U01 BigCrush test for random generators

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

Re: [lang] RandomStringUtilsTest.testRandomStringUtilsHomog fails a lot

[Alex Herbert]

The chi-square critical value (13.82) is correct:

>>> from scipy.stats import chi2
>>> chi2(2).isf(0.001)
13.815510557964274

The test seems to fail with the expected frequency when run locally. I
annotated with:

@RepeatedTest(value = 10)

I observe 93 failures (just under 1 in 1000). So it is strange this
fails a lot on the GH CI build.

We could just use a fixed Random argument to the call that is
ultimately performing the random string generation:

random(count, 0, chars.length, false, false, chars, random());

Switch the test to:

Random rng = new Random(0xdeadbeef)

gen = RandomStringUtils.random(6, 0, 3, false, false, chars, rng);

You will see a drop in coverage by not exercising the public API.

The alternative is to change the chi-square critical value:

1 in 10,000: 18.420680743952364
1 in 100,000: 23.025850929940457
1 in 1,000,000: 27.631021115928547

Alex

On Fri, 20 Oct 2023 at 18:44, Elliotte Rusty Harold  wrote:
>
> It's possible the chi square test is miscalculated. Perhaps some stats
> expert can check that. It's also possible the chi square test isn't
> the right one to use here. Again, consult a stats expert.
>
> It's also very possible that the randomness is not nearly as random as
> it's supposed to be. That's incredibly common, and that might be
> noticeable given the very short three-letter character set [a, b, c]
> being picked from.
>
> On Fri, Oct 20, 2023 at 1:31 PM Gary D. Gregory  wrote:
> >
> > Despite the failure comment:
> >
> > RandomStringUtilsTest.testRandomStringUtilsHomog:474 test homogeneity -- 
> > will fail about 1 in 1000 times ==> expected:  but was: 
> >
> > This test fails a LOT more than once every 1000 times, based on how many 
> > GitHub builds I need to restart every week.
> >
> > What can be done to make this test more resilient?
> >
> > TY!
> > Gary
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.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: [ALL] Java CI badge does not agree with workflow status

[Alex Herbert]

Navigating to the Java CI workflow you can generate a badge using the
... menu in the top right next to the search filter. This creates a
badge with a different URL to that currently in use:

Current:
[![GitHub Actions
Status](https://github.com/apache/commons-build-plugin/workflows/Java%20CI/badge.svg)](https://github.com/apache/commons-build-plugin/actions)

Generated:
[![Java 
CI](https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml/badge.svg)](https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml)

Using the badge URL shows a green badge.

Another working version from Statistics is the same E.g.:

https://github.com/apache/commons-statistics/actions/workflows/maven.yml/badge.svg

So try a badge update with a different URL.

Alex



On Fri, 20 Oct 2023 at 16:03, sebb  wrote:
>
> The build-plugin readme shows a failing Java CI build:
>
> https://github.com/apache/commons-build-plugin
>
> However the build has been working for ages:
>
> https://github.com/apache/commons-build-plugin/actions/workflows/maven.yml
>
> Any idea how this can be fixed?
>
> Not much point having the badge if it is stale.
>
> Sebb
>
> -
> 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] Java 21 failure with a double

[Alex Herbert]

I've implemented a fix for this in PR 467 [1]. Builds now pass on JDK 21.

This does not change the DoubleFormat class. It adds javadoc to state
that the formatting is dependent on Double.toString.

The tests have been updated to use a different range for the random
doubles so the tests across formats should be testing roughly the same
precision. They should not test the full precision output (i.e. 17
digits).

Note that this change identified another mismatch between the
reference DecimalFormat and the DoubleFormat when a zero trails the
decimal point. The DecimalFormat class can omit this trailing zero and
the decimal point:

new DecimalFormat("##0.0##E0").format(1.129e-4) => 113E-6(not 113.0E-6)

The inelegant solution I used was to remove .0 from the DecimalFormat
output and recheck the string is a match. This allows the above case
to pass. There are no other cases in the 1000 random numbers that hit
this mismatch case.

A new test has been added for full precision output. The test requires
that the output format can be parsed back to the same number, i.e. no
loss of precision occurs when formatting. This seemed simpler than
writing custom code to check against the digits output from
Double.toString to ensure all digits are present.

Alex

[1] https://github.com/apache/commons-text/pull/467

On Mon, 16 Oct 2023 at 18:37, Alex Herbert  wrote:
>
> TLDR; The Double.toString(double) value is different for
> -9.354004711977437E17 on JDK 21 and earlier JDKs:
>
> JDK 21: -9.354004711977437E17
> JDK 17: -9.3540047119774374E17
>
> The DoubleFormat class is built upon Double.toString. So the test
> fails due to this change.
>
> ---
>
> More details:
>
> On JDK 21 Double.toString is dropping the last digit (a 4) as it is
> not required to uniquely represent the double from the next double up
> or down. Note the javadoc for toString states: "This decimal is
> (almost always) the shortest one that rounds to m according to the
> round to nearest rounding policy of IEEE 754 floating-point
> arithmetic." So this is not the closest decimal representation of the
> double, just the closest required for rounding to the double.
>
> I do not think this is a bug. But we should document that the
> DoubleFormat class is built upon the Double.toString representation of
> a double. This string may not be the closest decimal representation of
> the double. Thus final digit errors can be observed when using the
> entire character output of Double.toString compared to other
> formatting classes such as java.lang.DecimalFormat or the numerical
> string representation provided by java.lang.BigDecimal (see examples
> below).
>
> Q. How to fix the test?
>
> The DoubleFormatTest is using 1000 random double values with a base-2
> exponent of -100 to 100. Then testing against a plain text format of
> 0.00##. The exponent of 9.35e17 is 59. It is so large there are no
> digits after the decimal point. So the test is checking if
> DoubleFormat is accurate to 17 decimal digits of precision, which it
> is not in this case. The other tests using the random numbers test the
> formats:
>
> #,##0.0##
> 0.0##E0
> ##0.0##E0
>
> So the scientific and engineering tests are only checking 4 and 6
> decimal digits. But the plain formats are checking up to 17 digits due
> to the large exponent of the random numbers. This does not seem very
> fair.
>
> Fix 1: A simple fix would be to reduce the exponent range for random
> numbers so that the plain numbers should always have at least 4 digits
> after the decimal point.
>
> However, changing the test like this would reduce its power. It would
> not have alerted us to this failure.
>
> Fix 2: An alternative would be to change the test assertion to perform
> the current check, and if it fails perform a test that all digits from
> Double.toString are present in the formatted string in the same order
> (i.e. the class has used the entire output from Double.toString and so
> is at its limit). This is non-trivial as the double value is tested in
> all the installed locales which may change the digits and other
> formatting characters. The assertion would have to create a reverse
> parsing method based on the locale.
>
> Note: I did try using the DecimalFormat used to specify formatting the
> expected string to parse the string with DecimalFormat.parse. It
> worked on the original root locale but it failed on locale "he"; this
> may be another bug in DoubleFormat since the locale can parse its own
> output:
>
> jshell> var df = new java.text.DecimalFormat("0.0##",
> java.text.DecimalFormatSymbols.getInstance(Locale.forLanguageTag("he")))
> jshell> x
> x ==> -9.3540047119774374E17
> jshell> df.parse(df.f

Re: [Text] Java 21 failure with a double

[Alex Herbert]

TLDR; The Double.toString(double) value is different for
-9.354004711977437E17 on JDK 21 and earlier JDKs:

JDK 21: -9.354004711977437E17
JDK 17: -9.3540047119774374E17

The DoubleFormat class is built upon Double.toString. So the test
fails due to this change.

---

More details:

On JDK 21 Double.toString is dropping the last digit (a 4) as it is
not required to uniquely represent the double from the next double up
or down. Note the javadoc for toString states: "This decimal is
(almost always) the shortest one that rounds to m according to the
round to nearest rounding policy of IEEE 754 floating-point
arithmetic." So this is not the closest decimal representation of the
double, just the closest required for rounding to the double.

I do not think this is a bug. But we should document that the
DoubleFormat class is built upon the Double.toString representation of
a double. This string may not be the closest decimal representation of
the double. Thus final digit errors can be observed when using the
entire character output of Double.toString compared to other
formatting classes such as java.lang.DecimalFormat or the numerical
string representation provided by java.lang.BigDecimal (see examples
below).

Q. How to fix the test?

The DoubleFormatTest is using 1000 random double values with a base-2
exponent of -100 to 100. Then testing against a plain text format of
0.00##. The exponent of 9.35e17 is 59. It is so large there are no
digits after the decimal point. So the test is checking if
DoubleFormat is accurate to 17 decimal digits of precision, which it
is not in this case. The other tests using the random numbers test the
formats:

#,##0.0##
0.0##E0
##0.0##E0

So the scientific and engineering tests are only checking 4 and 6
decimal digits. But the plain formats are checking up to 17 digits due
to the large exponent of the random numbers. This does not seem very
fair.

Fix 1: A simple fix would be to reduce the exponent range for random
numbers so that the plain numbers should always have at least 4 digits
after the decimal point.

However, changing the test like this would reduce its power. It would
not have alerted us to this failure.

Fix 2: An alternative would be to change the test assertion to perform
the current check, and if it fails perform a test that all digits from
Double.toString are present in the formatted string in the same order
(i.e. the class has used the entire output from Double.toString and so
is at its limit). This is non-trivial as the double value is tested in
all the installed locales which may change the digits and other
formatting characters. The assertion would have to create a reverse
parsing method based on the locale.

Note: I did try using the DecimalFormat used to specify formatting the
expected string to parse the string with DecimalFormat.parse. It
worked on the original root locale but it failed on locale "he"; this
may be another bug in DoubleFormat since the locale can parse its own
output:

jshell> var df = new java.text.DecimalFormat("0.0##",
java.text.DecimalFormatSymbols.getInstance(Locale.forLanguageTag("he")))
jshell> x
x ==> -9.3540047119774374E17
jshell> df.parse(df.format(x)).doubleValue()
$32 ==> -9.3540047119774374E17

Fix 3: Implement fix 1, plus add a test for full length precision
using only the root locale. This can quickly test the output is at the
limit by checking the string creates the original input double using
Double.parseDouble, i.e. the DoubleFormat has captured the entire
information required to uniquely recreate the original double.

Alex

---

Here is the failure:

[ERROR] Failures:
[ERROR]   
DoubleFormatTest.testPlain_localeFormatComparison:491->checkLocalizedFormats:127->checkLocalizedFormat:121->assertLocalized
FormatsAreEqual:40 Unexpected output for locale [und] and double value
-9.354004711977437E17 ==> expected: <-935400471197743740.0> bu
t was: <-935400471197743700.0>

The Double.toString value is the minimum string required to uniquely
identify the double value; this is the string required to round trip
the number to a string and back via Double.parseDouble(String).
However, it may not be the closest decimal representation of the
value.

In the failed test the double value is -9.354004711977437E17 which can
be interpreted differently. I obtained the value that failed using
Double.doubleToLongBits. This has different representations depending
on how it is output:

jshell
|  Welcome to JShell -- Version 17.0.6
|  For an introduction type: /help intro

jshell> double x = Double.longBitsToDouble(-4347673023486037259L)
x ==> -9.3540047119774374E17

jshell> new BigDecimal(x)
$2 ==> -935400471197743744

// Using the DecimalFormat from the failing test:
jshell> new java.text.DecimalFormat("0.0##",
java.text.DecimalFormatSymbols.getInstance(Locale.ROOT)).format(x)
$3 ==> "-935400471197743740.0"

jshell> Math.nextUp(x)
$4 ==> -9.3540047119774362E17

jshell> Math.nextDown(x)
$5 ==> -9.3540047119774387E17


Note the difference for JDK 21:

Re: [ALL] Standardise Maven defaultGoal in components?

[Alex Herbert]

On Sun, 8 Oct 2023 at 22:53, sebb  wrote:
>
> > > On Oct 8, 2023, at 7:11 AM, sebb  wrote:
> > >
> > > There are currently lots of variations of the defaultGoal in different
> > > components.
> > >
> > > It may be sensible to establish a standard setting which components
> > > should adopt (unless there is a good reason to do otherwise).
> > >
> > > If so, what should that be, and where does it get documented?
> > >
> > > Personally, I don't think install should ever be a default goal as it
> > > changes the environment outside the component.
> > >
> > > Main goals seen:
> > > clean
> > > install
> > > package
> > > site
> > > test
> > > verify
> > >
> > > Other goals seen:
> > > apache-rat:check
> > > checkstyle:check
> > > clirr:check
> > > findbugs:check
> > > japicmp:cmp
> > > javadoc:javadoc
> > > pmd:check
> > > pmd:cpd-check
> > > spotbugs:check

Note that some poms will be configured to use executions to bind goals
to lifecycle phases. So the default goal may only be 'clean verify'
but many plugins will be executed. For example the commons-parent pom
runs apache-rat-plugin in the validate phase making this explicit goal
redundant in all our projects; the multi-module RNG component uses
'clean verify javadoc:javadoc' but executes PMD, SpotBugs and
Checkstyle in executions bound to the verify phase. There are also
some plugins that have executions bound to verify but activated by the
presence of a file, for example RevAPI/JApiCmp for modules building a
jar; these can be disabled by lack of a file for modules with a
non-jar packaging.

I think making the default goal run verify is appropriate as this is
where many validation plugins are conventionally configured to run. It
allows a quicker build with 'mvn test' and a full check with 'mvn'.

Alex

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

Re: [VOTE][LAZY] Release Apache Commons Parent 63 based on RC2

[Alex Herbert]

Can you provide the usage for the new  property?
This is listed in the release notes as a new feature thanks to
dependabot. But the commit was a single line added by Gary. I do not
think it is attributed to dependabot. It is added under the release
management section for properties for the Commons Release plugin but I
cannot find 'commons.conf.dir' referenced in the current release
plugin code.

Alex

On Mon, 2 Oct 2023 at 13:28, Gary Gregory  wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Parent 62 was released, so I would like to release Apache
> Commons Parent 63.
>
> Apache Commons Parent 63 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2
> (svn revision 64292)
>
> The Git tag commons-parent-63-RC2 commit for this RC is
> cf512e1352e886a50c1f292420dbc052bdedbf39 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=cf512e1352e886a50c1f292420dbc052bdedbf39
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-63-RC2 commons-parent-63-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1662/org/apache/commons/commons-parent/63/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Mon Oct 02 07:53:04 EDT 2023
> commons-parent-63-src.tar.gz=415919a83c9a84101c586e36da25aeacad9126119e5f3bee1de8db8e4dbda46c5b0a28a0c440ea64254533f31d31be5e2904838e1dd72d456e7befde7a6b2f77
> org.apache.commons_commons-parent-63.spdx.json=51ef87a005d61ad1aa1318770ad79f4decbe717d7a570266c3ad24223fe5f7e7fcaf0ef162a5e6dc232ba6f79799f484ce68345a8bf164bf52f6992bf6d5cc7c
> commons-parent-63-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c
> commons-parent-63-src.zip=3674e727c8a770117d40d21812d581774446d9144a9625d3b45535231ccc9ad7e923397d1e9df16133888fbcc8745c573639f89523ba3dd360d459d08069eea1
> commons-parent-63-bom.json=d08fbea2168dcd027d6c2928c3604f22b081d4d88fd480f1f2b282c3ac32a15f312e47e72ad0d0f525680e931d311fe51472e9b6450e2bde5ee1a3f4632aaad2
> commons-parent-63-bom.xml=36d3cb1aed436d44fbb97ef16e1e603196598dea68cc113ebfe630c7044a214132c6e7444f32f4e90ba8bf5d47f357d3426afa37b4ea6a8e735ddd666e8d0744
>
> I have tested this with:
>
> mvn -V -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy
>
> using:
>
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: /usr/local/Cellar/maven/3.9.4/libexec
> Java version: 17.0.8.1, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@17/17.0.8.1/libexec/openjdk.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "14.0", arch: "x86_64", family: "mac"
>
> Darwin  23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:42:42
> PDT 2023; root:xnu-10002.1.13~1/RELEASE_X86_64 x86_64
>
> Details of changes since 62 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/site/index.html
> (note some *relative* links are broken and the 63 directories are
> not yet created - these will be OK once the site is deployed.)
>
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> garydgregory,
> Release Manager (using key DEADBEEF)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1a) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-63-RC2 commons-parent-63-RC2
> cd commons-parent-63-RC2
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/63-RC2/source
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page
> which you then must check.
>
> mvn clirr:check
>
> Newer components use 

Re: [BUILD-PLUGIN] Drop component list from README template?

[Alex Herbert]

On Mon, 2 Oct 2023 at 10:05, sebb  wrote:
>
> The Build Plugin currently includes a list of components in the README 
> template.
>
> This duplicates information provided elsewhere, and gets out of date.
>
> Since this info is in every GH repo, any changes also need to be
> applied to every one of them, to ensure they are up to date.
>
> This is an unnecessary maintenance burden.
>
> I think this local list should be dropped, and replaced with a link to
> the main website.

+1

Alex

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

[statistics] descriptive module

[Alex Herbert]

I have been looking at continuing the work on the descriptive module
to add the remaining stats found in Commons Math. Before adding more
classes I would like to address the current implementation pattern.

The statistics in the descriptive module are currently abstract
classes with a concrete inner class that is prefixed Storeless.

This pattern would make sense if there was the intention to provide
stored implementations. Currently I do not think this would be the
best solution. For example it would make sense to separate the storage
of a variable size stream of double values, from the computation of a
statistic. That is, a resizable backing array storage is out of scope
for this module.

I propose to simplify the current implementations to final classes
that implement the current Storeless functionality. Any future change
to stored, immutable, or other implementations can be provided by
changing the final class back to abstract with different
implementations.

Alex

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

Re: [MATH] Inconsistent artifactId for parent pom

[Alex Herbert]

On Wed, 20 Sept 2023 at 14:24, sebb  wrote:
>
> The artifactId for the parent pom is
>
> commons-math-parent
>
> whereas all the child poms have the prefix
>
> commons-math4-
>
> Seems to me this ought to be fixed before the first GA release
> (current is 4.0-beta2)

The current parent was probably copied from one of the derived
multi-module projects (e.g. RNG/Numbers) which are still on major
version 1. Feel free to fix it in git master.

Alex

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

Re: [DRAFT][REPORT] September 2023

[Alex Herbert]

You could add that we had a successful participant in Google Summer of
Code 2023 working on the statistics sub-project. This may apply to the
community section.

Alex

On Wed, 13 Sept 2023 at 02:59, Gary Gregory  wrote:
>
> Here is the report I plan on filing, probably in the AM (EST):
>
> ## Description:
> The mission of Apache Commons is the creation and maintenance of Java-focused
> reusable libraries and components.
>
> ## Project Status:
> Current project status: Ongoing with moderate activity.
> Issues for the board: None.
>
> ## Membership Data:
> Apache Commons was founded 2007-06-19 (16 years ago)
> There are currently 149 committers and 42 PMC members in this project.
> The Committer-to-PMC ratio is roughly 5:2.
>
> Community changes, past quarter:
> - No new PMC members. Last addition was Matt Juntunen on 2021-06-25.
> - No new committers. Last addition was Claude Warren on 2022-02-01.
>
> ## Project Activity:
> Our recent releases are:
> - COMPRESS-1.24.0 was released on 2023-09-08.
> - PARENT-62 was released on 2023-09-05.
> - DBCP-2.10.0 was released on 2023-09-03.
> - PARENT-61 was released on 2023-08-29.
> - PARENT-60 was released on 2023-08-23.
> - DBUTILS-1.8.0 was released on 2023-08-08.
> - LANG-3.13.0 was released on 2023-07-28.
> - PARENT-59 was released on 2023-07-26.
> - FILEUPLOAD-2.0.0-M1 was released on 2023-07-19.
> - BUILD-PLUGIN-1.13 was released on 2023-06-28.
> - RELEASE-PLUGIN-1.8.1 was released on 2023-06-28.
> - CODEC-1.16.0 was released on 2023-06-21.
>
> ## Community Health:
> We have had much more activity on the mailing lists, Jira, and GitHub. We are
> also reviewing security reports as they come in and have been working through
> that backlog.
>
> Gary
>
> -
> 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: [collections] AbstractLinkedList is source incompatible with JDK 21

[Alex Herbert]

On Fri, 8 Sept 2023 at 13:46, Alex Herbert  wrote:



> The problem then becomes how to support AbstractLinkedList and
> CursorableLinkedList. Currently collections4 will not be source
> compatible with JDK 21. Any downstream project that extends these
> classes will not be source compatible with JDK 21.

Extra:

Note that this incompatibility is true when targeting Java 21 as the release.

If compiling for an earlier Java release then this is possible using
JDK 21 via the javac --release flag.

Collections is a very long way from targeting Java 21 (it currently
targets Java 8). A third option would be:

3. Simply mark the methods as deprecated

This acknowledges the issue but does nothing to fix it. The fix can be
done with the bump to collections 5 when that happens. This will not
support cutting edge users who are targeting Java 21. This would be
expected to be a subset of the unknown number of users for these
classes. A workaround would be the user uses a local copy of the class
to allow source compilation (license permitting).

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

[collections] AbstractLinkedList is source incompatible with JDK 21

[Alex Herbert]

JDK 21 has added these methods to java.util.List:

default public void addFirst(E o)
default public void addLast(E o)

These are source incompatible with Commons Collections AbstractLinkedList:

public boolean addFirst(E o)
public boolean addLast(E o)

This affects AbstractLinkedList and any list that extends it
(CursorableLinkedList and NodeCachingLinkedList).

This issue was identified by Julian Reschke (see [1, 2]) due to use of
code that extends AbstractLinkedList in Apache Jackrabbit.

The source incompatibility means that collections, or any project that
extends these List classes, cannot be compiled with Java 21. Class
files compiled with Java < 21 are runtime compatible with Java 21.

A performance test (on one machine) shows that NodeCachingLinkedList
may no longer offer any performance gain over the base implementation.
The NodeCachingLinkedList differs in that it reuses nodes rather than
allowing garbage collection. Subject to further performance testing,
this implementation can be deprecated.

CursorableLinkedList provides functionality not in the JDK LinkedList.
This is to allow concurrent changes to the list with list methods and
iterator methods, or multiple iterators, for the lifetime of all
iterators. In contrast JDK LinkedList only allows modification to the
list via the (single) iterator during the lifetime of the iterator.

The problem then becomes how to support AbstractLinkedList and
CursorableLinkedList. Currently collections4 will not be source
compatible with JDK 21. Any downstream project that extends these
classes will not be source compatible with JDK 21.

Possible solutions:

1. Duplicate AbstractLinkedList (and possibly CursorableLinkedList) in
collections4 and update the methods signatures to be compatible in the
duplicate.

This solution allows collections4 to be compiled with JDK 8, 11, 17.
It cannot be compiled with 21. Any downstream project can extend the
duplicate class and be compiled under Java 21 (assuming all references
to incompatible classes are removed).

2. Bump collections major version to 5 and fix the incompatibility.

Note that collections 4.4 was released in Jul 2019. This option could
perform one last release of collections 4 to release all fixes and
changes, then proceed to collections 5 for the development branch.

I am unfamiliar with the entire collections codebase and the clean-up
work required for a major revision bump. Note the new bloomfilter
package is as yet unreleased. So choosing this option provides the
ability to release a 5-beta to receive community feedback on the
bloomfilter API before an official release.

Any other options are welcomed for discussion.

Alex

[1] https://lists.apache.org/thread/lnrzdv348q8g64dlno6xq84wb49vbc2c
[2] https://issues.apache.org/jira/browse/COLLECTIONS-842

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

Re: [commons-math] function or Number class to count/track number of significant figures

[Alex Herbert]

On Wed, 9 Aug 2023 at 17:13, Daniel Watson  wrote:

> BigSigFig result = new BigSigFig("1.1").multiply(new BigSigFig("2"))

Multiply is easy as you take the minimum significant figures. What
about addition?

12345 + 0.0001

Here the significant figures should remain at 5.

And for this:

12345 + 10.0
12345 + 10
12345 + 1
12345 + 1.0
12345 + 1.00

You have to track the overlap of significant digits somehow.

Alex

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

Re: [commons-math] function or Number class to count/track number of significant figures

[Alex Herbert]

On Wed, 9 Aug 2023 at 15:43, Daniel Watson  wrote:
>
> Hope that answers more questions than it creates!

It does not address the issue of the last significant zero, e.g:

1 (4 sf)
1 (3 sf)
1 (2 sf)

One way to solve this with standard parsing would be to use scientific notation:

1.000e4
1.00e4
1.0e4

Note that for the example of inch to cm conversions the value 2.54
cm/inch is exact. This leads to the issue that there should be a way
to exclude some input from limiting the detection of the lowest
significant figure (i.e. mark numbers as exact). This puts some
responsibility on the provider of the data to follow a format; and
some on the parser to know what fields to analyse.

Alex

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

Re: [commons-math] function or Number class to count/track number of significant figures

[Alex Herbert]

Hi,

On Wed, 9 Aug 2023 at 12:27, Daniel Watson  wrote:

> This feature is necessary when working with scientific/clinical data which
> was reported with significant figures in mind, and for which calculation
> results must respect the sigfig count. As far as I could tell there is no
> Number implementation which correctly respects this. e.g.
>
> "11000" has 2 significant figures,
> "11000." has 5
> ".11000" has 5
> "11000.0" has 6

This functionality is not in Commons AFAIK. Is the counting to accept
a String input?

Q. What is the use case that you would read data in text format and
have to compute the significant figures? Or are you reading data in
numeric format and computing the decimal significant figures of the
base-2 data representation? Note: Differences between base-10 and
base-2 representations can lead to an implementation that satisfies
one use case and not others due to rounding conversions (see
NUMBERS-199 [1]). I would advise against this and only support text
input when referring to decimal significant figures.

I presume you have input data of unknown precision, are computing
something with it, then outputting a result and wish to use the
minimum significant figures from the input data. If the output
significant figures are critical then this is a case where I would
expect the reported significant figures to be manually verified; thus
automation only partly increases efficiency by providing a first pass.

Note: I do not think there is an easy way to handle trailing zeros
when not all the zeros are significant [1]. This is in part due to the
different formats used for this such as an overline/underline on the
last significant digit. I do not think we wish to support parsing of
non-ascii characters and multiple options to identify significant
zeros. Thoughts on this?

Secondly, you are reliant on the text input being correctly formatted.
For example if I include the number 1, it would have to be represented
as e.g. 1.000 to not limit the significant figures of the rest of the
input data.

Thirdly, if accepting string input then you have the issue of first
identifying if the string is a number. This is non-trivial. For
example there is a function to do it in o.a.c.lang3.math in
NumberUtils.isCreatable.

Finding a home in commons will elicit different opinions from the
various contributors. The math and numbers projects are more related
to numeric computations. They output results in a canonical format,
typically the JDK toString representation of the number(s).
Conversions to different formats are not in scope, and parsing is
typically from the canonical format using JDK parse methods. There is
a o.a.c.text.numbers package in the text component that currently has
formatting for floating-point numbers to various text representations.
But parsing of Strings is not supported there. And lang has the
NumberUtils.

As for a class that tracks significant figures through a computation,
that will require some consideration. Do we create the class to wrap
Number and track significant digits of a configurable base. This would
allow BigDecimal with base 10, or int and double with base 2. Since
Number does not specify arithmetic then this has to be captured
somehow. It may be able to use the Numbers implementation of Field [3]
in o.a.c.numbers.field. Or simplify to only using a BigDecimal
wrapper.

In summary this may be simpler with an ideal use case. For example the
input is text, it must be parable to a BigDecimal and the number of
significant figures is identified using the text input. Support of
significant zeros is limited to the full length of the trailing zeros,
or the first zero if no decimal point is provided. This could be
handled with a parse method that returns both the BigDecimal and the
significant figures.

Alex

[1] https://issues.apache.org/jira/browse/NUMBERS-199
[2] 
https://en.wikipedia.org/wiki/Significant_figures#Ways_to_denote_significant_figures_in_an_integer_with_trailing_zeros
[3] http://mathworld.wolfram.com/Field.html

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

Re: [VOTE][LAZY] Release Apache Commons Parent 59 based on RC1

[Alex Herbert]

I installed it locally from the git tag. I build the following
projects with their default mvn goal using:

Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /usr/local/apache-maven-3
Java version: 1.8.0_362, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-153-generic", arch: "amd64", family: "unix"

RNG
Numbers
Statistics
Lang
Text

No issues found except some javadoc warnings in Text when linking to
private members. I have fixed this in master.

+1

On Sat, 22 Jul 2023 at 21:34, Gary Gregory  wrote:
>
> We have updated the Apache Commons POM since Apache Commons Parent 58
> was released, so I would like to release Apache Commons Parent 59.
>
> Apache Commons Parent 59 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1
> (svn revision 63135)
>
> The Git tag commons-parent-59-RC1 commit for this RC is
> 86b1b6f9575219f9009cdc89ddf3f1450e9f8982 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=86b1b6f9575219f9009cdc89ddf3f1450e9f8982
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-59-RC1 commons-parent-59-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1646/org/apache/commons/commons-parent/59/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Jul 22 16:24:00 EDT 2023
> commons-parent-59-bom.json=094208bc437b500fd33853d186fda8728257519ab0fe59dbfcb1d0eb96a822a9f0fbbcb103d29539dada9b2ddd7ef530197bfd2558d112e006e327931ceb35da
> commons-parent-59-bom.xml=1a7b5b636ceb6c2b1cd23a31d2b4c19f35fe7c037502e439132d86e85b367fbc173c17a7a60449a6b9073194b2c2987762a4cc54e68211a55015745bdb1a5c88
> commons-parent-59-site.xml=c6aea4f2c03920366bee23b08b046dacc09710e92c78ccd83f47cd92f89bc53abc3b8bbc7f44017ee94a2cb022ce763fe3f7d8c9aa42d571350269ba6568ca07
> commons-parent-59-src.tar.gz=71acd5fb605fa2eaede743319a7ad0aed57bfa438152a84dd284bf075807d91a4db52251c718c0d3428a80f43d0022f678ca74a784a80f14f063d1973e6ade7b
> commons-parent-59-src.zip=080f4deab4863f64f5324e4f43e25a1b7dfef96962dd4afc3227356155aa1aa7fdc314c8499777058789b0748f332b8ad91ba3d5f2b67457a494e9380204d758
> org.apache.commons_commons-parent-59.spdx.json=b9614d9c1143eb8c7f5d79c3ec19f701ba395fe903e3f18280b245e35296e0a9f4ad53eeea85e6b59c0751c85e1a6db71cf5fd5a58b0c0e6ee9da09737626657
>
> I have tested this with
>
> mvn -V -Ddoclint=none -Prelease -Ptest-deploy clean package site deploy
>
> using:
>
> Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
> Maven home: /usr/local/Cellar/maven/3.9.3/libexec
> Java version: 1.8.0_372, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+372/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.4.1", arch: "x86_64", family: "mac"
> Darwin  22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:22
> PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64
>
> Details of changes since 58 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/site/index.html
> (note some *relative* links are broken and the 59 directories are
> not yet created - these will be OK once the site is deployed.)
>
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key DEADBEEF)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1a) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-59-RC1 commons-parent-59-RC1
> cd commons-parent-59-RC1
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/59-RC1/source
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still 

Re: [Pool] Toward version 2.12.0 and 3.0

[Alex Herbert]

On Wed, 19 Jul 2023 at 19:38, Gary Gregory  wrote:
>
> OK, that sounds good.
>
> Gary
>
> On Tue, Jul 18, 2023 at 5:50 PM Phil Steitz  wrote:
> >
> > I would say 17 for 3.0.
> >
> > Phil

Are there aspects of Pool that require moving away from JDK 8? Such a
move would restrict downstream consumers of the library.

Alex

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

Re: Move math algorithms from all projects to math libraries

[Alex Herbert]

On Tue, 18 Jul 2023 at 09:43, Gilles Sadowski  wrote:
>
> Hello.
>
> Le mar. 18 juil. 2023 à 02:48, Dimitrios Efthymiou
>  a écrit :
> >
> > Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and
> > i will put it in *.ext package (TBD) along with some tests. Do i have to
> > look at Dfd.java or something, because these dfd classes in math legacy
> > core have lots of hard-coded decimals in there.
>
> Yes, we need to sort out what to with with the "Dfp" classes: I don't
> know how useful they will be once the DD implementation is available.
> We'll perhaps need benchmarks to assess speed vs precision among
> all extended precision implementations:
>  * DD in [Numbers],
>  * Dfp in [Math]
>  * BigDecimal in the JDK
>
> If "Dfp" is somehow (TBD) useful, it should be moved to a module of
> its own, perhaps in [Numbers].

Note: Dfp is not in the same category as a double-double number as it
is an "unlimited" precision number. It has a configurable decimal
precision and a larger exponent range than a double. It also has
support for various elementary functions (exp, exp1p, log, log1p, sin,
cos, etc). As such it is very valuable to fill a void where BigDecimal
cannot be used since that only supports pow and, from JDK 9+, sqrt. I
expect the speed would be comparable to BigDecimal and so a JMH test
would be useful.

Moving it out of math to a new module in numbers would be a chance to
revisit the code. But it is a large and complex class. I would not
change its implementation without a very thorough set of tests against
other comparable unlimited precision number implementations in other
libraries (Python mpmath; Maxima; Matlab vpa; etc).

Alex

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

Re: Move math algorithms from all projects to math libraries

[Alex Herbert]

On Tue, 18 Jul 2023 at 01:48, Dimitrios Efthymiou
 wrote:
>
> Thanks Gilles. I checked NUMBERS-193 and i have an implementation of DD and
> i will put it in *.ext package (TBD) along with some tests. Do i have to
> look at Dfd.java or something, because these dfd classes in math legacy
> core have lots of hard-coded decimals in there. Do these need to be copied
> to DD or just implement the high/low part, add, multiply and checks for
> overflows?

I am currently working on the implementation for this by porting what
I created for Statistics. If you can wait for this to be completed
then we can discuss the functionality and public API on the mailing
list or Jira ticket.

Alex

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

Re: Are any of these types of projects needed?

[Alex Herbert]

I would suggest you develop code that you will use. As volunteers we
have a main focus for our interests and put work in where we can, or
where it also benefits us back.

Contributions of large functionality are typically from an existing
project that would like to donate mature code to the ASF. This can go
through the process of becoming incorporated into the ASF as a new
project.

Contributions of small functionality are typically from a contributor
that had a specific need, could not find it in Java and created their
own. The Commons project is focused on all aspects of reusable Java
components. As such you can find similar functionality in other
programming languages. A contribution is more likely to be welcomed if
you can show examples of the same functionality in the core libraries
of other programming languages. This is a good acid test of what a
large number of programmers may require. For all of your suggestions
some feedback would be to put the question into a search engine: How
do I do ... in [Java|R|Matlab|Python|JavaScript|C++|etc]. If you find
Java has some missing topics then this could be a focus to start a
discussion on the dev mailing list.

Note that the ASF is not a place to host code that does not have
anyone using it. That is not productive to forming a developer
community.

Regards,

Alex


On Fri, 14 Jul 2023 at 02:21, Dimitrios Efthymiou
 wrote:
>
> The intended audience is the devs on this maillist. It is like market
> research to get the pulse of the community on these ideas to see if there
> is at least one that I could apply for in the incubator.
>
> No, i am not working on all of these. I just presented ideas so that I get
> some feedback. Maybe some people will say: "yes, an open source java-based
> eCommerce platform will be in demand", you know? Same with the other emails
> about math functions. Maybe some people from math or non-math commons
> libraries may point out that they would need some of those functions.
>
> Lastly, are there any math libraries that do symbolic math using functional
> interfaces? For example can I use commons math to give it a function that
> represents x^2, differentiate it and as a result get another function that
> represents 2x? I am talking about symbolic math that Wolfram Mathematica
> does.
>
> Thank you for the time you spent on going through the emails. I did some
> pull requests implementing some things and they kept being rejected. So, (i
> think it was you that suggested it) to ask the community which math
> functions they would like to see implemented
>
> On Fri, 14 Jul 2023, 02:03 Gilles Sadowski,  wrote:
>
> > Dimitrios,
> >
> > As requested several times, could you please add the "component"
> > prefix to the "Subject: " line, to signal to the intended audience?
> >
> > What's the purpose of the list below?
> > Are you developing all of those applications?
> >
> > Regards,
> > Gilles
> >
> > Le ven. 14 juil. 2023 à 02:54, Dimitrios Efthymiou
> >  a écrit :
> > >
> > > Java-based ECommerce platform
> > >
> > > Graph and network theory library
> > >
> > > Operations research or management science or mathematical programming
> > > library
> > >
> > > Calendar library with many useful methods that the java datetime API
> > > doesn't provide off-the-shelf
> > >
> > > Finance library including financial engineering
> > >
> > > User management (not apache shiro) i.e. account management, 2-factor
> > auth,
> > > forgot/reset password, security questions and more
> > >
> > > Web utilities from cookie service to device recognition to email service
> > > and more
> > >
> > > Image manipulation library
> > >
> > > Parallelism library for CPU and GPU parallelism
> > >
> > > Quantum computing library
> > >
> > > AdminTool platform. Imagine grafana, but with a lot of prebuilt and
> > > extensible tools
> > >
> > > Physics library
> > >
> > > Client SDK builder by taking API specs and generating java SDKs,
> > JavaScript
> > > SDKs, python etc.
> > >
> > > Transformer of MySQL data to MongoDB and vice-versa. Same for other kinds
> > > of databases
> > >
> > > Blockchain library
> > >
> > > Query Profiling Plugin: A plugin that tracks and logs all database
> > queries
> > > that are executed by the application. It could highlight inefficient
> > > queries, and also track and display query execution times.
> > >
> > > Health Check Plugin: A plugin to perform various health checks on the
> > > application and its dependencies, such as checking database connectivity,
> > > ensuring required services are running, checking disk space, etc. This
> > > plugin can expose health check endpoints that return the status of your
> > > application and its dependencies. This can be useful for monitoring and
> > > automated deployment scenarios.
> > >
> > > Scheduled Tasks Monitoring Plugin: This plugin could provide a unified
> > view
> > > of all the scheduled tasks in your application and provide information
> > like
> > > when each task last ran, whether it 

Re: [commons-lang] 02/02: Add IntToIntFunction

[Alex Herbert]

Is this not the same as:

java.util.function.IntUnaryOperator

On Mon, 10 Jul 2023 at 12:56,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
> commit 120d3489aad924e310a8071a66139947ace7a685
> Author: Gary Gregory 
> AuthorDate: Mon Jul 10 07:56:18 2023 -0400
>
> Add IntToIntFunction
> ---
>  src/changes/changes.xml|  1 +
>  .../commons/lang3/function/IntToIntFunction.java   | 52 
> ++
>  .../lang3/function/IntToIntFunctionTest.java   | 40 +
>  3 files changed, 93 insertions(+)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index b9930b0d2..a9d493949 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -216,6 +216,7 @@ The  type attribute can be add,update,fix,remove.
>  Add and ExceptionUtils.isChecked() 
> and isUnchecked() #1069
>  Add and use ExceptionUtils.throwUnchecked(throwable).
>  Add LockingVisitors.create(O, ReadWriteLock).
> +Add IntToIntFunction.
>  
>   due-to="Dependabot, XenoAmess, Gary Gregory">Bump actions/cache from 2.1.4 to 
> 3.0.10 #742, #752, #764, #833, #867, #959, #964.
>   due-to="Dependabot, Gary Gregory">Bump actions/checkout from 2 to 3.1.0 #819, 
> #825, #859, #963.
> diff --git 
> a/src/main/java/org/apache/commons/lang3/function/IntToIntFunction.java 
> b/src/main/java/org/apache/commons/lang3/function/IntToIntFunction.java
> new file mode 100644
> index 0..45f309743
> --- /dev/null
> +++ b/src/main/java/org/apache/commons/lang3/function/IntToIntFunction.java
> @@ -0,0 +1,52 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +package org.apache.commons.lang3.function;
> +
> +import java.util.function.Function;
> +
> +/**
> + * Represents a function that accepts an int-valued argument and produces an 
> int-valued result. This is the {@code int}-to-{@code int} primitive 
> specialization
> + * for {@link Function}.
> + *
> + * 
> + * This is a functional interface whose 
> functional method is {@link #applyAsInt(int)}.
> + * 
> + *
> + * @see Function
> + * @since 3.13.0
> + */
> +@FunctionalInterface
> +public interface IntToIntFunction {
> +
> +/**
> + * Returns a function that always returns its input argument.
> + *
> + * @return a function that always returns its input argument
> + */
> +static IntToIntFunction identity() {
> +return i -> i;
> +}
> +
> +/**
> + * Applies this function to the given argument.
> + *
> + * @param value the function argument
> + * @return the function result
> + */
> +int applyAsInt(int value);
> +}
> diff --git 
> a/src/test/java/org/apache/commons/lang3/function/IntToIntFunctionTest.java 
> b/src/test/java/org/apache/commons/lang3/function/IntToIntFunctionTest.java
> new file mode 100644
> index 0..d8d11ae07
> --- /dev/null
> +++ 
> b/src/test/java/org/apache/commons/lang3/function/IntToIntFunctionTest.java
> @@ -0,0 +1,40 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +package org.apache.commons.lang3.function;
> +
> +import static org.junit.jupiter.api.Assertions.assertEquals;
> +
> +import org.apache.commons.lang3.AbstractLangTest;
> +import org.junit.jupiter.api.Test;
> +
> 

Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069

[Alex Herbert]

On Mon, 3 Jul 2023 at 08:29, sebb  wrote:
>
> Is null checked or unchecked?
>
> I think neither, so isUnchecked also needs to check for null.
>
> I wonder whether it might be better to throw NPE in both cases for null.
>
> It may be confusing for users if not checked != unchecked.
> e.g. it is tempting to code:
>
> if (isChecked(t)) {
> } else { // must be unChecked
> }
>
> If we don’t throw NPE, then it needs to be made very clear that
> isChecked and isUnchecked are not opposites, there is a 3rd case.
>
> In any case, there needs to be a unit-test specifically for null.
>
> Sebb

+1

I reiterate what I originally said, this is missing:

@Test
public void testIsUnchecked_null() {
assertFalse(ExceptionUtils.isUnchecked(null));
}

The method implementation details are secondary to the fact that the
code is not clear on how it handles null; the relationship between
isChecked and isUnchecked; and the intended usage.

Note that one possible usage of type determination is to decide if you
can cast it to a certain type. Currently this method does not provide
this functionality as isUnchecked does not ensure that a cast to
RuntimeException is allowed (since it passes for Error). So my use
case is satisfied by instanceof. This leaves me wondering what are the
use cases for isChecked or isUnchecked. I presume you are in an
exception block with a Throwable of unknown type. So why do you care
if the exception is not checked if not for a recast?

Without a use case not satisfied by instanceof then this is code bloat.

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

Re: [commons-lang] branch master updated: [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069

[Alex Herbert]

This change is not null-safe for isUnchecked. This case is missing
from the tests (and currently fails):

@Test
public void testIsUnchecked_null() {
assertFalse(ExceptionUtils.isUnchecked(null));
}

The case fails because it simply negates isChecked. Both methods
should return false when passed a null. Since instanceof handles null
then the isUnchecked method can be updated to:

public static boolean isUnchecked(final Throwable throwable) {
return (throwable instanceof Error) || (throwable instanceof
RuntimeException);
}

This implementation passes all current tests plus the extra one above.

On Sun, 2 Jul 2023 at 20:55,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-lang.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 98ef0a413 [LANG-1647] Add and ExceptionUtils.isChecked() and 
> isUnchecked() #1069
> 98ef0a413 is described below
>
> commit 98ef0a4138ac032923c4fb12a97b388bde354668
> Author: Gary Gregory 
> AuthorDate: Sun Jul 2 15:55:12 2023 -0400
>
> [LANG-1647] Add and ExceptionUtils.isChecked() and isUnchecked() #1069
> ---
>  src/changes/changes.xml|   2 +
>  .../java/org/apache/commons/lang3/Functions.java   |   8 +-
>  .../commons/lang3/concurrent/ConcurrentUtils.java  |  21 +---
>  .../apache/commons/lang3/concurrent/Memoizer.java  |  10 +-
>  .../commons/lang3/exception/ExceptionUtils.java| 119 
> -
>  .../apache/commons/lang3/function/Failable.java|   8 +-
>  6 files changed, 77 insertions(+), 91 deletions(-)
>
> diff --git a/src/changes/changes.xml b/src/changes/changes.xml
> index 98a831c53..d4e0e4210 100644
> --- a/src/changes/changes.xml
> +++ b/src/changes/changes.xml
> @@ -208,6 +208,8 @@ The  type attribute can be add,update,fix,remove.
>  Add Pair.accept(FailableBiConsumer).
>  Add Pair.apply(FailableBiFunction).
>  Add ReflectionDiffBuilder.setExcludeFieldNames(...) 
> and DiffExclude a… #838.
> +Add and ExceptionUtils.isChecked() 
> and isUnchecked() #1069
> +Add and use ExceptionUtils.throwUnchecked(throwable).
>  
>   due-to="Dependabot, XenoAmess, Gary Gregory">Bump actions/cache from 2.1.4 to 
> 3.0.10 #742, #752, #764, #833, #867, #959, #964.
>   due-to="Dependabot, Gary Gregory">Bump actions/checkout from 2 to 3.1.0 #819, 
> #825, #859, #963.
> diff --git a/src/main/java/org/apache/commons/lang3/Functions.java 
> b/src/main/java/org/apache/commons/lang3/Functions.java
> index e5e4e106c..7e0de8ba4 100644
> --- a/src/main/java/org/apache/commons/lang3/Functions.java
> +++ b/src/main/java/org/apache/commons/lang3/Functions.java
> @@ -33,6 +33,7 @@ import java.util.function.Supplier;
>  import java.util.stream.Stream;
>
>  import org.apache.commons.lang3.Streams.FailableStream;
> +import org.apache.commons.lang3.exception.ExceptionUtils;
>  import org.apache.commons.lang3.function.Failable;
>  import org.apache.commons.lang3.function.FailableBooleanSupplier;
>
> @@ -521,12 +522,7 @@ public class Functions {
>   */
>  public static RuntimeException rethrow(final Throwable throwable) {
>  Objects.requireNonNull(throwable, "throwable");
> -if (throwable instanceof RuntimeException) {
> -throw (RuntimeException) throwable;
> -}
> -if (throwable instanceof Error) {
> -throw (Error) throwable;
> -}
> +ExceptionUtils.throwUnchecked(throwable);
>  if (throwable instanceof IOException) {
>  throw new UncheckedIOException((IOException) throwable);
>  }
> diff --git 
> a/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java 
> b/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
> index bafbad67d..42b6343da 100644
> --- a/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
> +++ b/src/main/java/org/apache/commons/lang3/concurrent/ConcurrentUtils.java
> @@ -61,8 +61,7 @@ public class ConcurrentUtils {
>  if (ex == null || ex.getCause() == null) {
>  return null;
>  }
> -
> -throwCause(ex);
> +ExceptionUtils.throwUnchecked(ex.getCause());
>  return new ConcurrentException(ex.getMessage(), ex.getCause());
>  }
>
> @@ -84,7 +83,7 @@ public class ConcurrentUtils {
>  return null;
>  }
>
> -throwCause(ex);
> +ExceptionUtils.throwUnchecked(ex.getCause());
>  return new ConcurrentRuntimeException(ex.getMessage(), 
> ex.getCause());
>  }
>
> @@ -145,22 +144,6 @@ public class ConcurrentUtils {
>  return ex;
>  }
>
> -/**
> - * Tests whether the cause of the specified {@link ExecutionException}
> - * should be thrown and does it if necessary.
> - *
> - * @param ex the exception in question
> - */
> -   

Re: [COLLECTIONS] Thread safe Bloom filter

[Alex Herbert]

I do not think concurrent write usage is a general use case for the
filter. So this seems like a specialisation. If implementing it would
harm performance then I would be against it for the base
implementation.

For specialisation I would prefer the JDK pattern used for
Synchronized collections which have a class to wrap the underlying
implementation, e.g.

BloomFilters:
public static BloomFilter synchronizedBloomFilter(BloomFilter)
public static CountingBloomFilter
synchronizedCountingBloomFilter(CountingBloomFilter)

You can then make any implementation thread safe. If your suggested
solution would be to use a lock wrapping the entire method body then
the effect of a synchronized call wrapping the implementation is the
same. This would satisfy the use case of building a single filter
using multiple threads. Note however that the same can be achieved by
building multiple filters, 1 per thread, and then merging them all.

Note that it is dangerous to think that only some methods require
being synchronized. E.g. if a filter "contains" method does not alter
the internal state then it could be unsynchronized. But if a
concurrent thread changes the state then the result of the method call
can change. Those filters with complex internal state that may
reallocate memory will require synchronization around all methods,
e.g. SparseBloomFilter. Without this there may be concurrent
modification exceptions from internal data structures which are
traversed but may be updated concurrently.

For a SimpleBloomFilter there can be no structural modification after
construction (the internal backing array is final). But concurrent
writes may not be atomic and so data corruption can occur. For the
case of reads (i.e. calls to contains), the result is probabilistic
anyway so some error due to concurrent update while reading may be
acceptable.

What is your use case? It may be simpler to provide a static helper
class to wrap access to the methods you are using that can change the
filter (merge/cardinality). Your pool of threads can then call
'contains' without synchronization overhead and any threads that
update the filter use the helper:

// operations synchronized on the filter that is modified
// applies only to filters with no object reallocation on modification
static class FilterHelper {
boolean merge(BloomFilter bf1, BloomFilter bf2) {
synchronized (bf1) {
return bf1.merge(bf2);
}
}
}

Thus you effectively synchronize writes but do not restrict reads.
Some level of probabilistic error on read would have to be tolerated.

Alex

On Sun, 2 Jul 2023 at 07:40, Claude Warren  wrote:
>
> I have been thinking about what it would take to make SimpleBloomFilter
> thread safe.  I think that the answer is to use a copy on write strategy
> and a lock within all the merge methods.
>
> However, this leaves the problem of the cardinality calculation.  Currently
> it is lazily performed and cached.  I am thinking that there are 2
> solutions.
>
>1. mark cardinality volatile and leave the calculation as it effectively
>does a copy on write.
>2. update the cardinality inside the merge.  This should be doable as we
>can get the number of bits in each long after the merge and simply add them
>up during processing.
>
>
> Does anyone see a problem with this solution?
>
> Claude
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren

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

Re: [VOTE] Release Apache Commons IO 2.12.0 based on RC2

[Alex Herbert]

Built from src zip using:

mvn install site

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /Users/ah403/mvn/mvn
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "aarch64", family: "mac"

I see 51 javadoc errors. Some are for private fields. But there are
many for public Builder and 12 for empty  tag (most probably using
 instead of ).

I see some coverage checks failing:

[WARNING] Rule violated for bundle commons-io: classes covered ratio
is 0.97, but expected minimum is 1.00
[WARNING] Rule violated for bundle commons-io: instructions covered
ratio is 0.88, but expected minimum is 0.90
[WARNING] Rule violated for bundle commons-io: methods covered ratio
is 0.89, but expected minimum is 0.95
[WARNING] Rule violated for bundle commons-io: branches covered ratio
is 0.81, but expected minimum is 0.85
[WARNING] Rule violated for bundle commons-io: lines covered ratio is
0.87, but expected minimum is 0.90
[WARNING] Rule violated for bundle commons-io: complexity covered
ratio is 0.83, but expected minimum is 0.85

These numbers (instructions covered; branche covered) are lower than
those reported on the live site report for 2.11. However the CodeCov
report [1] shows the same coverage since the start of reporting
(unfortunately just back to Apr 24) so this may be only a small
downward trend since the last release.

I believe all concerns with the new Builder for streams API were
addressed since the RC1 (I've been following the commits but did not
do a code deep dive). So these are all minor issues.

+1

Alex

[1] https://app.codecov.io/gh/apache/commons-io?search==30%20days

On Sat, 13 May 2023 at 16:24, Gary Gregory  wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons IO 2.11.0 was released, so I would like to
> release Apache Commons IO 2.12.0.
>
> Apache Commons IO 2.12.0 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/io/2.12.0-RC2 (svn
> revision 61825)
>
> The Git tag commons-io-2.12.0-RC2 commit for this RC is
> 266bcc4d5d0fbd230756539f93acd9fc5ddd2c5c which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-io.git;a=commit;h=266bcc4d5d0fbd230756539f93acd9fc5ddd2c5c
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-io.git
> --branch commons-io-2.12.0-RC2 commons-io-2.12.0-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1635/commons-io/commons-io/2.12.0/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat May 13 11:10:37 EDT 2023
> commons-io-2.12.0-bin.tar.gz=24e41dec5dbdbd56d24c3d2ff294a1fecd4d0a80f1af2821ecf60da3527774aced1dca8d0752cebf444249cc4a207baf0fd6555e463b45879e02d0f03acc2445
> commons-io-2.12.0-bin.zip=03c1b6394a07b7b7ed36c97191891811985df9e89ce7369ac7e69d83e6491cc288755d33936ba45cb57fdac5addadf4b19b183b8f2ae52a0e1ee78157c80ea8d
> commons-io-2.12.0-bom.json=07c0b0c4112f54573606a7346699930850fef1274e848576c4a458edbcdd8b613c2cd6d54ab5f96a82a91875e8bbec41f9d50296dfea8558dd317c0ea0555b12
> commons-io-2.12.0-bom.xml=6fb6f96277ef2703bcb5d589bb6fdd1e7f8157d412ace264eb7a47ef0e245d9afa9ebf2b15b4e04b25fb600b37f6369a203ff90b33b904fd3869e48dc0a62069
> commons-io-2.12.0-javadoc.jar=af7ac2ef5439a3d744625917df048445ca6c867c8bef823d70f67a3c3509373b0f70dd4f37e1dd6b1e9ea9878d3a8596262f085ceb8f5255e5af868a9a19d231
> commons-io-2.12.0-sources.jar=a43e070c8b9f4b9a23bb3a6dd9bb5970d0bc8bc973e7fac707d35ac561738e785fffa92acca91483465539a3083fc36431ec09582fa0f98299848e795ff87ce2
> commons-io-2.12.0-src.tar.gz=0318e1566ed125a1d10a0a4f72895c0e7f0b1ad4f8704caec3a107b1755edaef6cd7502eb367c3b2b95e5ec46990b29c90e06cfe4da1cddd13cb9026bb5dee3a
> commons-io-2.12.0-src.zip=df6476b8a9b44746d71a617733048b1848612ec894564d413d92bc16426fe65a38cfbaa12c02140f76668220d9223f9e7d3c5b9a4c793fe14aff38540e0dd91a
> commons-io-2.12.0-test-sources.jar=594d19d76ab22e184fc962a4a3e4c91ff10e097cb5a8a52345a23b3b6d85e824f4844757d5c54f9d4d52a6e62687082d3685295f535d227b7a9586ea2444690b
> commons-io-2.12.0-tests.jar=86e392706ff98f04d053c4b3bbf1df5bb7a375f5ebcb1673ecdbedab36db627723937c93a6559944c19b516ce3b0f83d50143512dd2b891a1cc22524ee28c401
> commons-io_commons-io-2.12.0.spdx.json=071b3e127e1027587db04af620c406fd32ebb9810bd75936fd33131782b0c89417d83672f8ede5302eada044b4a2572b5dfbc598ca70a71695cad6fdea62d25a
>
> I have tested this with:
>
> mvn -V -Duser.name=$my_apache_id -Prelease -Ptest-deploy -P jacoco -P
> japicmp clean package site deploy
>
> Using:
>
> Apache Maven 3.9.2 (c9616018c7a021c1c39be70fb2843d6f5f9b8a1c)
> Maven home: /usr/local/Cellar/maven/3.9.2/libexec
> Java version: 1.8.0_372, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+372/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: 

Re: [VOTE] Release Apache Commons IO 2.12.0 based on RC1

[Alex Herbert]

Validated signatures and checksums.

Build from source tar.gz file using 'mvn verify site' with:

Apache Maven 3.9.0 (9b58d2bad23a66be161c4664ef21ce219c2c8584)
Maven home: /usr/local/apache-maven-3
Java version: 11.0.18, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-148-generic", arch: "amd64", family: "unix"

I do see the checkstyle and spotbugs report.

Spotbugs has a few mentions of non-serializable fields. This is
another case where we may not wish to support serialization going
forward (e.g. as with CSV). I cannot remember the solution for CSV. I
think it was a formal documentation that serialization will be dropped
in CSV 2.0. Looking at the error these are not new as the report in
the live site for 2.11.0 also has these.

Checked for the @since tag for new items in the japicmp report and
found no missing tags. I note that some of the new classes in package
io.build have no javadoc on inner classes with public constructors and
some static helper protected methods.

New helper classes with a private constructor should be final:

CharsetDecoders
CharsetEncoders
FilesUncheck
FileTimes

Changing public classes to final after a release breaks binary
compatibility. However other utility classes in the lib do not use
final for classes so this is not critical. FYI there are 5 others
which I found using PMD. The rule is
ClassWithOnlyPrivateConstructorsShouldBeFinal [1]. This is not part of
the default rules used in the project which is using the default from
the maven plugin [2]. If you run 'mvn pmd:check' the rules are written
to target/pmd/rulesets. I took these rules, added the extra rule and
then used this as the ruleset for PMD.

The new IOBiFunction has a noop method. This has no equivalent in
java.util.function.BiFunction. As discussed on a recent PR for Lang
(adding a noop to TriFunction) it does not make sense to have a noop
function that returns null as this is an operation. I assume this
BiFunction class was copied across from Lang bringing the noop with
it.

A minor inconsistency: QueueInputStream uses the new
AbstractStreamBuilder API but existing public constructors are not
deprecated. However other classes with equally simple constructors
(MemoryMappedFileInputStream, MessageDigestCalculatingInputStream,
etc) have deprecated their public constructors in favour of the
builder.

Documentation: The new AbstractStreamBuilder API exposes a lot of
public set methods in the builder. Some of these may not be applicable
to all use cases. The API allows an object for IO that is typically
created with either a Reader/Writer or Input/OutputStream, to also be
created with a Path or File. However creation using a Reader does not
support InputStream and vice versa. If a Reader is set then the Origin
will not be valid and a RTE will occur when opening the object which
tries to access the input stream from the Origin. Using the old API of
public constructors it was clear what the supported input arguments
were. All the Deprecated constructors that reference the new builder
would benefit from javadoc on the builder of the valid options that
can be configured.

The new classes UncheckedBufferedReader, UncheckedFilterInputStream,
UncheckedFilterReader, UnsynchronizedBufferedInputStream,
UnsynchronizedFilterInputStream, UncheckedFilterOutputStream do not
use the AbstractStreamBuilder API and have constructors. I think the
API can be applied in these cases, although many of the options would
be ignored (e.g. charset, buffer size, etc). However there may be a
reason that blocks use of the API that I did not notice (as I did not
try to implement it).

NullOutputStream deprecated constructor references deprecated
NULL_OUTPUT_STREAM singleton. Should be INSTANCE. Following on from
this should the NullPrintStream and NullWriter constructors also be
deprecated in favour of the INSTANCE?

New class UncheckedFilterOutputStream has a public constructor but
UncheckedFilterWriter is protected. Both have a static 'on' method for
construction so this is inconsistent. These could use the
AbstractStreamBuilder API although the constructors are very simple.
Use of the new API would allow use of Path/File as output.

New class ThreadUtils has a TODO in the javadoc. The javadoc also
requires  tags. The TODO can be moved to a method comment rather
than being within the javadoc where I do not think it is beneficial to
the end-user.

I do not think these are blockers. Extra docs on the use of the
builders can be added later. But it may be nice to clean up little
inconsistencies in the new public before release.

Alex

[1] 
https://pmd.github.io/pmd/pmd_rules_java_design.html#classwithonlyprivateconstructorsshouldbefinal
[2] https://maven.apache.org/plugins/maven-pmd-plugin/pmd-mojo.html#rulesets

On Tue, 2 May 2023 at 12:44, Gary Gregory  wrote:
>
> Ping PMC (and others welcome).
>
> Gary
>
>
> On Mon, May 1, 2023, 08:47 Gary D. Gregory  

Re: [VOTE] Release Apache Commons Parent 57 based on RC2

[Alex Herbert]

+1

Installed from the tag. Builds Statistics (multi-module) and Lang
using Java 8 and 17.

Note: I do get this error from several plugins (pmd, site, bundle,
remote-resources):

[WARNING] Parameter 'localRepository' is deprecated core expression;
Avoid use of ArtifactRepository type. If you need access to local
repository, switch to '${repositorySystemSession}' expression and get
LRM from it instead.

Building using Maven 3.9.1. This property is not in the Statistics
project or CP. It is in lang for 'src/test/resources/java.policy'
which is for the Java Security Manager. So I assume the plugins are
attempting to perform a deprecated action via the Java Security
Manager.

Alex

On Sun, 23 Apr 2023 at 15:30, Gary Gregory  wrote:
>
> We have fixed a few bugs and added some enhancements since Apache
> Commons Parent 56 was released, so I would like to release Apache
> Commons Parent 57.
>
> Apache Commons Parent 57 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2
> (svn revision 61436)
>
> The Git tag commons-parent-57-RC2 commit for this RC is
> 21a0d410161312537687ab9188f9838af5bbd9e0 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=21a0d410161312537687ab9188f9838af5bbd9e0
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-57-RC2 commons-parent-57-RC2
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1632/org/apache/commons/commons-parent/57/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sun Apr 23 10:21:43 EDT 2023
> commons-parent-57-bom.json=465cc213bfafd2a47275ec9e7ada6ce7122486bce0c3e0191afd4b2dfb081a1bdd54d061bfc74e6911681d6470e87db54a785413099c495b4f69024bef6ad37f
> commons-parent-57-bom.xml=2bba4d662318246b268ad78cc5a1774b348ac98a826e17e5a31cfad6ebb20974842d25fe44ddb8785cbb4564411096ae02671d7ab1a76ae4d119f95a24ddf365
> commons-parent-57-site.xml=c6aea4f2c03920366bee23b08b046dacc09710e92c78ccd83f47cd92f89bc53abc3b8bbc7f44017ee94a2cb022ce763fe3f7d8c9aa42d571350269ba6568ca07
> commons-parent-57-src.tar.gz=fc57f72701b4e8d95a95fb972c8570c88e2976a9ac4270dea72bb961d46196ecdfee3cc9d5f7e18cf23a426412d0acdc15456955cd38707cd7ba3b34f877f2e6
> commons-parent-57-src.zip=cccd197f9bad7bdbe39ef91717533d1007666039144ae1ab29934e074208d360f69e0a28d733f0cb25210fce3a8bd10e7d0c8fdc7f6f373e4148d2a548c856a8
> org.apache.commons_commons-parent-57.spdx.json=6573ce664c4a0f0f940b649e77bd1ae4eb0130bdea29e6e861b50dfeb727bb73f22cdc708131b8accdfc44fc07a304ed51a47bf0d18632d2c4555f7e368f53e0
>
> I have tested this with
>
> mvn -V -Duser.name=$my_apache_id -Ddoclint=none -Prelease
> -Ptest-deploy clean package site deploy
>
> using:
>
> Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
> Maven home: /usr/local/Cellar/maven/3.9.1/libexec
> Java version: 1.8.0_362, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+362/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.3.1", arch: "x86_64", family: "mac"
> Darwin  22.4.0 Darwin Kernel Version 22.4.0: Mon Mar  6 21:00:17
> PST 2023; root:xnu-8796.101.5~3/RELEASE_X86_64 x86_64
>
> Details of changes since 56 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/site/index.html
> (note some *relative* links are broken and the 57 directories are
> not yet created - these will be OK once the site is deployed.)
>
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> Gary Gregory,
> Release Manager (using key DEADBEEF)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1a) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-57-RC2 commons-parent-57-RC2
> cd commons-parent-57-RC2
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC2/source
>
> 2) Check Apache licenses
>
> This step is not required if the 

Re: [ALL] Eventually, soon, Java 11

[Alex Herbert]

Free commercial support for JDK 8 from Oracle ended in 2022.
Non-commercial and extended commercial support ends in 2030. Other
providers have free support for longer than 2023 [1]. I would rather
maintain Java 8 support when JDK 8 still has broad support and usage.

Alex

[1] https://en.wikipedia.org/wiki/Java_version_history

On Sun, 23 Apr 2023 at 14:50, Alex Remily  wrote:
>
> Gary,
>
> A few years ago I migrated commons crypto onto Java 11 in my local
> environment.  I haven't kept the code, but it wasn't a heavy lift and I'm
> happy to do it again for the community version.  Let me know how you'd like
> me to proceed.
>
> Alex
>
> On Sun, Apr 23, 2023 at 9:47 AM Gary Gregory  wrote:
>
> > Hi All,
> >
> > In the year 2023, and with Java 21 in EA (https://jdk.java.net/21/), I
> > think it is time to start migrating our components from Java 8 to Java
> > 11. I imagine this to happen slowly and surely over the course of this
> > whole year.
> >
> > In addition, originally, it should also be time to update our GitHub
> > builds to run on Java 21-EA.
> >
> > Gary
> >
> > -
> > 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: [VOTE][LAZY] Release Apache Commons Parent 57 based on RC1

[Alex Herbert]

Installed from the git tag. I can build projects on JDK 11 and 17. But
not on JDK 8.

The new profile to conditionally configure the maven-compiler-release
plugin for JDK 9+ is incorrect. The parent pom defines the property:


8

Then activates it using:


  jdk9-compiler
  
[9,)
  
  

  

  org.apache.maven.plugins
  maven-compiler-plugin
  
${maven.compiler.release}
  

  

  


However the use of the property  is enough to
set it into the compiler-plugin when building on JDK 8. I see the
following error when building under JDK 8:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile
(default-compile) on project commons-lang3: Fatal error compiling:
invalid flag: --release -> [Help 1]

I note that the config is actually recommended on the maven
documentation for the plugin [1]. However it seems that just setting
this property (given that it is the user override property for the
 tag [2]) enables it on JDK 8. Perhaps this is an error in
the maven-compiler-plugin itself.

In Commons Geometry the configuration uses a unique property on the
POM and then sets maven.compiler.release for JDK 9+:


8


compiler-release-property

[9,)



${jvm.target}



I switched to this setup in CP 57 and the build on JDK 8 worked. So
perhaps we should change to this pattern and provide feedback to the
maven-compiler-plugin developers that their recommended configuration
does not work.

Other notes:

1. I still get a warning from the SPDX plugin (same as previous versions of CP):

[WARNING] Unable to map maven licenses to a declared license.  Using NOASSERTION

I do not know where this comes from. The ASF 2.0 license should be
recognised. This seems to output for all projects including building
CP itself. Looking at the config options for SPDX this should
automatically recognise the ASF license so I do not know if this is a
config problem or a bug in SPDX.


2. I had problems with commons-lang on a new Mac processor:

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /Users/ah403/mvn/mvn
Java version: 17.0.6, vendor: Eclipse Adoptium, runtime:
/Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "aarch64", family: "mac"

Using JDK 11 or 17 I get a failure in a unit test for
ArchUtilsTest.testGetProcessor. The test assumes that the current
architecture is x86. As shown above the architecture is "aarch64". The
problem is with the test which should be more robust to actually
knowing what the architecture is before asserting it is x86. This is
not an issue with the parent.

Note that the "os.arch" property on JDK 8 does not detect the new
apple architecture:

Apache Maven 3.9.1 (2e178502fcdbffc201671fb2537d0cb4b4cc58f8)
Maven home: /Users/ah403/mvn/mvn
Java version: 1.8.0_362, vendor: Temurin, runtime:
/Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "x86_64", family: "mac"

So when building on JDK 8 this test passes as the arch is detected as
"x86". The test in lang should be more robust, perhaps just commenting
out the invalid assertion on line 128 would be enough:

final Processor processor = ArchUtils.getProcessor();
assertTrue(processor.isX86());  // <--  This is not platform safe

Regards,

Alex

[1] 
https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html
[2] 
https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#release

On Sat, 22 Apr 2023 at 15:25, Gary Gregory  wrote:
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons Parent 56 was released, so I would like to
> release Apache Commons Parent 57.
>
> Apache Commons Parent 57 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/57-RC1
> (svn revision 61424)
>
> The Git tag commons-parent-57-RC1 commit for this RC is
> 438328ae7ef71feb9565c650c2d83404c191c031 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=438328ae7ef71feb9565c650c2d83404c191c031
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-57-RC1 commons-parent-57-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1631/org/apache/commons/commons-parent/57/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Sat Apr 22 10:17:35 EDT 2023
> 

Re: [all] Failed Jenkins builds

[Alex Herbert]

On Mon, 20 Mar 2023 at 10:26, Gary Gregory  wrote:
>
> All Commons components are Java 8 (or older), so all could be disabled? I
> only rely on GitHub builds since it validates PRs. There is a way to make
> releases from GH but I've not looked into it yet.

I do not want to waste my time fixing something that is not required.
I'd rather just turn them off for now and they can be fixed if needed
in the future.

I will configure the math derived multi-module components to run under
JDK 11 as snapshot deployment is useful. The SonarCloud analysis
already requires JDK 11 so these builds are fine.

Alex

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

[all] Failed Jenkins builds

[Alex Herbert]

A recent update in Jenkins has updated some part of the Jenkins
tooling that reports on the job to a jar file compiled for Java 11.
This is making all the Java 8 Jenkins jobs fail.

I am not sure of the relevance of many of these Jenkins builds given
the use of GH actions for CI builds. The advantage of Jenkins builds
is to deploy SNAPSHOTS automatically to the snapshot repo. This is
useful for mutli-module projects where you are able to do a build
within one module from the current dev branch and the other
dependencies are pulled from the snapshot repo. It can also be used to
run the SonarCloud code quality analysis.

I suggest disabling the following builds that are failing due to Java
11 incompatibility in the job setup:

- commons-bcel
- commons-build-plugin
- commons-cli
- commons-codec
- commons-configuration
- commons-imaging
- commons-io
- commons-parent
- commons-validator

The configuration can be fixed if snapshot deployment is required in the future.

Alex

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

[numbers][GSoC2023] About “Add support for extended precision floating-point numbers” project

[Alex Herbert]

FYI: I added the [numbers] prefix to the subject line.



> > ・ I read David Bailey's paper on the QD library and understood its
> > algorithms. I also briefly looked over its C++ implementation.

This is where I would start with an API design. E.g. what OO API does
the c++ reference implementation provide?

I do not think we want to replace the functionality in the Sum class.
This is a specialised class for linear combinations. The DD class
would be a more general number to be used as you would use a double or
a BigDecimal. I would imagine the API would consist of methods acting
on the current instance and returning a new instance:

DD add(DD)
DD subtract(DD)
DD multiply(DD)
DD divide(DD)

Overrides could be provided for int/long/double arguments as these
have useful simplifications over adding a full double-double number.

Other methods from the current statistics implementation are:

DD pow(int)
DD inverse()

DD ldexp(int)
(int, DD) frexp()  ???

The later are useful for scaling where the exponent range of a double
is effectively limited to [-1074, 1023] in base 2; without sub-normal
numbers this is -1022.

The frexp method is somewhat problematic as there are two return
values. A new normalised fraction in [0.5, 1) and the base 2 scale of
the normalised number. It could be implemented as:

DD frexp(int[] exp)

Other methods for a number could be e.g.:

DD negate()

> > ・ Implement QD as well as DD. As briefly mentioned in the David Bailey
> > paper, for many applications, the use of DD or QD is sufficient.
> > Therefore, I do not think implementing arbitrary-length floating-point
> > numbers is necessary.

Perfectly fine. Other variants can be added later if required.

> > And my question is, what specific extensions do you think are needed
> > regarding the existing double-double API?

The key point of the current API is that it requires no memory
allocation within the class. As such the class has been written to be
mutable. All methods act on primitives and write results to an output
argument. However this does not fully encapsulate the functionality
and methods may be called with arguments that are not normalised
double-double numbers. As such it is open to incorrect usage. For a
public class this either should not be done, or it should be provided
as an alternative to the friendly OO API for advanced usage.

I wrote the implementation this way to avoid memory allocation of a
new object for every operation. I do not know if it actually impacts
the performance. A first project would be to: copy the entire DD class
into a JMH project; add OO methods that create a new instance for all
operations; and copy/adapt the Kolmogorov-Smirnov p-value computation
from statistics for the non-OO and OO API. For a large p-value
computation the current method takes up to 1 second and would create
approximately 50 million objects for intermediate computations (my
guesstimate). The present implementation creates 3 objects. It would
be a useful test to determine if this object creation and garbage
collection affects the performance.

> > Also, how about my ideas on extending the API to be more
> > user-friendly? Am I on the right way?

Perhaps focus on what API is in the c++ library. I imagine this is
fairly mature and will provide a good example of an API of how to
manipulate a custom number implementation.

> Sure; your questions are certainly part of the issues that need
> clarification.
> However, besides the functionality itself, there is the question of
> how it fits within the (math-related) components' "eco-system".
> By this I mean that the code should be moved to "[Numbers]", but
> where?  In the "core" module (where "Sum" is implemented), or in
> a new module of its own (e.g. on the assumption that it may be
> too specific a utility)?
> For one thing, the "Statistics" component will surely depend on
> that utility; hence, porting the existing code to "[Numbers]" might
> be your first pull request[1] (after ensuring locally that the calling
> code is "Statistics" still works as it used to).
>
> Thus, please create a JIRA report[2] to further elaborate on this.[3]

I think a new numbers module for a DD implementation makes sense. We
already have modules for fractions and complex numbers.

Feel free to add some comments on the initial Jira ticket summarising
this direction. We can then create sub-tickets for tasks that you wish
to tackle (e.g. JMH benchmark the current DD class; describe an
initial API for a DD class).

Alex

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

Re: [math] The build is broken

[Alex Herbert]

Is it consistently broken? One test for the optimisers requires 15 restarts
due to randomness in the optimiser and the difficulty of the optimisation
problem. This runs in a different phase. See the surefire plug-in
configuration in the math parent pom.

We tried to make the test suite more robust but you still get failures.
Gilles did a lot of work on the simplex tests which by their nature are
random in their search process. The rest of the test suite runs with up to
5 retries and sporadically fails. But most of the time what we have will
pass so I did not move more tests to the difficulty to pass group. If you
check the build log you can see if the build failed on one of these
optimisation tests or if it is failing somewhere else.

Alex


On Sat, 4 Mar 2023, 15:21 sebb,  wrote:

> On Sat, 4 Mar 2023 at 15:16, Gary Gregory  wrote:
> >
> > Let me get this straight: You use Gmail but you refuse to sign in to
> > GitHub? Right...
>
> So what?
>
> They are run by different organisations.
> The consequences of a leak are very different, especially if you only
> use GMail for public mails.
>
> Let people choose what 3rd party services they want to use.
>
> > Gary
> >
> > On Sat, Mar 4, 2023, 10:11 Gilles Sadowski  wrote:
> >
> > > Hello Gary.
> > >
> > > Le sam. 4 mars 2023 à 15:52, Gary D. Gregory  a
> > > écrit :
> > > >
> > > > Hi Math,
> > > >
> > > > The build is broken locally for me, and as exemplified on GHA [1]:
> > >
> https://github.com/apache/commons-math/actions/runs/4086106809/jobs/7044975362
> > >
> > > Thanks for the notice but a button says "Sign in to view logs".
> > > No-go.
> > >
> > > >
> > > > Please fix.
> > >
> > > Could you please post the logs in a JIRA report?
> > >
> > > Two builds in a row were successful here:
> > >
> > > $ git pull
> > > Already up to date.
> > > $ mvn
> > > [...]
> > > [INFO] Reactor Summary for Apache Commons Math 4.0-SNAPSHOT:
> > > [INFO]
> > > [INFO] Apache Commons Math  SUCCESS [
> > > 4.842 s]
> > > [INFO] Miscellaneous core classes . SUCCESS [
> > > 15.431 s]
> > > [INFO] Artificial neural networks . SUCCESS [
> > > 9.253 s]
> > > [INFO] Transforms . SUCCESS [
> > > 7.217 s]
> > > [INFO] Exception classes (Legacy) . SUCCESS [
> > > 7.430 s]
> > > [INFO] Miscellaneous core classes (Legacy)  SUCCESS [
> > > 16.820 s]
> > > [INFO] Apache Commons Math (Legacy) ... SUCCESS
> [01:24
> > > min]
> > > [INFO] Apache Commons Math Documentation .. SUCCESS [
> > > 5.144 s]
> > > [INFO] Example applications ... SUCCESS [
> > > 0.212 s]
> > > [INFO] SOFM ... SUCCESS [
> > > 0.274 s]
> > > [INFO] SOFM: Chinese Rings  SUCCESS [
> > > 5.772 s]
> > > [INFO] SOFM: Traveling Salesman Problem ... SUCCESS [
> > > 5.743 s]
> > > [INFO] K-Means  SUCCESS [
> > > 0.487 s]
> > > [INFO] K-Means: Image Clustering .. SUCCESS [
> > > 5.322 s]
> > > [INFO]
> > >
> 
> > > [INFO] BUILD SUCCESS
> > > [INFO]
> > >
> 
> > > [INFO] Total time:  02:48 min
> > > [INFO] Finished at: 2023-03-04T16:05:58+01:00
> > > [INFO]
> > >
> 
> > >
> > > Regards,
> > > Gilles
> > >
> > > >
> > > > Gary
> > > > [1] https://github.com/apache/commons-math/actions
> > > >
> > >
> > > -
> > > 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
>
>

[gsoc][statistics] Request for advice about the Commons Statistics project.

[Alex Herbert]

Hi,

Thanks for your interest in Apache Commons.

The GSoC project for Statistics is part of the ongoing project to
refactor the large Commons Math (CM) component into smaller modular
components (see [1-5]).

I have CC'd the commons developer's list on this e-mail. If you
subscribe you will be able to track all the discussion on GSoC by
searching the subject for the GSoC tag.

The suggested project for Statistics 54 ([6]) is to develop the
various univariate statistics in CM for use in Java 8 streams. You can
see the statistics in the latest javadoc for CM ([7]); the relevant
packages are under 'descriptive'. A start point would be to look at
the storeless statistics such as mean, variance, moments, as well as
the summary statistics classes which group together more than one
statistic. The project would be to develop an API that complements the
SummaryStatistics in Java (see [8]) for double, long and int. In
general a collector for a stream would have to be able to accept both
a single value and be combined with another collector to create an
aggregate, e.g:

Mean.add(double)
Mean.add(Mean)

This is to allow parallel stream support.

Currently the JDK only offers a summary containing min, max, count,
average and sum. To extend this would be development of some
aggregator classes for individual statistics and some type of generic
aggregator class that can be constructed to summarise statistics of
interest, e.g. mean and standard deviation; the statistics could be
user-configurable.

Please take a look at the current code in CM and then ask any
questions, either on the dev mailing list or on the Jira ticket. If
you wish to register for a Jira account to allow you to track the GSoC
issue then see here [9, 10]. You send your preferred username,
alternate username and display name to priv...@commons.apache.org and
we shall create an account for you.

Regards,

Alex

[1] https://commons.apache.org/proper/commons-rng/
[2] https://commons.apache.org/proper/commons-geometry/
[3] https://commons.apache.org/proper/commons-statistics/
[4] https://commons.apache.org/proper/commons-numbers/
[5] https://commons.apache.org/proper/commons-math/
[6] https://issues.apache.org/jira/browse/STATISTICS-54
[7] 
https://commons.apache.org/proper/commons-math/javadocs/api-4.0-beta1/index.html
[8] 
https://docs.oracle.com/javase/8/docs/api/java/util/DoubleSummaryStatistics.html
[9] https://infra.apache.org/jira-guidelines.html
[10] https://issues.apache.org/jira/secure/Dashboard.jspa

On Fri, 24 Feb 2023 at 21:03, Md Tanvir Alfesani
 wrote:
>
> I hope this email finds you well. My name is Md Tanvir Alfesani and I'm a 
> student who is interested in contributing to Apache Foundation's project 
> 'Summary Statistics API for JAVA 8 Streams', for Google Summer of Code 2023.
>
> As I was going through the project idea, I realized that I need to learn more 
> about the project. I'm particularly interested in the functionalities of the 
> Common Statistics Library and how to access them to get a good idea about the 
> aforesaid project. I would appreciate any advice or resources you could 
> provide to help me prepare for the project.
>
> Thank you for taking the time to read my email. I am looking forward to 
> hearing from you and hopefully working together on the project.
>
> Best regards,
> Md Tanvir Alfesani

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

[GSoC 2023][statistics] Summary Statistics API for Java 8 streams

[Alex Herbert]

Hi Mostafa,

Thanks for your interest in Apache Commons.

The GSoC project for Statistics is part of the ongoing project to refactor
the large Commons Math (CM) component into smaller modular components (see
[1-5]).

I have CC'd the commons developer's list on this e-mail. If you subscribe
you will be able to track all the discussion on GSoC by searching the
subject for the GSoC tag.

The suggested project for Statistics 54 ([6]) is to develop the various
univariate statistics in CM for use in Java 8 streams. You can see the
statistics in the latest javadoc for CM ([7]); the relevant packages are
under 'descriptive'. A start point would be to look at the storeless
statistics such as mean, variance, moments, as well as the summary
statistics classes which group together more than one statistic. The
project would be to develop an API that complements the SummaryStatistics
in Java (see [8]) for double, long and int. In general a collector for a
stream would have to be able to accept both a single value and be combined
with another collector to create an aggregate, e.g:

Mean.add(double)
Mean.add(Mean)

This is to allow parallel stream support.

Currently the JDK only offers a summary containing min, max, count, average
and sum. To extend this would be development of some aggregator classes for
individual statistics and some type of generic aggregator class that can be
constructed to summarise statistics of interest, e.g. mean and standard
deviation; the statistics could be user-configurable.

Please take a look at the current code in CM and then ask any questions,
either on the dev mailing list or on the Jira ticket. If you wish to
register for a Jira account to allow you to track the GSoC issue then see
here [9, 10]. You send your preferred username, alternate username and
display name to priv...@commons.apache.org and we shall create an account
for you.

Regards,

Alex

[1] https://commons.apache.org/proper/commons-rng/
[2] https://commons.apache.org/proper/commons-geometry/
[3] https://commons.apache.org/proper/commons-statistics/
[4] https://commons.apache.org/proper/commons-numbers/
[5] https://commons.apache.org/proper/commons-math/
[6] https://issues.apache.org/jira/browse/STATISTICS-54
[7]
https://commons.apache.org/proper/commons-math/javadocs/api-4.0-beta1/index.html
[8]
https://docs.oracle.com/javase/8/docs/api/java/util/DoubleSummaryStatistics.html
[9] https://infra.apache.org/jira-guidelines.html
[10] https://issues.apache.org/jira/secure/Dashboard.jspa

On Wed, 15 Feb 2023 at 15:21, Mostafa Magdi 
wrote:

> Hello Aherbert,
>
> I hope this email finds you well.
>
> My name is Mostafa Magdy, a 4th year senior computer engineer at Cairo
> University faculty of engineering from Egypt.
>
> I worked before as a java developer when i was in the third year in
> college and really i love to code with java.
>
> I have recently seen Apache's project list for 2023 and I found
> Summary Statistics API for Java 8 streams especially very interesting to
> me, hence I decided to apply for it and it would be very helpful if you
> give me some tips about what I can do next.
>
> Thank you in advance.
>
>

[GSoC 2023] Re: Regarding contribution to Commons Numbers Project under GSoC 2023

[Alex Herbert]

Hi Manav,

Thanks for your interest in Apache Commons. At present we do not know
if there will be projects with Apache Commons for the GSoC 2023
season. If we do have any projects then we will post them with
appropriate labels on our issue tracking system so they can be easily
found, see for example [1] for the 2022 project in Numbers. The label
will be the same across all Apache projects so it will allow you to
search more than just Commons projects.

In the meantime there are many open tickets in the issue tracking
system for Apache projects. Please take a look and if you find
anything of interest then contact the appropriate project if you wish
to contribute.

Regards,

Alex

[1] 
https://issues.apache.org/jira/browse/NUMBERS-188?jql=project%20%3D%20NUMBERS%20AND%20labels%20%3D%20gsoc2022

On Thu, 2 Feb 2023 at 12:08, Manav P Gondalia  wrote:
>
> Respected Sir/Ma’am,
>
>
>
> My name is Manav P Gondalia, and I am writing to express my interest in 
> participating in Google Summer of Code and contributing to the project 
> "Common Numbers" under Apache Software Foundation. I have been following 
> Apache Software Foundation’s development for several months now and I am 
> impressed with the impact it has made on the open-source community as well as 
> how much it is loved by the developer community.
>
>
>
> I am currently a pre-final year undergraduate student in Computer Science and 
> Engineering (CSE) pursuing my BTech from the Indian Institute of 
> Technology(IIT), Patna and I have a strong background in C++, Data Structures 
> and Algorithms and Competitive Programming and Mathematics. I had secured an 
> All India Rank of 2535 in the prestigious JEE-Advanced examination in 2020. I 
> have a keen interest for Mathematics and Programmin from a very young age.
>
>
>
> I request you to provide me with some starting guides/resources to begin with 
> contributing to this project.
>
>
>
> I am confident that my skills and passion will allow me to make a meaningful 
> contributions.
>
>
>
> Following are the links to my CP and GitHub profiles:
>
> https://codeforces.com/profile/NineFathoms
> https://www.codechef.com/users/ninefathoms
>
> https://atcoder.jp/users/NineFathoms
>
> https://www.hackerrank.com/gondaliamanav
>
> https://github.com/manavgondalia
>
>
> Thank you for your time and consideration.
>
>
>
> Regards,
>
> __
> Manav P Gondalia
> 3rd Year B.Tech. | Department of Computer Science and Engineering(CSE)
> Indian Institute of Technology(IIT), Patna

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

Re: [commons-math] branch master updated: Add "checkFinite" utility method.

[Alex Herbert]

Note there is an isFinite method.

if (!Double.isFinite(x)) {
...

The isFinite method is a JVM intrinsic method in JDK 20. It was added
in JDK 8 so can be used in [math].

PMD rules would also change this to a forEach loop:

> +for (double x : value) {
> +if (!Double.isFinite(x)) {
> +throw new NotFiniteNumberException(x);
> +}
> +}

This does remove the requirement to declare x = val[i] for reuse of x.

Alex



On Thu, 5 Jan 2023 at 18:54,  wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> erans pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-math.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 093c7ecbf Add "checkFinite" utility method.
> 093c7ecbf is described below
>
> commit 093c7ecbf514d5f196bcb4afd9a67932e9e28f21
> Author: Gilles Sadowski 
> AuthorDate: Thu Jan 5 19:52:17 2023 +0100
>
> Add "checkFinite" utility method.
>
> Functionality was defined in class "MathUtils" (in v3.6.1).
> ---
>  .../commons/math4/legacy/core/MathArrays.java  | 19 ++
>  .../commons/math4/legacy/core/MathArraysTest.java  | 23 
> ++
>  2 files changed, 42 insertions(+)
>
> diff --git 
> a/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java
>  
> b/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java
> index 7b4284b8f..869d10ad5 100644
> --- 
> a/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java
> +++ 
> b/commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/MathArrays.java
> @@ -34,6 +34,7 @@ import 
> org.apache.commons.math4.legacy.exception.NotPositiveException;
>  import 
> org.apache.commons.math4.legacy.exception.NotStrictlyPositiveException;
>  import org.apache.commons.math4.legacy.exception.NullArgumentException;
>  import org.apache.commons.math4.legacy.exception.NumberIsTooLargeException;
> +import org.apache.commons.math4.legacy.exception.NotFiniteNumberException;
>  import org.apache.commons.math4.legacy.exception.util.LocalizedFormats;
>  import org.apache.commons.math4.core.jdkmath.JdkMath;
>
> @@ -573,6 +574,24 @@ public final class MathArrays {
>  }
>  }
>
> +/**
> + * Check that all the elements are real numbers.
> + *
> + * @param val Arguments.
> + * @throws NotFiniteNumberException if any values of the array is not a
> + * finite real number.
> + */
> +public static void checkFinite(final double[] val)
> +throws NotFiniteNumberException {
> +for (int i = 0; i < val.length; i++) {
> +final double x = val[i];
> +if (Double.isInfinite(x) ||
> +Double.isNaN(x)) {
> +throw new NotFiniteNumberException(val[i]);
> +}
> +}
> +}
> +
>  /**
>   * Check that all entries of the input array are = 0.
>   *
> diff --git 
> a/commons-math-legacy-core/src/test/java/org/apache/commons/math4/legacy/core/MathArraysTest.java
>  
> b/commons-math-legacy-core/src/test/java/org/apache/commons/math4/legacy/core/MathArraysTest.java
> index 54677765b..99f09ff02 100644
> --- 
> a/commons-math-legacy-core/src/test/java/org/apache/commons/math4/legacy/core/MathArraysTest.java
> +++ 
> b/commons-math-legacy-core/src/test/java/org/apache/commons/math4/legacy/core/MathArraysTest.java
> @@ -31,6 +31,7 @@ import 
> org.apache.commons.math4.legacy.exception.NotANumberException;
>  import org.apache.commons.math4.legacy.exception.NotPositiveException;
>  import 
> org.apache.commons.math4.legacy.exception.NotStrictlyPositiveException;
>  import org.apache.commons.math4.legacy.exception.NullArgumentException;
> +import org.apache.commons.math4.legacy.exception.NotFiniteNumberException;
>  import org.apache.commons.math4.core.jdkmath.JdkMath;
>
>  /**
> @@ -757,4 +758,26 @@ public class MathArraysTest {
>  public void testUniqueNullArgument() {
>  MathArrays.unique(null);
>  }
> +
> +@Test
> +public void testCheckFinite() {
> +try {
> +MathArrays.checkFinite(new double[] {0, -1, 
> Double.POSITIVE_INFINITY, -2, 3});
> +Assert.fail("an exception should have been thrown");
> +} catch (NotFiniteNumberException e) {
> +// Expected
> +}
> +try {
> +MathArrays.checkFinite(new double[] {1, 
> Double.NEGATIVE_INFINITY, -2, 3});
> +Assert.fail("an exception should have been thrown");
> +} catch (NotFiniteNumberException e) {
> +// Expected
> +}
> +try {
> +MathArrays.checkFinite(new double[] {4, 3, -1, Double.NaN, -2, 
> 1});
> +Assert.fail("an exception should have been thrown");
> +} catch (NotFiniteNumberException e) {
> +// Expected
> + 

Re: [VOTE] Release Apache Commons Parent 56 based on RC1

[Alex Herbert]

Locally installed from the git tag. Builds fine for [rng] and [numbers] using:

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/apache-maven-3.6.3
Java version: 17, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "12.6.1", arch: "x86_64", family: "mac"

+1

Alex

On Fri, 30 Dec 2022 at 16:27, Gary Gregory  wrote:
>
> We have added some enhancements since Apache Commons Parent 55 was
> released, so I would like to release Apache Commons Parent 56.
>
> Apache Commons Parent 56 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1
> (svn revision 59034)
>
> The Git tag commons-parent-56-RC1 commit for this RC is
> 5b9c51eb767743b4e8c6405813b7082926659b98 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=5b9c51eb767743b4e8c6405813b7082926659b98
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-56-RC1 commons-parent-56-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1614/org/apache/commons/commons-parent/56/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Fri Dec 30 11:18:57 EST 2022
> commons-parent-56-bom.json=fb85672b30edcc1dfba3ff5b45d2ab8d98616e428733d30494eb15870b61166ab9915b2fe5c26f0093699e78389ca6808f8a47fb89b8059c9725b131a5b6c2fa
> commons-parent-56-bom.xml=5ffe9849ba1b038bee2cdd0c440eb8872d2c1f7ca0f4262363544f61e57675f1e209c2f5eec06dc978e20b57853faaddaae16e58dbb9b111e3d78ac3c05d6770
> commons-parent-56-site.xml=c6aea4f2c03920366bee23b08b046dacc09710e92c78ccd83f47cd92f89bc53abc3b8bbc7f44017ee94a2cb022ce763fe3f7d8c9aa42d571350269ba6568ca07
> commons-parent-56-src.tar.gz=6c3831c0ca6cf22b610b0362093c4b1467571e2c1fc3c4398b7cdaa636375f289d4b52d62a2ef1a42e485b5241316b7599066c25464ac148db49c7a3339c6692
> commons-parent-56-src.zip=a6af3b55474c568a3b48fb7e75adfa11b105b2e23c8a5f522d717a6434403cb3981c9b5867ae06177c4e15fa9b82a3de5295b5f4e7faa66c90ea1a23056e7896
> org.apache.commons_commons-parent-56.spdx.json=032a54626a692686b574708ef33ac5c9f93a48e0a567abafcf73281142354acc7c129e03d10de2145288d84b6aa329896e1fcaa3ee34ac85d8c4e648d8ef09a1
>
> I have tested this with 'mvn -V -Duser.name=$my_apache_id
> -Ddoclint=none -Prelease -Ptest-deploy clean package site deploy'
> using:
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_352, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.1", arch: "x86_64", family: "mac"
>
> Darwin  22.2.0 Darwin Kernel Version 22.2.0: Fri Nov 11 02:08:47
> PST 2022; root:xnu-8792.61.2~4/RELEASE_X86_64 x86_64
>
> Details of changes since 55 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/site/changes-report.html
>
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/site/index.html
> (note some *relative* links are broken and the 56 directories are
> not yet created - these will be OK once the site is deployed.)
>
> RAT Report:
> 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/site/rat-report.html
>
> KEYS:
>   https://downloads.apache.org/commons/KEYS
>
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now.
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you,
>
> garydgregory,
> Release Manager (using key DEADBEEF)
>
> For following is intended as a helper and refresher for reviewers.
>
> Validating a release candidate
> ==
>
> These guidelines are NOT complete.
>
> Requirements: Git, Java, Maven.
>
> You can validate a release from a release candidate (RC) tag as follows.
>
> 1a) Clone and checkout the RC tag
>
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-56-RC1 commons-parent-56-RC1
> cd commons-parent-56-RC1
>
> 1b) Download and unpack the source archive from:
>
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/56-RC1/source
>
> 2) Check Apache licenses
>
> This step is not required if the site includes a RAT report page which
> you then must check.
>
> mvn apache-rat:check
>
> 3) Check binary compatibility
>
> Older components still use Apache Clirr:
>
> This step is not required if the site includes a Clirr report page
> which you then must check.
>
> mvn clirr:check
>
> 

Re: [Math] Post-release 4.0-beta1, still to do

[Alex Herbert]

On Wed, 21 Dec 2022 at 15:08, Gilles Sadowski  wrote:
>
> Hello.
>
> Le mer. 21 déc. 2022 à 15:08, Alex Herbert  a écrit 
> :
> >
> > On Wed, 21 Dec 2022 at 12:26, Gilles Sadowski  wrote:
> > >
> > > Hello.
> > >
> > > Artefacts are available from Maven Central, distribution files
> > > are available from the ASF server and "rel/..." tag was created
> >
> > Thanks.
> >
> > > The [Math] web is not up-to-date yet.
> > > IIUC, a new module must be added that will aggregate the
> > > Javadoc.  As it is now, the link "Latest API docs", in the left
> > > bar menu, will be dangling (because files are in the respective
> > > "sub-modules").
> > > Should I do it from the "4.0-beta1-release" branch?  Or is OK
> > > to only update "master", and from there, regenerate the site?
> > >
> > > Most links to so-called "long-term" apidocs should be
> > > removed (as nobody would ever need to look at how to use
> > > unsupported code).  [They are empty anyways, and nobody
> > > has ever complained...]
> > > Also, IMO, we don't need to keep "long-term" apidocs for this
> > > release, since it's "beta".
> > >
> > > Shall I send the [ANNOUNCE] message now?
> > > Or should it be delayed until the web site is fixed?
> >
> > Fixing the site should not take long.
>
> Hopefully not, but I won't have time to try and do it until much
> later this evening (or tomorrow).
>
> > Adding the aggregate module
> > should be a simple copy of what is in RNG or Numbers but just updated
> > to add the correct modules to the pom.
> >
> > I would update on master
>
> If you have the opportunity to do it... :-)

I have pushed a version to master with a docs module. It required
putting the junit-vintage dependency in each module that uses it. If
it is in the parent pom then the old junit 4 code is included in the
aggregate javadoc report. A second issue was that the aggregate report
errored on bad javadoc (and broke the build) whereas the respective
modules only output warnings. I do not know why this occurs. It was
fixed by using -Xdoclint:none for the javadoc options to ignore
javadoc errors and allow the aggregate report to build.

To create the site for the 4.0-beta1 release still requires merging
the release branch back into master.

Alex

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

Re: [Math] Post-release 4.0-beta1, still to do

[Alex Herbert]

On Wed, 21 Dec 2022 at 12:26, Gilles Sadowski  wrote:
>
> Hello.
>
> Artefacts are available from Maven Central, distribution files
> are available from the ASF server and "rel/..." tag was created

Thanks.

> The [Math] web is not up-to-date yet.
> IIUC, a new module must be added that will aggregate the
> Javadoc.  As it is now, the link "Latest API docs", in the left
> bar menu, will be dangling (because files are in the respective
> "sub-modules").
> Should I do it from the "4.0-beta1-release" branch?  Or is OK
> to only update "master", and from there, regenerate the site?
>
> Most links to so-called "long-term" apidocs should be
> removed (as nobody would ever need to look at how to use
> unsupported code).  [They are empty anyways, and nobody
> has ever complained...]
> Also, IMO, we don't need to keep "long-term" apidocs for this
> release, since it's "beta".
>
> Shall I send the [ANNOUNCE] message now?
> Or should it be delayed until the web site is fixed?

Fixing the site should not take long. Adding the aggregate module
should be a simple copy of what is in RNG or Numbers but just updated
to add the correct modules to the pom.

I would update on master and publish before sending the ANNOUNCE mail.

Alex

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

Re: svn commit: r1906114 - in /commons/cms-site/trunk: conf/component_releases.properties content/xdoc/index.xml.vm doap/doap_math.rdf

[Alex Herbert]

On Tue, 20 Dec 2022 at 17:10, Gilles Sadowski  wrote:
>
> Hi.
>
> I've updated the occurrences of "math", but the script
>   conf/parse-latest-release.py
> in
>   https://svn.apache.org/repos/asf/commons/cms-site/trunk
> seems to behave weirdly (creating spurious entries?).
>
> Please check that the commit is OK.

The commit looks OK to me.

I checked out the CMS site and ran the scripts to regenerate the
staging site. No changes were detected:

svn co https://svn.apache.org/repos/asf/commons/cms-site/trunk/
cd trunk/
conf/parse-latest-release.py
python3 conf/parse-latest-release.py
svn diff
./commons-site-build.sh
svn diff target/site

Alex

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

Re: [VOTE][RC1] Release Commons Math 4.0-beta1

[Alex Herbert]

On Sun, 18 Dec 2022, 23:06 Gilles Sadowski,  wrote:

> Le dim. 18 déc. 2022 à 23:10, Alex Herbert  a
> écrit :
> >
> > I think the name for the distribution archive is collected in:
> >
> > dist-archive/src/assembly/[bin|src].xml
> >
> > These use ${project.artifactId}-${project.version} by specifying the
> >  tag.
> >
> > So renaming the artifactId for the dist-archive in the pom.xml from
> > commons-math to commons-math4 fixes this.
>
> Thus the "mistake" is in the definition of  in the
> "dist-archive" module: By the current convention, it must be
> "commons-math4".  [Similarly to the  of module
> "commons-math-core" being "commons-math4-core".]
>
> Now I wonder: Is this distinction (with or without the "4") really
> necessary in what the elements are used for?
> E.g. for the file names referred to in the previous message:
> commons-math-4.0-beta1-bin.tar.gz
> vs
> commons-math4-4.0-beta1-bin.tar.gz
> why is the latter better than the former?
> IOW, the "4" is redundant since it is present in the "version"
> string.  So why keep track, in the POM files, of distinct strings
> "commons-math" and "commons-math4" if wherever they are
> used, the "version" string is also used?
>
> Hence, could we adopt a new, less error-prone, convention that
> will be simpler:  is always composed of the string
> "commons", a hyphen, and the name of the component,
> irrespective of version?
>


I don't know the history here but looking at commons Lang the download for
the 2.x line does not have lang2 in the name but for the 3.x line it does
have lang3.

https://commons.apache.org/proper/commons-lang/download_lang.cgi

I thought the artifact id was used in commons to match the package name. So
you can import math3 and math4 artifacts. So it is important for jar
artifacts.

But for the distribution module having the math4 is redundant, but also
harmless to keep it included.

Alex



> Gilles
>
> > Verified using:
> >
> > > mvn assembly:single
> >
> > from within the dist-archive module.
> >
> > Note that if the  tag is removed from the assembly
> > descriptors then the final output archive name is
> > ${project.build.finalName} [1]. This results in the same output using
> > ${project.artifactId}-${project.version} to create:
> >
> > commons-math4-4.0-SNAPSHOT-src.tar.gz
> > commons-math4-4.0-SNAPSHOT-src.zip
> > commons-math4-4.0-SNAPSHOT-bin.tar.gz
> > commons-math4-4.0-SNAPSHOT-bin.zip
> >
> > Alex
> >
> > [1] https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
> >
> > On Sun, 18 Dec 2022 at 19:55, Gilles Sadowski 
> wrote:
> > >
> > > Hi.
> > >
> > > > [...]
> > > >
> > > > Distribution files and release notes:
> > > >   https://dist.apache.org/repos/dist/dev/commons/math/
> > > >
> > > >   To verify the integrity of the distribution files, you can
> > > >
> > > >   1. download them with the command
> > > >  $ wget -nH --cut-dirs=8 \
> > > >
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.tar.gz
> \
> > > >
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.zip
> \
> > > >
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.tar.gz
> \
> > > >
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.zip
> > > >
> > >
> > > There is a glitch here: Prefix in those file names should have been
> > >commons-math4
> > > but it is
> > >commons-math
> > >
> > > The names can be fixed while copying to the "release" directory of
> > > the "dist" server, without side-effects (I think).
> > > But I don't know what (the "commons-release-plugin" ?) picked
> > > which variable, and where, rather than the element (in the main
> > > "pom.xml"):
> > >   commons-math4-${project.version} commons.release.name>
> > > that seems intended (?) to match the release file names.
> > > [Of course, this issue wouldn't show up in the 1.x release of a
> > > component.]
> > >
> > > Gilles
> > >
> > > > [...]
> > >
> > > -
> > > 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: [VOTE][RC1] Release Commons Math 4.0-beta1

[Alex Herbert]

I think the name for the distribution archive is collected in:

dist-archive/src/assembly/[bin|src].xml

These use ${project.artifactId}-${project.version} by specifying the
 tag.

So renaming the artifactId for the dist-archive in the pom.xml from
commons-math to commons-math4 fixes this. Verified using:

> mvn assembly:single

from within the dist-archive module.

Note that if the  tag is removed from the assembly
descriptors then the final output archive name is
${project.build.finalName} [1]. This results in the same output using
${project.artifactId}-${project.version} to create:

commons-math4-4.0-SNAPSHOT-src.tar.gz
commons-math4-4.0-SNAPSHOT-src.zip
commons-math4-4.0-SNAPSHOT-bin.tar.gz
commons-math4-4.0-SNAPSHOT-bin.zip

Alex

[1] https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html

On Sun, 18 Dec 2022 at 19:55, Gilles Sadowski  wrote:
>
> Hi.
>
> > [...]
> >
> > Distribution files and release notes:
> >   https://dist.apache.org/repos/dist/dev/commons/math/
> >
> >   To verify the integrity of the distribution files, you can
> >
> >   1. download them with the command
> >  $ wget -nH --cut-dirs=8 \
> > 
> > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.tar.gz
> >  \
> > 
> > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.zip
> >  \
> > 
> > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.tar.gz
> >  \
> > 
> > https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.zip
> >
>
> There is a glitch here: Prefix in those file names should have been
>commons-math4
> but it is
>commons-math
>
> The names can be fixed while copying to the "release" directory of
> the "dist" server, without side-effects (I think).
> But I don't know what (the "commons-release-plugin" ?) picked
> which variable, and where, rather than the element (in the main
> "pom.xml"):
>   
> commons-math4-${project.version}
> that seems intended (?) to match the release file names.
> [Of course, this issue wouldn't show up in the 1.x release of a
> component.]
>
> Gilles
>
> > [...]
>
> -
> 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: [VOTE][RC1] Release Commons Math 4.0-beta1

[Alex Herbert]

Verified the checksums on the source and binary archives.

Verified the binary jar files have the correct module entries in the
MANIFEST.MF.

Built from the git tag using: 'mvn'

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/apache-maven-3.6.3
Java version: 1.8.0_301, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Built from the tar source using: mvn site site:stage

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/apache-maven-3.6.3
Java version: 17, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home
Default locale: en_GB, platform encoding: UTF-8
OS name: "mac os x", version: "12.6.1", arch: "x86_64", family: "mac"

Notes on the site:

The developer guide on the site could do with an update to reflect
github PRs (see the numbers, rng guide etc). Adding a .gitattributes
to the repo would make redundant the developer notes on setting up git
config for line endings.

There is no release history page. However it does duplicate
information in the changes report. So perhaps other sites that have a
release history page should drop it. One to discuss.

The changes report has a big TBD at the top of the page.

The jira report is empty. I recently fixed this for BCEL which had
some very old tickets that did not have a Priority label in the
expected Major, Minor, etc. but used 1, 2, 3, etc. These were legacy
tickets ported from a Bugzilla system. Tracking them down required
locally building the maven-changes-plugin and printing out all the
tickets where the priority was returned as null, causing a NPE.

In the userguide overview there is no mention of the legacy module.
Some sort of statement that captures the intent to provide backward
compatibility for functionality in CM3 in the legacy module and that
new code will be added into new modules would be useful.

The overview section 0.3 has the packages: complex; distribution;
fraction; geometry. These do not exist in the code. However the links
are useful as when followed they point to the new Commons projects
containing the updated code. Perhaps the links for packages removed in
4.0 should be placed below under a section for migrated code.

The latest API docs link is broken as the structure is now modular.
This could be fixed using an aggregate docs module (see numbers, rng)
that builds an aggregate javadoc across the entire set of modules and
uses this in the site link for the javadoc.

No real issues here, just things to tidy up.

+1 Release it

Alex

On Thu, 15 Dec 2022 at 19:10, Gilles Sadowski  wrote:
>
> Hello.
>
> This is a VOTE for releasing Apache Commons Math v4.0-beta1 (from RC1).
> [Thanks for the help to get there!]
>
> Tag name:
>   commons-math-4.0-beta1-RC1
>
>   Command for checking out the project corresponding to this tag:
> $ git clone https://gitbox.apache.org/repos/asf/commons-math.git
> --branch commons-math-4.0-beta1-RC1
>
>   From within the "commons-math" directory created by the above command, you
>   can
>1. check the tag signature with the command
>  $ git tag -v commons-math-4.0-beta1-RC1
>
>2. build the project[1] with the command
>  $ mvn
>
> Tag URL:
>   
> https://gitbox.apache.org/repos/asf?p=commons-math.git;a=commit;h=12ad3420a77611557603d1c7893d588610b2463a
>
> Commit ID the tag points at:
>   12ad3420a77611557603d1c7893d588610b2463a
>
> Site:
>   http://home.apache.org/~erans/commons-math-4.0-beta1-site/
>
> Distribution files and release notes:
>   https://dist.apache.org/repos/dist/dev/commons/math/
>
>   To verify the integrity of the distribution files, you can
>
>   1. download them with the command
>  $ wget -nH --cut-dirs=8 \
> 
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.tar.gz
> \
> 
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/binaries/commons-math-4.0-beta1-bin.zip
> \
> 
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.tar.gz
> \
> 
> https://dist.apache.org/repos/dist/dev/commons/math/4.0-beta1-RC1/source/commons-math-4.0-beta1-src.zip
>
>   2. copy/paste the following excerpt (hash of the distribution files)
>  into a text file (say "sha512.txt"):
> ---CUT---
> #  
> 4a535ba815bd74eab4890d2a99ecfbe719927521b547119d68b03d87e6984f6ca41b9ee66cd4bd37bfc77762f0146227b7bd4a2157500aabfa20ce674fc9f8ab
> commons-math-4.0-beta1-bin.tar.gz
> 3951e7d287032cb2beb966a5259c5ce6c64830fa9570a4659e4e36b74eecfd941ccc8c729dff1b9db1d695301e6a83e2ec35e49c54520c35d93146bfcafcf024
> commons-math-4.0-beta1-bin.zip
> 668f552c444c7328bfb4e73bfba031e00d56212fc38a5d587ac9809ae63547b1caec7edb46a808dd62054601aaca696c3afa9fc4b6e5daa38d8c0db0f31a2ccd
> 

Re: [Math] Release hurdles

[Alex Herbert]

On Thu, 15 Dec 2022 at 11:28, Gilles Sadowski  wrote:
>
> Hi.
>
> Le jeu. 15 déc. 2022 à 12:00, Alex Herbert  a écrit 
> :
> >
> > On Thu, 15 Dec 2022 at 10:52, Gilles Sadowski  wrote:
> > >
> > > Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a 
> > > écrit :
> > > >
> > > > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > > > écrit :
> > > > >
> > > > > Hi.
> > > > >
> > > > > So using the insecure way of passing a password on the command-line,
> > > > > I'm one step further:  Which files to delete from Nexus (and how).
> > > > > Why can't we seem to avoid uploading unnecessary files there?
> > > > > Is the problem with Nexus or the release process or maven?
> > > > > Now that they are there, is there still no other way than to pick them
> > > > > up one at a time, click on "Delete" and then click for confirmation 
> > > > > (that
> > > > > make it largely the most time consuming task of the process)?
> > > > >
> > > > > Please confirm that only the
> > > > >   *.jar
> > > > >   *.pom
> > > > >   *.cyclonedx.xml
> > > > >   *.cyclone.json
> > > > >   *.spdx.json
> > > > > files (and their associated fingerprint and checksum files) should 
> > > > > remain.
> > > >
> > > > Also, there is no JAR file in the
> > > >   commons-math-examples
> > > > folder on Nexus; is it OK to delete it entirely?
> > >
> > > I guess not: It is the parent of modules that may have artefacts.
> > > Ditto for "examples-kmeans" (no JAR, but parent of "examples-kmeans-image"
> > > that has a JAR).
> > >
> > > It is cleaner to have a separate module for each "mini-application" 
> > > (which a
> > > user can then easily run).
> > > However if we have to perform this "manual" deletion of spurious file for 
> > > each
> > > release), it will be much less error-prone to put all the examples in the 
> > > same
> > > module (and use the "subcommand" feature of "picocli").
> >
> > For the other multi-module projects we decided not to upload artifacts
> > to nexus. These jars have no binary compatibility commitment.
> >
> > They are included using an 'examples' profile when you build the site.
>
> There is no such profile in the [Math] POM.
> The line
> ---CUT---
> commons-math-examples
> ---CUT---
> is in the "" section.
>
> Also, I've performed a maven command, noted in earlier messages, that
> did not specify "site" (or does the "deploy" target depend on "site"?).

Our current release howto states that the site goal is required for
the commons-release plugin to stage the site. So I always run it and
didn't know you could omit it. If you do have a staged site then you
manually delete it (it is only the site for the parent pom) and then
stage the correct multi-module site built with the examples. If you
did not have to use the 'site' goal then the release guide can be
updated. I'll make a note to try without the site goal on the next
release.

>
> > But they should not be in the release profile. The latest release of
> > statistics, geometry, rng and numbers did not upload the examples to
> > Nexus. They would be in the source distribution only.
>
> So, for this release, can I just delete all the "*examples*" folders on
> Nexus?
> [Then for the next ones, the upload should be disabled like for the
> other components.]

If Nexus allows you then yes. I don't see a problem with it still
being in the parent pom since that will only affect building the
project. No-one will do that from downloaded artifacts.

Alex

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

Re: [Math] Release hurdles

[Alex Herbert]

On Thu, 15 Dec 2022 at 10:52, Gilles Sadowski  wrote:
>
> Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a écrit :
> >
> > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > écrit :
> > >
> > > Hi.
> > >
> > > So using the insecure way of passing a password on the command-line,
> > > I'm one step further:  Which files to delete from Nexus (and how).
> > > Why can't we seem to avoid uploading unnecessary files there?
> > > Is the problem with Nexus or the release process or maven?
> > > Now that they are there, is there still no other way than to pick them
> > > up one at a time, click on "Delete" and then click for confirmation (that
> > > make it largely the most time consuming task of the process)?
> > >
> > > Please confirm that only the
> > >   *.jar
> > >   *.pom
> > >   *.cyclonedx.xml
> > >   *.cyclone.json
> > >   *.spdx.json
> > > files (and their associated fingerprint and checksum files) should remain.
> >
> > Also, there is no JAR file in the
> >   commons-math-examples
> > folder on Nexus; is it OK to delete it entirely?
>
> I guess not: It is the parent of modules that may have artefacts.
> Ditto for "examples-kmeans" (no JAR, but parent of "examples-kmeans-image"
> that has a JAR).
>
> It is cleaner to have a separate module for each "mini-application" (which a
> user can then easily run).
> However if we have to perform this "manual" deletion of spurious file for each
> release), it will be much less error-prone to put all the examples in the same
> module (and use the "subcommand" feature of "picocli").

For the other multi-module projects we decided not to upload artifacts
to nexus. These jars have no binary compatibility commitment.

They are included using an 'examples' profile when you build the site.
But they should not be in the release profile. The latest release of
statistics, geometry, rng and numbers did not upload the examples to
Nexus. They would be in the source distribution only.

Also note that you may wish to delete some modules from the release.
For example, is the new ga module ready? Given this is a beta release
then this removal may not be necessary as it is not a final cut.

Alex

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

Re: [Math] Release hurdles

[Alex Herbert]

On Thu, 15 Dec 2022 at 10:24, Gilles Sadowski  wrote:
>
> Le jeu. 15 déc. 2022 à 11:01, Gilles Sadowski  a écrit :
> >
> > Le jeu. 15 déc. 2022 à 10:53, Gilles Sadowski  a 
> > écrit :
> > >
> > > Hi.
> > >
> > > So using the insecure way of passing a password on the command-line,
> > > I'm one step further:  Which files to delete from Nexus (and how).
> > > Why can't we seem to avoid uploading unnecessary files there?
> > > Is the problem with Nexus or the release process or maven?
> > > Now that they are there, is there still no other way than to pick them
> > > up one at a time, click on "Delete" and then click for confirmation (that
> > > make it largely the most time consuming task of the process)?

Yes. It is slow for a large multi-module project to remove all these.
I think this is due to the gpg deploy goal in maven signing extras. I
had to delete extra files for the BOM module in numbers and rng which
uploaded extras.

> > >
> > > Please confirm that only the
> > >   *.jar
> > >   *.pom
> > >   *.cyclonedx.xml
> > >   *.cyclone.json
> > >   *.spdx.json
> > > files (and their associated fingerprint and checksum files) should remain.

Yes. See a recent single jar release for an example [1].

> >
> > Also, there is no JAR file in the
> >   commons-math-examples
> > folder on Nexus; is it OK to delete it entirely?
>
> And what about the "*site.xml.*" files in the commons-math-parent" folder?
> To be deleted too?

I do not see the need for these. But they are usually left for any pom
files (see [2, 3]). This is probably due to them being harmless and it
being a pain to remove them. I think I removed them from one rng
release I performed but not the most recent one.

Alex

[1] https://repo1.maven.org/maven2/org/apache/commons/commons-text/1.10.0/
[2] https://repo1.maven.org/maven2/org/apache/commons/commons-parent/55/
[3] https://repo1.maven.org/maven2/org/apache/commons/commons-rng-parent/1.5/


>
> >
> > > Regards,
> > > Gilles
>
> -
> 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: [Math] Release hurdles

[Alex Herbert]

On Wed, 14 Dec 2022 at 13:31, Gilles Sadowski  wrote:
>
> Le mer. 14 déc. 2022 à 09:09, Alex Herbert  a écrit 
> :
> >
> > On Wed, 14 Dec 2022 at 00:49, Gilles Sadowski  wrote:
> > >
> > > Hello.
> > >
> > > Next problem:
> > > $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn -Duser.name=erans
> > > clean deploy -Prelease
> > > [...]
> > > [INFO] Reactor Summary for Apache Commons Math 4.0-beta1:
> > > [INFO]
> > > [INFO] Apache Commons Math  SUCCESS [ 
> > > 11.845 s]
> > > [INFO] Miscellaneous core classes . SUCCESS [ 
> > > 26.164 s]
> > > [INFO] Artificial neural networks . SUCCESS [ 
> > > 20.008 s]
> > > [INFO] Transforms . SUCCESS [ 
> > > 17.360 s]
> > > [INFO] Exception classes (Legacy) . SUCCESS [ 
> > > 18.615 s]
> > > [INFO] Miscellaneous core classes (Legacy)  SUCCESS [ 
> > > 29.017 s]
> > > [INFO] Apache Commons Math (Legacy) ... SUCCESS 
> > > [01:54 min]
> > > [INFO] Example applications ... SUCCESS [  
> > > 4.542 s]
> > > [INFO] SOFM ... SUCCESS [  
> > > 4.651 s]
> > > [INFO] SOFM: Chinese Rings  SUCCESS [ 
> > > 18.144 s]
> > > [INFO] SOFM: Traveling Salesman Problem ... SUCCESS [ 
> > > 15.359 s]
> > > [INFO] K-Means  SUCCESS [  
> > > 4.529 s]
> > > [INFO] K-Means: Image Clustering .. SUCCESS [ 
> > > 16.085 s]
> > > [INFO] Apache Commons Math (full distribution)  FAILURE [  
> > > 1.303 s]
> > > [INFO] 
> > > 
> > > [INFO] BUILD FAILURE
> > > [INFO] 
> > > 
> > > [INFO] Total time:  05:02 min
> > > [INFO] Finished at: 2022-12-13T18:47:14+01:00
> > > [INFO] 
> > > 
> > > [ERROR] Failed to execute goal
> > > org.apache.commons:commons-release-plugin:1.8.0:clean-staging
> > > (clean-staging) on project commons-math: Failed to commit files: null
> > > [null]
> > > [...]
> > >
> > > I could see on the console that files are being uploaded to Nexus.
> > > But no trace there.[1]
> >
> > This seems to be where the plugin tries to remove any old staged files
> > from the dev area. I've just checked and this directory does exist:
> >
> > svn co https://dist.apache.org/repos/dist/dev/commons/math
> >
> > If it is missing I think you get a different error. It was missing for
> > statistics.
> >
> > When I run the release goal I add this 
> > [-Duser.password= >
> > I found that my system does not cache my svn credentials. From the
> > statistics release guide:
> >
> > "The apache ID password is required to clean and deploy the binary 
> > distribution
> > files to svn if the svn client is not configured to locally cache the user
> > password."
>
> This is where I'm a lost.  Why is "svn" involved here, where I thought
> that "deploy" was meant to upload the artefacts to "nexus"?
> If the "nexus" step did not work out (no email notification, thus it didn't,
> despite I was seeing upload progress on the console), it should say so
> before trying something else (related to "svn").
>
> >
> > You could restart from the failed module and run with -X to get more
> > info on the point it fails
> >
> > mvn [release goals] -rf :commons-math 
> > -Duser.password= -X
>
> It is quite unexpected that a part of that command works without
> providing the password (i.e. mvn uses the info in "~/.m2/settings.xml",
> I guess), while another needs it to appear in clear-text on the command
> line.  Is that the case?

That is how I get it to work because my svn client will not cache my
password for my username. So I have to provide it to the commons
release plugin.

As Gary stated, svn is used by the release plugin to copy the dist
archives to (in this case):

svn co https://dist.apache.org/repos/dist/dev/commons/math --depth immediates

Since the directory exists the error must be when the release plugin
is trying to remove all the items inside that directory and it does
not have svn commit permissions to do so.

Alex

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

Re: [Math] Release hurdles

[Alex Herbert]

On Wed, 14 Dec 2022 at 00:49, Gilles Sadowski  wrote:
>
> Hello.
>
> Next problem:
> $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn -Duser.name=erans
> clean deploy -Prelease
> [...]
> [INFO] Reactor Summary for Apache Commons Math 4.0-beta1:
> [INFO]
> [INFO] Apache Commons Math  SUCCESS [ 11.845 
> s]
> [INFO] Miscellaneous core classes . SUCCESS [ 26.164 
> s]
> [INFO] Artificial neural networks . SUCCESS [ 20.008 
> s]
> [INFO] Transforms . SUCCESS [ 17.360 
> s]
> [INFO] Exception classes (Legacy) . SUCCESS [ 18.615 
> s]
> [INFO] Miscellaneous core classes (Legacy)  SUCCESS [ 29.017 
> s]
> [INFO] Apache Commons Math (Legacy) ... SUCCESS [01:54 
> min]
> [INFO] Example applications ... SUCCESS [  4.542 
> s]
> [INFO] SOFM ... SUCCESS [  4.651 
> s]
> [INFO] SOFM: Chinese Rings  SUCCESS [ 18.144 
> s]
> [INFO] SOFM: Traveling Salesman Problem ... SUCCESS [ 15.359 
> s]
> [INFO] K-Means  SUCCESS [  4.529 
> s]
> [INFO] K-Means: Image Clustering .. SUCCESS [ 16.085 
> s]
> [INFO] Apache Commons Math (full distribution)  FAILURE [  1.303 
> s]
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  05:02 min
> [INFO] Finished at: 2022-12-13T18:47:14+01:00
> [INFO] 
> 
> [ERROR] Failed to execute goal
> org.apache.commons:commons-release-plugin:1.8.0:clean-staging
> (clean-staging) on project commons-math: Failed to commit files: null
> [null]
> [...]
>
> I could see on the console that files are being uploaded to Nexus.
> But no trace there.[1]

This seems to be where the plugin tries to remove any old staged files
from the dev area. I've just checked and this directory does exist:

svn co https://dist.apache.org/repos/dist/dev/commons/math

If it is missing I think you get a different error. It was missing for
statistics.

When I run the release goal I add this [-Duser.password= -X

Alex

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

Re: [Math] "mvn commons-build:download-page" fails with Java 11

[Alex Herbert]

On Tue, 13 Dec 2022 at 01:05, Gilles Sadowski  wrote:
>
> Hello.
>
> Running
> $ JAVA_HOME=~/java/jdk/oracle/jdk1.8.0_333 mvn commons-build:download-page
> [...]
> [INFO] BUILD SUCCESS
> [...]
>
> Running
> $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64/ mvn 
> commons-build:download-page
> [...]
> [ERROR] Failed to execute goal
> org.apache.commons:commons-build-plugin:1.12:download-page
> (default-cli) on project commons-math4-core: Failed to execute:
> Executing Ant script: generate-xdocs.build.xml [download-page]: Failed
> to execute.: The following error occurred while executing this line:
> [ERROR] /tmp/plexus-ant-component18328128830526809687.build.xml:215:
> Unable to create javax script engine for javascript
> [...]

I did not find a solution for this when doing the latest releases. I
put this note in the release notes doc:

Note: This command presently requires Java 8.

Alex

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

Re: [Math] "maven site" fails

[Alex Herbert]

Deleting the line:



Works.

I had to do this for the statistics userguide. IIRC the stylesheet was
empty there so it did not matter. However for math the style sheet
contains some elements. It includes some styles that do not exist and
the project.css which is empty apart from an import of a url that does
not exist. So this minimal xsl may not do anything anyway.

I would drop the  wrote:
>
> Hello.
>
> Running
> $ mvn clean package site
> [...]
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.12.1:site (default-site)
> on project commons-math-parent: Error parsing
> '/home/gilles/gilles/devel/java/apache/commons-math/trunk/src/site/xdoc/userguide/analysis.xml':
> line [20] Error parsing the model: processing instruction can not have
> PITarget with reserved xml name (position: IGNORABLE_WHITESPACE seen
> ...ons and\n   limitations under the License.\n
> -->\n\n [...]
>
> Any idea?
>
> Regards,
> Gilles
>
> -
> 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: [Math] Towards 4.0

[Alex Herbert]

I think a beta would be good. Ideally we would get some feedback from
those migrating from CM3 to CM4 and there could be a chance to adjust
the API.

Alex

On Mon, 12 Dec 2022 at 15:22, Gary Gregory  wrote:
>
> I'd be happy with at least one beta release.
>
> Gary
>
> On Mon, Dec 12, 2022, 10:03 Gilles Sadowski  wrote:
>
> > Le lun. 12 déc. 2022 à 15:50, Gary Gregory  a
> > écrit :
> > >
> > > I would say go for it is you are 100% certain that all public and
> > protected
> > > elements are the best they can be as a major release is the only time we
> > > can change them.
> >
> > 100% I'm sure it isn't. ;-)
> > Much work remains in order to reach desirable goals, API-wise, but it
> > should not hold much longer a release that would provide the many
> > improvements done over the years.
> > Anyways, the idea would be to release a "beta" version so that a mistake
> > such as you evoke (a "public" element that should be "private") could be
> > corrected.  [Of course that does not hold for code in "legacy" packages
> > where by definition, work could not be completed to provide an improved
> > API; yet functionality equivalent to CM 3.6.1. should still be available
> > (for
> > people who'd rather not depend on both "3.6.1" and "4.0").]
> >
> > Gilles
> >
> > >
> > > Gary
> > >
> > > On Mon, Dec 12, 2022, 09:39 Gilles Sadowski 
> > wrote:
> > >
> > > > Hello.
> > > >
> > > > With all its dependencies having been released, are there any
> > > > objections (or concerns) wrt the release of the next major version
> > > > of "Commons Math"?
> > > >
> > > > Regards,
> > > > Gilles
> > > >
> > > > -
> > > > 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: [VOTE][LAZY] Release Apache Commons Parent 55 based on RC1

[Alex Herbert]

On Sun, 11 Dec 2022 at 13:23, Gary Gregory  wrote:
>
> > find ~/.m2 -name '*spdx*' -exec rm {} \;
>
> This command also deletes SPDX files. Was that your intent or did you
> only want to delete jar files?

Yes. I wanted to clear everything out. Anything needed would be
downloaded again. It worked and I do not know why. Maybe something I
built locally using an old version of the plugin when it was first
introduced for commons. If it happens again then I may investigate
further.

Alex

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

Re: [VOTE][LAZY] Release Apache Commons Parent 55 based on RC1

[Alex Herbert]

The offending file from my stacktrace was: org.spdx.spdRdfStore.RdfStore

I have this in my maven cache which is a Java 11 class file:

unzip  ~/.m2/repository/org/spdx/spdx-rdf-store/1.1.2/spdx-rdf-store-1.1.2.jar
org/spdx/spdxRdfStore/RdfStore.class

javap -v org/spdx/spdxRdfStore/RdfStore.class  | more
Classfile 
/data/git/commons-rng/commons-rng-simple/org/spdx/spdxRdfStore/RdfStore.class
 Last modified 30 Oct 2022; size 21349 bytes
 SHA-256 checksum
a19c47ed9cca4a9b8f15f23522648deb6f443c8c81951105026d27a3eae31e7c
 Compiled from "RdfStore.java"
public class org.spdx.spdxRdfStore.RdfStore implements
org.spdx.storage.IModelStore,org.spdx.storage.ISerializableModelStore
 minor version: 0
 major version: 55
...

I deleted the org.spdx directory from my cache and it did not fix the issue.

This classfile is the same on my MacBook where the build works under
java 8. So something is triggering the Java 11 RdfStore class to be
loaded on my linux workstation, but not my MacBook.

Not knowing how the spdx cache works, I took a guess and removed all
spdx files from the maven cache:

find ~/.m2 -name '*spdx*' -exec rm {} \;

This mainly removed a lot of the spdx artifacts under org.apache.commons.

Now my builds are OK under java 8. So I do not know the reason why,
but clearing out the spdx artifacts used by maven fixed it.

Alex


On Thu, 8 Dec 2022 at 20:31, Gary Gregory  wrote:
>
> Thanks for the update Alex!
>
> Gary
>
> On Thu, Dec 8, 2022, 15:11 Alex Herbert  wrote:
>
> > I can confirm JDK 8 on my macbook is OK for rng, numbers and lang.
> >
> > Tried 55-SNAPSHOT from git master and also the tagged 55 RC1 (double
> > checking).
> >
> > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
> > Maven home: /usr/local/apache-maven-3.6.3
> > Java version: 1.8.0_301, vendor: Oracle Corporation, runtime:
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre
> > Default locale: en_US, platform encoding: UTF-8
> > OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> >
> > I'll investigate a bit more tomorrow why the JDK 8 build on my other
> > machine is loading a Java 11 class. I may have some problem with the
> > maven cache and the jars that are loaded.
> >
> > Alex
> >
> > On Thu, 8 Dec 2022 at 18:30, Alex Herbert 
> > wrote:
> > >
> > > On Thu, 8 Dec 2022 at 18:18, Gary Gregory 
> > wrote:
> > > >
> > > > Java version: 1.8.0_352, vendor: Private Build
> > > >
> > > > Private build? What's that?
> > >
> > > I did not notice that. It is strange.
> > >
> > > I believe this is the version installed by my package manager on Ubuntu:
> > >
> > > $ java -version
> > > openjdk version "1.8.0_352"
> > > OpenJDK Runtime Environment (build 1.8.0_352-8u352-ga-1~18.04-b08)
> > > OpenJDK 64-Bit Server VM (build 25.352-b08, mixed mode)
> > >
> > > $ lsb_release -a
> > > No LSB modules are available.
> > > Distributor ID: Ubuntu
> > > Description:Ubuntu 18.04.6 LTS
> > > Release:18.04
> > > Codename:   bionic
> > >
> > > I'll try on my MacBook as it has a different java 8.
> > >
> > > Otherwise I will try to download a different java 8 for this linux box.
> > >
> > > Alex
> >
> > -
> > 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: [VOTE][LAZY] Release Apache Commons Parent 55 based on RC1

[Alex Herbert]

I can confirm JDK 8 on my macbook is OK for rng, numbers and lang.

Tried 55-SNAPSHOT from git master and also the tagged 55 RC1 (double checking).

Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /usr/local/apache-maven-3.6.3
Java version: 1.8.0_301, vendor: Oracle Corporation, runtime:
/Library/Java/JavaVirtualMachines/jdk1.8.0_301.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

I'll investigate a bit more tomorrow why the JDK 8 build on my other
machine is loading a Java 11 class. I may have some problem with the
maven cache and the jars that are loaded.

Alex

On Thu, 8 Dec 2022 at 18:30, Alex Herbert  wrote:
>
> On Thu, 8 Dec 2022 at 18:18, Gary Gregory  wrote:
> >
> > Java version: 1.8.0_352, vendor: Private Build
> >
> > Private build? What's that?
>
> I did not notice that. It is strange.
>
> I believe this is the version installed by my package manager on Ubuntu:
>
> $ java -version
> openjdk version "1.8.0_352"
> OpenJDK Runtime Environment (build 1.8.0_352-8u352-ga-1~18.04-b08)
> OpenJDK 64-Bit Server VM (build 25.352-b08, mixed mode)
>
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 18.04.6 LTS
> Release:18.04
> Codename:   bionic
>
> I'll try on my MacBook as it has a different java 8.
>
> Otherwise I will try to download a different java 8 for this linux box.
>
> Alex

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

Re: [VOTE][LAZY] Release Apache Commons Parent 55 based on RC1

[Alex Herbert]

On Thu, 8 Dec 2022 at 18:18, Gary Gregory  wrote:
>
> Java version: 1.8.0_352, vendor: Private Build
>
> Private build? What's that?

I did not notice that. It is strange.

I believe this is the version installed by my package manager on Ubuntu:

$ java -version
openjdk version "1.8.0_352"
OpenJDK Runtime Environment (build 1.8.0_352-8u352-ga-1~18.04-b08)
OpenJDK 64-Bit Server VM (build 25.352-b08, mixed mode)

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 18.04.6 LTS
Release:18.04
Codename:   bionic

I'll try on my MacBook as it has a different java 8.

Otherwise I will try to download a different java 8 for this linux box.

Alex

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

Re: [All] Main site is outdated

[Alex Herbert]

On Thu, 8 Dec 2022 at 13:50, Gilles Sadowski  wrote:
>
> Le jeu. 8 déc. 2022 à 14:13, Alex Herbert  a écrit :
> >
> > On Thu, 8 Dec 2022 at 12:43, Gilles Sadowski  wrote:
> > 
> > > >
> > > > > conf/parse-latest-release.py
> > > >
> > > > currently makes no changes.
> > >
> > > I've just run it, and it "downgrades"
> > >  * RNG (to 1.1)
> > >  * Collections (to 4.1)
> > >
> > > :-?
> >
> > That is strange.
> >
> > The script shebang uses env to pick the python version. My version is:
> >
> > /usr/bin/env python --version
> > Python 2.7.17
> >
> > But it also works with:
> >
> > python3 --version
> > Python 3.6.9
> >
> > Perhaps you do not have the latest doap files. Run 'svn update' from
> > the trunk folder
>
> I had done that, to no avail.
>
> > or checkout clean again.
>
> I did that; it now works.

Good to know.

I checked the index.html for the staging and live site and the
differences are minor:

svn co --depth files
https://svn.apache.org/repos/infra/websites/production/commons/content/
svn co --depth files
https://svn.apache.org/repos/infra/websites/staging/commons/trunk/content
content2
diff content/index.html content2/index.html

< 2021-07-12
---
> 2022-11-01
559,560c559,560
< https://search.maven.org/artifact/org.apache.commons/commons-jexl3/3.2/jar;
rel="nofollow">
< https://img.shields.io/maven-central/v/org.apache.commons/commons-jexl3;
alt="3.2" style="max-wid
th:100%;" />
---
>  href="https://search.maven.org/artifact/org.apache.commons/commons-jexl3/3.2.1/jar;
>  rel="nofollow">
>  src="https://img.shields.io/maven-central/v/org.apache.commons/commons-jexl3; 
> alt="3.2.1" style="max-w
idth:100%;" />
562c562
< 2021-06-07
---
> 2021-06-25

The date is for compress. The version difference for jexl.

There may have been a generation or transfer error somewhere so I've
directly commited the correct index file.

Alex

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

Re: [VOTE][LAZY] Release Apache Commons Parent 55 based on RC1

[Alex Herbert]

Hi Gary,

I tried with the latest git master for numbers, rng and lang. The
updated spdx-maven-plugin is not compatible with java 8. I get the
following error:

[ERROR] Failed to execute goal
org.spdx:spdx-maven-plugin:0.6.3:createSPDX (build-spdx) on project
commons-lang3: Execution build-spd
x of goal org.spdx:spdx-maven-plugin:0.6.3:createSPDX failed: An API
incompatibility was encountered while executing org.spdx:spdx-ma
ven-plugin:0.6.3:createSPDX: java.lang.UnsupportedClassVersionError:
org/spdx/spdxRdfStore/RdfStore has been compiled by a more recen
t version of the Java Runtime (class file version 55.0), this version
of the Java Runtime only recognizes class file versions up to 5
2.0

mvn -v
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/apache-maven-3
Java version: 1.8.0_352, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"

Note: I am not clear exactly what the issue is as it does not happen
in the first jar module of the rng project reactor. The first module
commons-rng-client-api has no dependencies and this builds ok. The
next module commons-rng-core only depends on the client-api. This also
builds. The reactor breaks on the simple module which depends on core
and the client-api. However in numbers the reactor breaks on the first
module commons-numbers-core. This has no runtime dependencies. So some
part of the spdx plugin is being invoked only in some modules that has
a class compiled for Java 11.

Building under JDK 11 was fine for all 3 named projects.

Note that numbers and rng previously had  set to true
as the configuration in CP 54 broke the build. I changed to false and
the multi-module build was fine.

mvn -v
Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/apache-maven-3
Java version: 11.0.17, vendor: Ubuntu, runtime:
/usr/lib/jvm/java-11-openjdk-amd64
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"

So cyclonedx is fixed, but spdx is now not Java 8 compatible.

Alex

On Wed, 7 Dec 2022 at 19:50, Gary Gregory  wrote:
>
> We made some enhancements since Apache Commons Parent 54 was released,
> so I would like to release Apache Commons Parent 55.
>
> This is the parent POM for Apache Commons, it doesn't contain Java
> code, and therefore no JApiCmp API compatibility check or report on
> the site.
>
> Apache Commons Parent 55 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/55-RC1
> (svn revision 58537)
>
> The Git tag commons-parent-55-RC1 commit for this RC is
> 1a8382d227787216d76c1fea62b641158d0a265e which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=1a8382d227787216d76c1fea62b641158d0a265e
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-parent.git
> --branch commons-parent-55-RC1 commons-parent-55-RC1
>
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1611/org/apache/commons/commons-parent/55/
>
> These are the artifacts and their hashes:
>
> #Release SHA-512s
> #Wed Dec 07 14:37:02 EST 2022
> commons-parent-55-bom.json=e96e4d8f44b900ae5b12abbf81c1fa9a5c28e13c0767290e85c0f9e0486c9b3d2f6dac6ba8f4ca3f25c00716b5b6c180f16e0cfa17a51b1fd3c63c57f13deded
> commons-parent-55-bom.xml=11bdf25c251b8b99f5684740e05fa08e8ad01dddeb6544327083696a578bc48785a8d27d03cd7b1ce8f3ace8f4e1b60d32819e4a3b6bc1ed775be5d549e32d33
> commons-parent-55-site.xml=735ffceca46a0574d430b4e1213a2462b9475143c0788913312b8af117eaf3b7c02a075aaf6d9b30d2560822339651cb511b838f6c9f2bced46de1fc1227c5ff
> commons-parent-55-src.tar.gz=1a0307090faca60eaf8a034201521262828c283c8e51dd92a1add0adf48bb55898e0d990daa407648e7b65d6e85a7629ecfb30f4195fbc47d6bf0d14e9664254
> commons-parent-55-src.zip=13c5158f0957853e1df39aa5aa03180b404caa727fef276c969bc811de1e6b3b5465341d544869b338597805b085c21fee63b3d2f6f42dd93dd297fe5e6c8cda
> org.apache.commons_commons-parent-55.spdx.json=14f27b64c60287116e84e2ae9b4d66017260287962c29baef621e9e2b06c06578768453a05bafa90cbe1aa2fe04e248aaedf9b64e8683c658452dedd798e8538
>
> I have tested this with 'mvn clean install' using:
>
> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_352, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac"
> Darwin  22.1.0 Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:54
> PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64
>
> Details of changes since 54 are in the release notes:
> 
> 

Re: [All] Main site is outdated

[Alex Herbert]

On Thu, 8 Dec 2022 at 12:43, Gilles Sadowski  wrote:

> >
> > > conf/parse-latest-release.py
> >
> > currently makes no changes.
>
> I've just run it, and it "downgrades"
>  * RNG (to 1.1)
>  * Collections (to 4.1)
>
> :-?

That is strange.

The script shebang uses env to pick the python version. My version is:

/usr/bin/env python --version
Python 2.7.17

But it also works with:

python3 --version
Python 3.6.9

Perhaps you do not have the latest doap files. Run 'svn update' from
the trunk folder or checkout clean again.

Alex

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

Re: [All] Main site is outdated

[Alex Herbert]

On Thu, 8 Dec 2022 at 10:17, Gilles Sadowski  wrote:
>
> Le jeu. 8 déc. 2022 à 00:32, sebb  a écrit :
> >
> > On Wed, 7 Dec 2022 at 13:20, Alex Herbert  wrote:
> > >
> > > So I can see the file to edit is index.html at this location:
> > >
> > > svn checkout --depth files
> > > https://svn.apache.org/repos/infra/websites/production/commons/content/
> > >
> > > But should this be edited manually, or is it generated/updated via
> > > some automation?
> >
> > That URL is where the website is served; when the site is built from
> > source it will be overwritten.
> >
> > The actual site source is here:
> >
> > https://svn.apache.org/repos/asf/commons/cms-site/trunk/
> >
> > There is some documentation here:
> >
> > https://commons.apache.org/site-publish.html
> >
> > > I ask as the newly released statistics component entry requires more
> > > than just a version number to be updated. The entire link and badge
> > > requires adding.
> >
> > That needs to be done here I think:
> >
> > https://svn.apache.org/repos/asf/commons/cms-site/trunk/content/xdoc/index.xml.vm
>
> Thanks for the reminder.
>
> Main web site has been updated.

I have corrected the doap files to match those in
conf/component_releases.properties so that running this:

> conf/parse-latest-release.py

currently makes no changes.

This mainly added releases that have been manually updated in the
component_releases.properties but not in the doap file. Only the
latest Jexl 3.2.1 release required an update and the release date for
compress 1.22.

The following link is still out-of-date on the main site:

jexl 3.2 -> 3.2.1

When I build locally (see below) there is no svn diff and the link is
correct in the staging area at:

https://svn.apache.org/repos/infra/websites/staging/commons/trunk/content/index.html

Gilles, it looks like (from the commit message) that you ran
commons-site-publish.sh. But somehow the link for Jexl is still
pointing at 3.2 and not 3.2.1. So I do not know what went wrong for
this link.


For the release process:

After the component doap file is updated then the commons site should
be rebuilt. This used to be done by a build-bot but now must be done
manually. This requires running:

> svn co https://svn.apache.org/repos/asf/commons/cms-site/trunk/
==> edit doap/doap_.rdf
> conf/parse-latest-release.py
> svn diff
=> check you have not downgraded other components - fix their doap
file and repeat
> svn commit conf doap -m 'Regenerated component releases'

> commons-site-build.sh
> svn diff target/site
> svn commit target/site -m 'Update the staging site prior to deployment'
=> inspect at 
https://svn.apache.org/repos/infra/websites/staging/commons/trunk/content/index.html

> commons-site-publish.sh
=> inspect target/commons-site-publish.svnmucc
=> Run svnmucc command printed by the script

If this is correct then I can update the release guide we use in the
math-derived component to reflect these steps.

Alex


Alex

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

Re: [All] Main site is outdated

[Alex Herbert]

So I can see the file to edit is index.html at this location:

svn checkout --depth files
https://svn.apache.org/repos/infra/websites/production/commons/content/

But should this be edited manually, or is it generated/updated via
some automation?

I ask as the newly released statistics component entry requires more
than just a version number to be updated. The entire link and badge
requires adding.

Alex

On Tue, 6 Dec 2022 at 23:58, Gilles Sadowski  wrote:
>
> Le mer. 7 déc. 2022 à 00:31, sebb  a écrit :
> >
> > On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski  wrote:
> > >
> > > Hello.
> > >
> > > Homepage
> > >https://commons.apache.org/
> > > contains inconsistent information: Some "(maven-central) badges" display
> > > a version number but the link points to another (usually older) one.  See 
> > > e.g.
> > >  * RNG
> > >  * Geometry
> > >  * Imaging
> > >  * Numbers
> > >  * Compress
> > >  * Pool
> > >  * JCS
> > >  * Math
> > >  * Configuration
> > >  * Text
> > >  * Net
> > >  * ...
> >
> > That's because the version data has not been updated in the relevant
> > status file.
> > RMs should ensure that the file is updated upon release.
> >
> > The badges are generated dynamically from Maven Central metadata, so
> > are whatever the image.shields.io website thinks is the latest.
> >
> > IMO these invisible dynamic queries go against the Privacy FAQ:
> >
> > https://privacy.apache.org/faq/committers.html
> >
> > I think it would be better to have a regular batch job to ensure the
> > status file is up to date and not rely on a 3rd party.
> >
>
> Sorry, I'm fairly lost here; I don't know what "image.shields.io" is.
> Nor when/how we started having those links/badges generated.
>
> I seem to remember that the RM had to update this file:
>   
> https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties
> and the appropriate file in
>   https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/
>
> But then?  Is there a script to run so that the site is updated?
>
>
> Gilles
>
> -
> 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

[rng] LGTM switch to CodeQL GH action

[Alex Herbert]

The [rng] project was signed up to LGTM.com analysis (I presume at
their website). This is now being decommissioned. The underlying
analysis engine is CodeQL and this is migrating to direct support as a
Github action.

Do we want to continue with this for [rng]? There is a PR open by
their bot to enable it [1].

AFAICR the analysis has never noticed any issues. We get far more
feedback from using the sonarcloud analysis that is run by the Jenkins
CI build [2].

I compared their recommended GH workflow to the one configured to
[lang]. It appears mostly the same. I note that both ask for write
permission to the security events. I do not know how this fits with
the security policy to not publicly disclose events until reviewed and
patched, i.e. I do not know if the security tab for the GH page is
restricted, and where event notifications will be sent. So I do not
want to enable this without further investigation, unless someone can
confirm what exactly the CodeQL build analysis will do if it finds
something.

Alex

[1] https://github.com/apache/commons-rng/pull/119
[2] https://sonarcloud.io/project/overview?id=commons-rng

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

[ANNOUNCE] Apache Commons Statistics Version 1.0 Released

[Alex Herbert]

The Apache Commons Team is pleased to announce the availability of
version 1.0 of "Apache Commons Statistics".

Apache Commons Statistics provides tools for statistics.

This is the first release of Apache Commons Statistics.

Contains the following modules:

 commons-statistics-distribution.

Requires Java 8.

For complete information on Apache Commons Statistics, including
instructions on how
to submit bug reports, patches, or suggestions for improvement, see the
Apache Commons Statistics website:
  https://commons.apache.org/proper/commons-statistics/

Distribution packages can be downloaded from
  http://commons.apache.org/proper/commons-statistics/download_statistics.cgi

When downloading, please verify signatures using the KEYS file
available at
  https://www.apache.org/dist/commons/KEYS

The Apache Commons Team

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

Re: [VOTE] Release Apache Commons Statistics 1.0 based on RC1

[Alex Herbert]

On Tue, 6 Dec 2022 at 12:21, Gilles Sadowski  wrote:
> >
> > So the issue with staging the RC site to home.apache.org does not
> > apply when staged to the commons.apache.org.
> >
>
> You could perhaps (FTR) file a JIRA issue to INFRA.

Since I had deleted the site from my home area I uploaded it again.
Now the previous issue with rendering the distribution module pages is
not present (see [1]). So I have nothing to show INFRA.

Alex

[1] 
https://home.apache.org/~aherbert/commons-statistics-1.0-site/commons-statistics-distribution/index.html

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

Re: [All] Main site is outdated

[Alex Herbert]

On Tue, 6 Dec 2022 at 23:31, sebb  wrote:
>
> On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski  wrote:
> >
> > Hello.
> >
> > Homepage
> >https://commons.apache.org/
> > contains inconsistent information: Some "(maven-central) badges" display
> > a version number but the link points to another (usually older) one.  See 
> > e.g.
> >  * RNG
> >  * Geometry
> >  * Imaging
> >  * Numbers
> >  * Compress
> >  * Pool
> >  * JCS
> >  * Math
> >  * Configuration
> >  * Text
> >  * Net
> >  * ...
>
> That's because the version data has not been updated in the relevant
> status file.
> RMs should ensure that the file is updated upon release.

Can you point to the relevant status file please?

After a release I update:

doap file in:
https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap

component_releases.properties in:
https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/

Is there another one I should update?

Alex

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

Re: [rng][lang] Shuffling arrays

[Alex Herbert]

On Tue, 6 Dec 2022 at 17:22, Gary Gregory  wrote:
>
> I agree this should be in rng.
>
> Does rng duplicate all of the lang APIs such that we can deprecate the lang
> methods?

In short, yes.

(cd src/main && git grep -c Random)
- ArrayUtils
- RandomStringUtils
- RandomUtils

The proposed ArraySampler with shuffle methods for all array types
would deprecate ArrayUtils.shuffle. You would have to provide a
UniformRandomProvider in place of a java.util.Random.

RandomStringUtils is not explicitly deprecated. However the class
javadoc states that Commons Text's RandomStringGenerator and,
generically, Commons RNG are more suitable for random generation.

RandomUtils is already deprecated. It mentions RNG in the header but
the functionality is for static thread-safe calls for random numbers.
The RandomUtils class is partly deprecated by changing calls from
RandomUtils.xxx to ThreadLocalRandom.current().xxx. The class uses
ThreadLocalRandom under the hood, but does not act as a pass-through
for all methods. It looks like these could be updated to directly use
ThreadLocalRandom's implementation:

nextLong(long upper)

Note: This method in RandomUtils does not check upper > 0 which is a bug.

However the bounds for some methods are different, some have extra
conditions and some are missing from ThreadLocalRandom.

method : lang : ThreadLocalRandom
nextBytes(int) : present : NA
nextDouble() : [0, MAX_VALUE) : [0, 1)
nextDouble(lower, upper) : [lower, upper) | upper > lower >= 0 : upper > lower
nextFloat() : [0, MAX_VALUE) : [0, 1)
nextFloat(lower, upper) : [lower, upper) | upper > lower >= 0 : NA
nextInt() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE]
nextInt(upper) : NA : [0, upper)
nextInt(lower, upper) : [lower, upper) | upper > lower >= 0 : [lower,
upper) | upper > lower
nextLong() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE]
nextLong(upper) : [0, upper) [no check upper > 0] : [0, upper)
nextLong(lower upper) : [lower, upper) | upper > lower >= 0 : [lower,
upper) | upper > lower

All these methods are in the UniformRandomProvider interface from
[rng], including the nextFloat with ranges but with the exception of
nextBytes(int count). The generators provide nextBytes(byte[]) and you
must supply the array.

In this case it may be helpful to document each method with an
equivalent from ThreadLocalRandom that provides a thread-safe static
call to generate the same output (with the exception that lower bounds
can be negative in ThreadLocalRandom).

Alex

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

Re: [rng][lang] Shuffling arrays

[Alex Herbert]

On Tue, 6 Dec 2022 at 14:38, Bruno Kinoshita  wrote:
>
> Hi Alex,
>
> I also don't have a use case for this right now. What about creating a JIRA
> issue to wait to see if someone has the need for this feature? Maybe users
> will confirm they need it, or provide other suggestions?
>
> -Bruno

I do have a use case for shuffling primitive arrays. But not for
sampling from primitive arrays. So I can create a jira issues for:

1. Add an ArraySampler with shuffle methods (to implement)
2. Add sampling methods to the ArraySampler (TBD)

Alex

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

[rng][lang] Shuffling arrays

[Alex Herbert]

Currently the [rng] sampler package can only shuffle primitive int[] arrays:

o.a.c.rng.sampling.PermutationSampler:

public static void shuffle(UniformRandomProvider rng, int[] list)
public static void shuffle(UniformRandomProvider rng,
   int[] list,
   int start,
   boolean towardHead)

I would like to be able to shuffle other arrays such as double[].
There is actually this functionality in [Lang] o.a.c.lang3.ArrayUtils.
However it uses java.util.Random for the random source, and does not
support a sub-range, e.g.

public static void shuffle(final byte[] array)
public static void shuffle(final byte[] array, final Random random)

I suggest an API that requires UniformRandomProvider and can handle
sub-ranges as:

public static void shuffle(UniformRandomProvider rng, int[] data);
public static void shuffle(UniformRandomProvider rng, int[] data, int
from, int to);
Or (similar to java.util.Arrays.copyOfRange):
public static void shuffleOfRange(UniformRandomProvider rng, int[]
data, int from, int to);

This can be repeated for all 8 primitive types and generic type T.

I suggest putting this in the sampling package but under what class?
Note that all public class names in the sampling package currently end
in Sampler. I would suggest ArraySampler.

Note there is currently a ListSampler which has generic methods to
return List samples from a list, and shuffle lists. So adding
ArraySampler with only shuffling would be missing equivalent sample
methods. Consistency would require adding 8 variations of sample and a
generic one:

public static double[] sample(UniformRandomProvider rng,
double[] array,
int k) {
public static  T[] sample(UniformRandomProvider rng,
T[] array,
int k)

I have no use case for this but can add it for completeness.

Alex

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

Re: [VOTE] Release Apache Commons Statistics 1.0 based on RC1

[Alex Herbert]

FYI

On Mon, 5 Dec 2022 at 00:46, Alex Herbert  wrote:

> I am wondering why the module page on the site I uploaded does not
> render correctly.

I have deployed the 1.0 release to the live site. The module page
renders correctly:

https://commons.apache.org/proper/commons-statistics/commons-statistics-distribution/index.html

So the issue with staging the RC site to home.apache.org does not
apply when staged to the commons.apache.org.

Alex

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

Re: [VOTE] Release Apache Commons BCEL 6.7.0 based on RC1

[Alex Herbert]

Thanks for the notes. I'm fine with exposing the clear() method if it
is intentional.

+1.

Alex

On Mon, 5 Dec 2022 at 18:37, Gary Gregory  wrote:
>
> Hi Alex,
>
> Thank you for the thorough review. Please find my notes below.
>
> On Mon, Dec 5, 2022, 09:31 Alex Herbert  wrote:
>
> > Verified the source signatures and hashes.
> >
> > Built from the tag using: mvn install site
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/apache-maven-3
> > Java version: 1.8.0_352, vendor: Private Build, runtime:
> > /usr/lib/jvm/java-8-openjdk-amd64/jre
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family:
> > "unix"
> >
> > 3 javadocs warnings for this.
> >
>
> Yes, I get 100 Javadoc warnings with 'mvn javadoc:javadoc' which I think
> Javadoc limits to 100 by default.
> I've cleaned up and filled in a lot of Javadocs for this and past releases,
> but this is a large ongoing task that should not block a release IMO since
> the current docs are now better.
>
>
> > Build from the src tar.gz using the default goal and:
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/apache-maven-3
> > Java version: 1.8.0_352, vendor: Private Build, runtime:
> > /usr/lib/jvm/java-8-openjdk-amd64/jre
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family:
> > "unix"
> >
> > 3 javadocs warnings for this too.
> >
> > Build from the src zip using the default goal and:
> >
> > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> > Maven home: /usr/local/apache-maven-3
> > Java version: 17.0.4.1, vendor: Oracle Corporation, runtime:
> > /usr/lib/jvm/jdk-17.0.4.1
> > Default locale: en_GB, platform encoding: UTF-8
> > OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family:
> > "unix"
> >
> > Lots of javadoc warnings for this. JDK 17 is obviously a lot stricter
> > on public members missing comments.
> >
> > Release notes link for the changes report is missing a '/':
> >
>
> I can fix that post-release (
> https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/RELEASE-NOTES.txt
> )
>
>
> >
> > https://commons.apache.org/proper/commons-bcelchanges-report.html
> >
> > Checked the site:
> >
> > Most reports seem OK.
> >
> > Test coverage is improving. Up to 63% since the last release at 50%.
> >
> > JApiCmp: All new classes methods have the correct tag @since 6.7.0.
> >
> > Trivial: The org.apache.bcel.classfile.MethodParameter now implements
> > Node. This is new but cannot be added to the @since tag. It could be
> > added in the class header javadoc.
> >
>
> To do post-release IMO.
>
>
> >
> > Issue: The org.apache.bcel.verifier.VerfierFactory has a method @since
> > 6.6.2 changed from package-private to public. I believe this is a
> > testing method and has only been exposed as public for use in the test
> > case: org.apache.bcel.AbstractTestCase. It is not called within the
> > main source package.
> >
> > For situations like this where the leak into the public has happened
> > for testing it is possible to add a static helper class to the package
> > in the test src that calls the package-private method on the class,
> > e.g.
> >
> > package org.apache.bcel.verifier;
> >
> > public class VerifyHelper {
> > public static void clearVerifierFactory() {
> > VerifierFactory.clear();
> > }
> > }
> >
> > So can we be sure that exposing the clear() method into the public API
> > is acceptable. The javadoc states that the purpose of VerifierFactory
> > is to create singletons. So exposing the clear() method will prevent
> > this purpose as singletons will be cleared and classes recreated.
> > Thoughts on this?
> >
>
> Yes, this was intentional: It turns out that we have a few classes with
> global/static caches and there should be a way to clear a cache for
> long-running apps or apps that load and unload different data.
>
> TY!,
> Gary
>
>
> >
> >
> > Alex
> >
> > On Sun, 4 Dec 2022 at 20:45, Gary Gregory  wrote:
> > >
> > > PMC members, please take a look.
> > >
> > > Gary
> > >
> &

Re: [VOTE] Release Apache Commons Statistics 1.0 based on RC1

[Alex Herbert]

On Mon, 5 Dec 2022 at 16:57, Bruno Kinoshita  wrote:
>
>[x] +1 Release these artifacts
>
> Tested with
>
> Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> Maven home: /opt/apache-maven-3.8.5
> Java version: 17.0.5, vendor: Private Build, runtime:
> /usr/lib/jvm/java-17-openjdk-amd64
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-56-generic", arch: "amd64", family:
> "unix"
>
> From tag, using mvn clean test install site.
>
> Reports look OK, checked NOTICE, LICENSE, and RELEASE-NOTES files, found no
> issues. Signatures also look OK in the dist area. Inspected some archives
> from the dist area and all look OK.
>
> Only odd thing was a CONTRIBUTING.md in the dist area, but I believe that
> will be fixed during the final release (not a big issue).

Yes, and I did wonder why it was there.

This file is present in rng and geometry in the dist area. The release
process has (blindly) copied those projects.

However, it is not there for numbers which shares a similar release
process, or other commons projects like lang and text.

I can remove the files from the relevant projects, and update their
release notes so it does not get put back.

Alex

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

Re: [VOTE] Release Apache Commons BCEL 6.7.0 based on RC1

[Alex Herbert]

Verified the source signatures and hashes.

Built from the tag using: mvn install site

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/apache-maven-3
Java version: 1.8.0_352, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"

3 javadocs warnings for this.

Build from the src tar.gz using the default goal and:

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/apache-maven-3
Java version: 1.8.0_352, vendor: Private Build, runtime:
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"

3 javadocs warnings for this too.

Build from the src zip using the default goal and:

Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Maven home: /usr/local/apache-maven-3
Java version: 17.0.4.1, vendor: Oracle Corporation, runtime:
/usr/lib/jvm/jdk-17.0.4.1
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-200-generic", arch: "amd64", family: "unix"

Lots of javadoc warnings for this. JDK 17 is obviously a lot stricter
on public members missing comments.

Release notes link for the changes report is missing a '/':

https://commons.apache.org/proper/commons-bcelchanges-report.html

Checked the site:

Most reports seem OK.

Test coverage is improving. Up to 63% since the last release at 50%.

JApiCmp: All new classes methods have the correct tag @since 6.7.0.

Trivial: The org.apache.bcel.classfile.MethodParameter now implements
Node. This is new but cannot be added to the @since tag. It could be
added in the class header javadoc.

Issue: The org.apache.bcel.verifier.VerfierFactory has a method @since
6.6.2 changed from package-private to public. I believe this is a
testing method and has only been exposed as public for use in the test
case: org.apache.bcel.AbstractTestCase. It is not called within the
main source package.

For situations like this where the leak into the public has happened
for testing it is possible to add a static helper class to the package
in the test src that calls the package-private method on the class,
e.g.

package org.apache.bcel.verifier;

public class VerifyHelper {
public static void clearVerifierFactory() {
VerifierFactory.clear();
}
}

So can we be sure that exposing the clear() method into the public API
is acceptable. The javadoc states that the purpose of VerifierFactory
is to create singletons. So exposing the clear() method will prevent
this purpose as singletons will be cleared and classes recreated.
Thoughts on this?


Alex

On Sun, 4 Dec 2022 at 20:45, Gary Gregory  wrote:
>
> PMC members, please take a look.
>
> Gary
>
> On Sat, Dec 3, 2022, 07:51 Gary Gregory  wrote:
>
> > Please take the time to review and vote on this RC.
> >
> > Gary
> >
> > On Fri, Dec 2, 2022 at 8:54 AM Gary Gregory 
> > wrote:
> > >
> > > ping ;-)
> > >
> > > On Mon, Nov 28, 2022 at 2:12 PM Bruno Kinoshita 
> > wrote:
> > > >
> > > >[x] +1 Release these artifacts
> > > >
> > > > Building OK from tag with:
> > > >
> > > > Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
> > > > Maven home: /opt/apache-maven-3.8.5
> > > > Java version: 17.0.5, vendor: Private Build, runtime:
> > > > /usr/lib/jvm/java-17-openjdk-amd64
> > > > Default locale: en_US, platform encoding: UTF-8
> > > > OS name: "linux", version: "5.15.0-53-generic", arch: "amd64", family:
> > > > "unix"
> > > >
> > > > Site reports look OK too.
> > > >
> > > > Thanks!
> > > >
> > > > Bruno
> > > >
> > > > On Mon, 28 Nov 2022 at 18:13, Gary Gregory 
> > wrote:
> > > >
> > > > > We have fixed a few bugs and added some enhancements since Apache
> > > > > Commons BCEL 6.6.1 was released, so I would like to release Apache
> > > > > Commons BCEL 6.7.0.
> > > > >
> > > > > Apache Commons BCEL 6.7.0 RC1 is available for review here:
> > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1
> > (svn
> > > > > revision 58280)
> > > > >
> > > > > The Git tag commons-bcel-6.7.0-RC1 commit for this RC is
> > > > > 6fc2135e6b1dca14716287e72bf813cb209bdbbd which you can browse here:
> > > > >
> > > > >
> > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=6fc2135e6b1dca14716287e72bf813cb209bdbbd
> > > > > You may checkout this tag using:
> > > > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git
> > > > > --branch <
> > https://gitbox.apache.org/repos/asf/commons-bcel.git--branch>
> > > > > commons-bcel-6.7.0-RC1 commons-bcel-6.7.0-RC1
> > > > >
> > > > > Maven artifacts are here:
> > > > >
> > > > >
> > https://repository.apache.org/content/repositories/orgapachecommons-1608/org/apache/bcel/bcel/6.7.0/
> > > > >
> > > > > These are the artifacts and their hashes:
> > > > >
> > > > > #Release SHA-512s
> > > > >