Re: Releasing JEXL woes

[Gary Gregory]

You only publish the JEXL site, not the whole Commons site.

Gary

On Mon, Jun 7, 2021, 15:54 Henri Biestro  wrote:

>
> I've been fumbling a bit with the release process, especially the site
> part, I'm pretty sure I've missed a (few) steps somewhere since the site
> still refers to release 3.1 or to 3.2.1-snapshot here and there.
> I'm a bit lost about what the 'site' is :-) Is it the whole commons site
> or only the JEXL site ? The procedure
> described in http://commons.apache.org/site-publish.html is very
> confusing to me now... And the 'being in flux' warning or the yaml
> publishing mail make me even more confused.
>
> A quick look at the site, a little bit of guidance and advice would be
> really welcome. I don't want to announce the release if I've fubar-ed the
> whole thing...
>
> Thanks in advance.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Releasing JEXL woes

[Henri Biestro]

I've been fumbling a bit with the release process, especially the site part, 
I'm pretty sure I've missed a (few) steps somewhere since the site still refers 
to release 3.1 or to 3.2.1-snapshot here and there.
I'm a bit lost about what the 'site' is :-) Is it the whole commons site or 
only the JEXL site ? The procedure 
described in http://commons.apache.org/site-publish.html is very confusing to 
me now... And the 'being in flux' warning or the yaml publishing mail make me 
even more confused.

A quick look at the site, a little bit of guidance and advice would be really 
welcome. I don't want to announce the release if I've fubar-ed the whole 
thing...

Thanks in advance.


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

Re: [IO] release soon

[Gary Gregory]

It's not, I am talking about a different regression.

The OSGi header issue is new.

Gary

On Mon, Jun 7, 2021 at 9:12 AM Jean-Baptiste Onofre  wrote:
>
> By the way, I saw IO-733, but it was not obvious to me it was related to OSGi 
> headers ;)
>
> > Le 7 juin 2021 à 15:04, Gary Gregory  a écrit :
> >
> > Please search Jira before you create duplicate issues.
> >
> > Gary
> >
> > On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre  wrote:
> >
> >> Hi,
> >>
> >> I created https://issues.apache.org/jira/browse/IO-738 <
> >> https://issues.apache.org/jira/browse/IO-738> about OSGi headers.
> >>
> >> I’m working on a PR to fix the headers.
> >>
> >> Would it be possible to include in 2.10.0 ?
> >>
> >> Thanks !
> >>
> >> Regards
> >> JB
> >>
> >>> Le 7 juin 2021 à 14:41, Gary Gregory  a écrit :
> >>>
> >>> We've had the same rehression issue reported a few times since 2.9.0, so
> >> I
> >>> will create a release candidate for 2.10.0 very soon.
> >>>
> >>> FYI it is https://issues.apache.org/jira/browse/IO-733
> >>>
> >>> 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: [IO] release soon

[Jean-Baptiste Onofre]

By the way, I saw IO-733, but it was not obvious to me it was related to OSGi 
headers ;)

> Le 7 juin 2021 à 15:04, Gary Gregory  a écrit :
> 
> Please search Jira before you create duplicate issues.
> 
> Gary
> 
> On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre  wrote:
> 
>> Hi,
>> 
>> I created https://issues.apache.org/jira/browse/IO-738 <
>> https://issues.apache.org/jira/browse/IO-738> about OSGi headers.
>> 
>> I’m working on a PR to fix the headers.
>> 
>> Would it be possible to include in 2.10.0 ?
>> 
>> Thanks !
>> 
>> Regards
>> JB
>> 
>>> Le 7 juin 2021 à 14:41, Gary Gregory  a écrit :
>>> 
>>> We've had the same rehression issue reported a few times since 2.9.0, so
>> I
>>> will create a release candidate for 2.10.0 very soon.
>>> 
>>> FYI it is https://issues.apache.org/jira/browse/IO-733
>>> 
>>> Gary
>> 
>> 


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

Re: [IO] release soon

[Jean-Baptiste Onofre]

Sorry about that, let me remove this Jira.

Regards
JB

> Le 7 juin 2021 à 15:04, Gary Gregory  a écrit :
> 
> Please search Jira before you create duplicate issues.
> 
> Gary
> 
> On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre  wrote:
> 
>> Hi,
>> 
>> I created https://issues.apache.org/jira/browse/IO-738 <
>> https://issues.apache.org/jira/browse/IO-738> about OSGi headers.
>> 
>> I’m working on a PR to fix the headers.
>> 
>> Would it be possible to include in 2.10.0 ?
>> 
>> Thanks !
>> 
>> Regards
>> JB
>> 
>>> Le 7 juin 2021 à 14:41, Gary Gregory  a écrit :
>>> 
>>> We've had the same rehression issue reported a few times since 2.9.0, so
>> I
>>> will create a release candidate for 2.10.0 very soon.
>>> 
>>> FYI it is https://issues.apache.org/jira/browse/IO-733
>>> 
>>> Gary
>> 
>> 


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

Re: [IO] release soon

[Gary Gregory]

Please search Jira before you create duplicate issues.

Gary

On Mon, Jun 7, 2021, 08:44 Jean-Baptiste Onofre  wrote:

> Hi,
>
> I created https://issues.apache.org/jira/browse/IO-738 <
> https://issues.apache.org/jira/browse/IO-738> about OSGi headers.
>
> I’m working on a PR to fix the headers.
>
> Would it be possible to include in 2.10.0 ?
>
> Thanks !
>
> Regards
> JB
>
> > Le 7 juin 2021 à 14:41, Gary Gregory  a écrit :
> >
> > We've had the same rehression issue reported a few times since 2.9.0, so
> I
> > will create a release candidate for 2.10.0 very soon.
> >
> > FYI it is https://issues.apache.org/jira/browse/IO-733
> >
> > Gary
>
>

Re: [Math] Low-discrepancy sequences

[Gilles Sadowski]

Hello Samy.

Le lun. 7 juin 2021 à 11:51, Samy Badjoudj  a écrit :
>
> Hello Gilles,
>
> Is there something we  need to change
> https://github.com/apache/commons-math/pull/190, that one comes after
> the discussion we had.

I probably failed to convey it but the main point of that discussion
was that we need more info about the subject (and use-cases too)
in order to be confident about what the API should be (or not).

The two of us agreeing that the current design can be improved is
a necessary condition but not sufficient to ensure that e.g. your PR
is a long-term improvement:  I'd be wary to add a new package to
the "legacy" module as that would just mean that we know that
more work is needed.

I remind that a goal of the modularization is to create a non-"legacy"
module with each functionality that can stand on its own.
The low-discrepancy classes are obvious candidates.  [They depend
on the legacy exception classes but that can be trivially fixed.  The
hard part it to come up with real use-cases to drive the discussion on
the design.]

It's great if you dig further into this.

But it's also great if you take on more pragmatic issues like those
that could block the release of v4.0.  [Cf. other thread.]

Thanks,
Gilles

> Thanks
>
> On 01.06.21 20:42, Samy Badjoudj wrote:
> >
> > On 01.06.21 20:02, Gilles Sadowski wrote:
> >> Le mar. 1 juin 2021 à 15:25, Samy Badjoudj 
> >> a écrit :
> >>> Thanks Gilles, please find below my remarks
> >>>
> >>>
> >>> On 01.06.21 12:37, Gilles Sadowski wrote:
>  Le lun. 31 mai 2021 à 02:07, Gilles Sadowski 
>  a écrit :
> > Hello.
> >
> > Halton and Sobol sequences have been implemented in the "random"
> > package.  From Wikipedia[1]:
> > ---CUT---
> > Low-discrepancy sequences are also called quasirandom sequences,
> > due to their common use as a replacement of uniformly distributed
> > random numbers. The "quasi" modifier is used to denote more clearly
> > that the values of a low-discrepancy sequence are neither random nor
> > pseudorandom.
> > ---CUT---
> >
> > TL;DR;
> > I propose to create an interface "LowDiscrepancySequence" to properly
> > represents the concept (as opposed to "RandomVectorGenerator").
>  In current "master", interface "RandomVectorGenerator" is not used
>  anymore; I'll remove it.
> 
>  The new (untested) API would be:
>  ---CUT---
>  public interface LowDiscrepancySequence extends Supplier {
>    /**
> * Creates a copy of the LowDiscrepancySequence and then
>  advances
> >>> I would do first the advance then the copy it.
> >> Then you'd end up with two instances having the same state...
> > +1, right,  it reminds me JumpableUniformRandomProvider ;)
>    /* the state of the current instance. The copy is returned.
> *
> * @param jump How far to jump from the current state.
> * @return a copy of this instance.
> */
>    LowDiscrepancySequence jump(int jump);
>  }
> 
>  public class SobolSequence implements LowDiscrepancySequence { /*
>  ... */ }
> 
>  public class HaltonSequence implements LowDiscrepancySequence { /*
>  ... */ }
>  ---CUT---
> 
>  TBD (through reading about the subject): Is this interface common to
>  all such algorithms?  [Is "jump" always defined?  Should its argument
>  rather be a "long"?]
> >>> The maximum size of an array (underlying object) is limited by the max
> >>> integer value. I would suggest keeping an it
> >> Which "underlying" array are you referring to?
> >> How would it impact the size of the "jump"?
> > After looking at the Sobol and Halton sequences plus doing some
> > testing, we can go for a long
>    From an usage POV, I don't see the purpose of the "skipTo" and
>  "getNextIndex" methods.
> >>> Agree
>  By the way, Javadoc for "skipTo" mandates that the arg be positive,
>  but no check is performed; and the code produces a result (expected
>  or not?).
> >>> It will return 0 vector in HaltonSequenceGenerator since
> >> A bug then.
> > Right I did check this condition
> >>> for (int i =0; i  >>>   int index =count; double f =1.0 /base[i]; int j =0; while
> >>> (index >0) {
> >>>   final int digit = scramble(i, j, base[i], index %base[i]);
> >>> v[i] += f * digit; index /=base[i]; // floor( index / base ) f
> >>> /=base[i]; }
> >>> }
> >>>
> >>> For the SobolSequence the Gray Code bit manipulation is working just
> >>> for unsigned number so unexpected value behavior.
> >> A comparison should be done with another implementation.
> >> Maybe the range can be extended to all "int" values (?).
> >>
> >>> Meaning we can do a sanity check in the jump method before.
> >> +1
> >>
>  Another improvement for "SobolGenerator" would be to move the IO
>  to a factory/builder class (that would also cache the data it reads
>  from
>  the "resource" file).

Re: [IO] release soon

[Jean-Baptiste Onofre]

Hi,

I created https://issues.apache.org/jira/browse/IO-738 
 about OSGi headers.

I’m working on a PR to fix the headers.

Would it be possible to include in 2.10.0 ?

Thanks !

Regards
JB

> Le 7 juin 2021 à 14:41, Gary Gregory  a écrit :
> 
> We've had the same rehression issue reported a few times since 2.9.0, so I
> will create a release candidate for 2.10.0 very soon.
> 
> FYI it is https://issues.apache.org/jira/browse/IO-733
> 
> Gary

[IO] release soon

[Gary Gregory]

We've had the same rehression issue reported a few times since 2.9.0, so I
will create a release candidate for 2.10.0 very soon.

FYI it is https://issues.apache.org/jira/browse/IO-733

Gary

Re: [compress] Dealing with RuntimeExceptions While Parsing Archives

[Gilles Sadowski]

Hello.

Le lun. 7 juin 2021 à 06:51, Stefan Bodewig  a écrit :
>
> On 2021-06-06, Gilles Sadowski wrote:
>
> > Le dim. 6 juin 2021 à 07:51, Stefan Bodewig  a écrit :
>
> >> Hi
>
> >> I'm thinking about a specific IOException subclass that is thrown when a
> >> RuntimeException "happens" somewhere in the code that parses data in
> >> Zip/SevenZ/TarFile, see
>
> > I'm afraid I missed part of the story as to what is the original problem.
>
> Sorry, I should have expanded on that.
>
> When we uncompress a stream / expand an archive our users most of the
> time are not responsible for the input. If the data they hand over to
> Compress is invalid, they expect the library to throw an IOException -
> and in many cases this is true.

Does "Compress" make the promise that all exceptions are
(subclasses) of IOException?

> But the reality is most of our parsing code is written for the good case
> where the archive follows the spec. The code relies on numbers to be
> where they should be and not letters, it may fail to check an offset is
> inside of the bounds of an array and so on. So for certain types of
> broken archives the parsers will throw arbitrary RuntimeException
> (NumberFormat, ArrayIndexOutOfBounds, NegativeArraySize and so on).
>
> People do not expect said RuntimeExcepitons, so they don't catch them.

If the answer to the above question was "no", then it's their
responsibility to protect their code against RuntimeException.

> In a situation where an attacker controls the input this can be used to
> make the application reading it crash. So for certain types of
> applications this might be security relevant, it could be a DoS
> vector. Of course one can argue the calling code should better protect
> itself when it reads untrusted input and catch even undeclared
> exceptions,

I cannot see of how one could argue differently.
That runtime exceptions can occur is a Java fact.

> that's why we've never issued CVEs for exceptions where our
> parser code has not been strict enough in the past.
>
> After Compress 1.20 we've had lots of reports of RuntimeExceptions being
> thrown, many of which have been uncovered by fuzz testing tools (not
> only, but also OSS Fuzz).
>
> What I suggest is a stop-gap. It is not an excuse for not properly
> verifying input in our parsing code

I still don't think that "Compress" should double-check a condition
(e.g. array index, null, ...) that will be checked at some lower level
and whose worst consequence would be to throw an exception.

> but rather a way to limit the impact
> of such oversights.

If the answer to the above question is "yes", then AFAICT the
only fix is what you proposed.

Best regards,
Gilles

>
> Stefan

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

Re: [Math] Low-discrepancy sequences

[Samy Badjoudj]

Hello Gilles,

Is there something we  need to change 
https://github.com/apache/commons-math/pull/190, that one comes after 
the discussion we had.


Thanks

On 01.06.21 20:42, Samy Badjoudj wrote:


On 01.06.21 20:02, Gilles Sadowski wrote:
Le mar. 1 juin 2021 à 15:25, Samy Badjoudj  
a écrit :

Thanks Gilles, please find below my remarks


On 01.06.21 12:37, Gilles Sadowski wrote:
Le lun. 31 mai 2021 à 02:07, Gilles Sadowski  
a écrit :

Hello.

Halton and Sobol sequences have been implemented in the "random"
package.  From Wikipedia[1]:
---CUT---
Low-discrepancy sequences are also called quasirandom sequences,
due to their common use as a replacement of uniformly distributed
random numbers. The "quasi" modifier is used to denote more clearly
that the values of a low-discrepancy sequence are neither random nor
pseudorandom.
---CUT---

TL;DR;
I propose to create an interface "LowDiscrepancySequence" to properly
represents the concept (as opposed to "RandomVectorGenerator").

In current "master", interface "RandomVectorGenerator" is not used
anymore; I'll remove it.

The new (untested) API would be:
---CUT---
public interface LowDiscrepancySequence extends Supplier {
  /**
   * Creates a copy of the LowDiscrepancySequence and then 
advances

I would do first the advance then the copy it.

Then you'd end up with two instances having the same state...

+1, right,  it reminds me JumpableUniformRandomProvider ;)

  /* the state of the current instance. The copy is returned.
   *
   * @param jump How far to jump from the current state.
   * @return a copy of this instance.
   */
  LowDiscrepancySequence jump(int jump);
}

public class SobolSequence implements LowDiscrepancySequence { /* 
... */ }


public class HaltonSequence implements LowDiscrepancySequence { /* 
... */ }

---CUT---

TBD (through reading about the subject): Is this interface common to
all such algorithms?  [Is "jump" always defined?  Should its argument
rather be a "long"?]

The maximum size of an array (underlying object) is limited by the max
integer value. I would suggest keeping an it

Which "underlying" array are you referring to?
How would it impact the size of the "jump"?
After looking at the Sobol and Halton sequences plus doing some 
testing, we can go for a long

  From an usage POV, I don't see the purpose of the "skipTo" and
"getNextIndex" methods.

Agree

By the way, Javadoc for "skipTo" mandates that the arg be positive,
but no check is performed; and the code produces a result (expected
or not?).

It will return 0 vector in HaltonSequenceGenerator since

A bug then.

Right I did check this condition

for (int i =0; i   int index =count; double f =1.0 /base[i]; int j =0; while 
(index >0) {
  final int digit = scramble(i, j, base[i], index %base[i]); 
v[i] += f * digit; index /=base[i]; // floor( index / base ) f 
/=base[i]; }

}

For the SobolSequence the Gray Code bit manipulation is working just 
for unsigned number so unexpected value behavior.

A comparison should be done with another implementation.
Maybe the range can be extended to all "int" values (?).


Meaning we can do a sanity check in the jump method before.

+1


Another improvement for "SobolGenerator" would be to move the IO
to a factory/builder class (that would also cache the data it reads 
from

the "resource" file).


That will be a good idea as a separate new improvement



[1] https://en.wikipedia.org/wiki/Low-discrepancy_sequence




/** Interface to Low Discrepancy Sequence generator and supplier *
Supplier of a low discrepancy vectors * Offers navigation through
underlying sequence */ public interface 
LowDiscrepancySequenceextends Supplier {
  /** * Skip to the index in the sequence * @param index of the 
element to
skip to * @return T element at the index */ 
LowDiscrepancySequencejump(int index); > return a copy of it to 
avoid side effect }





/** * private constructor avoid side effects * @return copy of
LowDiscrepancySequence */ private LowDiscrepancySequencecopy() {
  return new SobolSequenceGenerator(this); }


/** * private constructor avoid side effects * @return copy of
LowDiscrepancySequence */ private LowDiscrepancySequencecopy() {
  return new HaltonSequenceGenerator(this); }


Another line of improvement would be to mimic "RandomSource":
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=blob;f=commons-rng-simple/src/main/java/org/apache/commons/rng/simple/RandomSource.java;h=65ca02fdc285fbb7ea8305008dbce21f571191d7;hb=HEAD


Thanks for the link I will have a closer look, never checked the rng 
repo btw :)




-
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.

[RESULT] Release Apache Commons JEXL 3.2

[Henri Biestro]

The following people voted on release JEXL 3.2:
Gary +1
Matt +1
Henrib +1

Gary, Matt, thank you!


On 2021/06/03 18:34:40, Henri Biestro  wrote: 
> 
> We have fixed quite a few bugs and added some significant enhancements since 
> Apache Commons JEXL 3.1 was released, so I would like to release Apache 
> Commons JEXL 3.2.
> 
> Apache Commons JEXL 3.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/jexl/3.2-RC1 (svn revision 
> 48128)
> 
> The Git tag commons-jexl-3.2-RC1 commit for this RC is 
> 3bbdc91d649a085564561a6e93ba9e052d841508 which you can browse here:
> 
> https://gitbox.apache.org/repos/asf?p=commons-jexl.git;a=commit;h=3bbdc91d649a085564561a6e93ba9e052d841508
> You may checkout this tag using:
> git clone https://gitbox.apache.org/repos/asf/commons-jexl.git --branch 
> commons-jexl-3.2-RC1 commons-jexl-3.2-RC1
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1550/org/apache/commons/commons-jexl3/3.2/
> 
> These are the artifacts and their hashes:
> 
> #Release SHA-512s
> #Thu Jun 03 20:13:49 CEST 2021
> commons-jexl-3.2-bin.tar.gz=65593259dcb4e4cb3621766a59206e579d487ca0d56010ac8c514c21df2f0e5c90b05cb36b2c65f8e191b4fb86e91a5124e546d7017927efdcd3cbffeb8e33fa
> commons-jexl-3.2-bin.tar.gz.asc=56ffe095ec050cb3047b9a9463319427d1799351dc16526e4b066cbfbe3d0554ff38fa970e3eac36fe4f96d93f6918dee38a3aeaefbbaafca62dc258c208755f
> commons-jexl-3.2-bin.zip=184dfaa4e9e6aaca1e421a9c220f3c13902a71454a6d35eea8347017b93944a5c2f9455722b49a496e7e616481aa9bfba24ce5a4bb8cfc0b6f8f39680ddec95f
> commons-jexl-3.2-bin.zip.asc=56e5a673a59b422f994281e7e30e74945cee3576b4953077d8c25de9483bd3b24f51f16d5e18b51e74ae649853567b5f0a9900cb61a81aa3b47bd01e22771874
> commons-jexl-3.2-src.tar.gz=cd489cc0f6c117a24be4aedaf1e5a8cf06183085d307c9b855d62f7302709979e4482d6de8da87535381adae8d4671c5cea2af3bb3818050613db87da12aba5f
> commons-jexl-3.2-src.tar.gz.asc=af323b1bac610aea3166cf80433e27aa9c0d7396b56903329ef1d6faa0f808268da729e71c72c69be9695e077c3467abdc2f4d1d8e8a7c9cf53311829ae8e766
> commons-jexl-3.2-src.zip=f10e0a83c6d98f2f12cacfd92acb2b326f718052a73c539c8ca7f39cc60aad4b48331d5ad644dc9c4367ab5d8b1280bf44ccacee6b29fb138f1c12f0f2e285be
> commons-jexl-3.2-src.zip.asc=d99a223f3f5c813316d1ca112a1ee21af84c78475925415d8277b3ecdedd97e3b29a17ba5db5f65f22d945a541f38651f4bb1025892633a4f8cd4988e6d37815
> commons-jexl3-3.2-javadoc.jar=476200ebabb311e3a2197555b19f99ad284cca3501fa170fefd4885c5c310d162340a395dc7ebca842a0483700ca0d689ce42f19557efeab734b4315efa95791
> commons-jexl3-3.2-javadoc.jar.asc=816934c204b16946b9e8482d7fc2784d0f0a845ff4345509265db0f86a6a335fcfcc5c861a78fc431a71122fafc3a5720cb8edabaa35029cc34e4a49faf55135
> commons-jexl3-3.2-sources.jar=4cce369e319d8b83c835124f1c242a4e6502945d28cc8df7bcd36c09cade6aa13d5072b4407ddb01976a13a50df3ec8749e5896df076a501a6fc35eb29a8a8fd
> commons-jexl3-3.2-sources.jar.asc=1eabb310ddcfef0d3caf4d645361549390b22a9be46591ba2c77974e178aa1992e5d88b27cb8145b4437e5bb772577f1a7c6f311cf0aac3129f6ea74574f1a37
> commons-jexl3-3.2-test-sources.jar=944469e6ee58df60807305a4c1386239656efa3fa432a6ff23250e8f878e2135b0658e2e18a1959a1e1a1748764d9e7b6ef264404366d06ae7ab79b4db445be0
> commons-jexl3-3.2-test-sources.jar.asc=725e071ce91dd8c6ce8b8761834bb7578f5c725083bf7614c4f41e72ff2b76be7a03181fa36ec90da534025be236c418294338969d93b64dc87fd7afce4d38e0
> commons-jexl3-3.2-tests.jar=2c986cc9c3943f2d5231e77481819c78f37271e8586d3cc41d639664686de44519b7acb68f34f9dce1781fb70a2330bfff75dc3d3050463a403ee894260d6a98
> commons-jexl3-3.2-tests.jar.asc=e36eb120d1b71689efa6200707f9e58436621e02cd97bff9ad88da323197f0cf9065ebb4c879179ac6f0aeead165eca224e905018eac71f1fe59e80c010e25c3
> commons-jexl3-3.2.jar.asc=97522856c9a68cef53b421d44b350e7998803e459d54edaf20f07be8373968e2009f8734d7d6e89a35757993b227408e6701302a2d2483655fbdc93c2c698756
> commons-jexl3-3.2.pom.asc=0cf4afe3be69f9a7a6e0755ef9a095c903b7979c9585fbe6ecff11808d36c3ccd11b06b3dffd00a0a1c332599613b5afcbef827462b0bbca2140a398cf6baf47
> 
> 
> (no need for .asc hashes!)
> 
> I have tested this with 'mvn clean install site' using: 
> 
> Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 
> 2019-04-04T21:00:29+02:00)
> Maven home: /Users/henri.biestro/Java/apache-maven-3.6.1
> Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home/jre
> Default locale: en_FR, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
> 
> Details of changes since 3.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/jexl/3.2-RC1/RELEASE-NOTES.txt
> 
> https://dist.apache.org/repos/dist/dev/commons/jexl/3.2-RC1/site/changes-report.html
> 
> Site:
> 
> https://dist.apache.org/repos/dist/dev/commons/jexl/3.2-RC1/site/index.html
> (note some *relative* links are broken and the 3.2 directories are not 
> yet created - these will be OK once