Re: [rng] Split and Jump functions

2019-05-02 Thread Alex Herbert 



> On 1 May 2019, at 23:15, Gilles Sadowski  wrote:
> 
> Hi.
> 
>>> [...]
>> 
>> So do we do:
>> 
>> UniformRandomProvider restrict(JumpableUniformRandomProvider);
>> JumpableUniformRandomProvider restrict(LongJumpableUniformRandomProvider);
>> UniformRandomProvider restrict(RestorableUniformRandomProvider);
>> 
>> Or:
>> 
>> UniformRandomProvider unjumpable(JumpableUniformRandomProvider);
>> JumpableUniformRandomProvider 
>> unlongJumpable(LongJumpableUniformRandomProvider);
> 
> I'm a bit hesitant on the spelling…

Do you mean unlongJumpable vs unLongJumpable vs unlongjumpable? In that regard 
I was maintaining the likeness to unrestorable, but since there are two words 
after 'un' I put the second with camelcase.

Or just the entire method name? I don’t like it much but its function is clear: 
allow access to jump() but not longJump().

> 
>> UniformRandomProvider unrestorable(RestorableUniformRandomProvider);
>> 
>> The later option only adds two new methods. The first has 3 new methods 
>> (deprecating unrestorable with restrict) but suffers from having to cast 
>> instances of multiple interfaces to ensure the correct restrict is called.
> 
> Oops indeed.
> This is too error-prone.
> 
>> So this makes me favour the verbosely named option.
> 
> +1
> 
> Regards,
> Gilles
> 
>> 
>> 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

[statistics]Log-Cauchy Distribution

2019-05-02 Thread Udit Arora 
This is a new discussion for making a Log-Cauchy Distribution.
I just want to add a new distribution to the already existing distribution
list. Just like Cauchy Distribution I intend to include CDF, PDF and some
other functions.
Please let me know if I should go ahead with this idea.
Thanks
Udit Arora

Re: [lang] Deamon thread factory

2019-05-02 Thread Gary Gregory 
On Thu, May 2, 2019 at 11:27 AM Oliver Heger 
wrote:

> Hi,
>
> BasicThreadFactory has an option to create daemon threads. I assume, you
> have found out in the meantime?
>

I sure did.

Thank you!
Gary


>
> Oliver
>
> Am 01.05.19 um 23:07 schrieb Gary Gregory:
> > Hi All,
> >
> > Hard to believe, but we do not have one yet.
> >
> > https://issues.apache.org/jira/browse/LANG-1455
> >
> > Assigned to your truly.
> >
> > Gary
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances

2019-05-02 Thread Gary Gregory 
On Thu, May 2, 2019 at 10:59 AM Tomo Suzuki 
wrote:

> Gary,
> I didn't find ConstantUtf8.getCachedInstance
> 
> is used in BCEL (latest 6.3.1). I tried my custom ConstantUtf8 modification
> to leverage getCachedInstance method and it worked well:
>
> Before
>
> Without getCachedInstance, my tool created 2,6 million ConstantUtf8
> instances (before failing OutOfMemoryError: GC overhead limit exceeded) to
> check ~200 jar files
> [image: 2644k_constantutf8_without_getCachedInstance.png]
>
>
> After
>
> With getCachedInstance, my tool created just 0.6 million ConstantUtf8
> instances. It didn't throw the OutOfMemoryError.
> [image: 621k_constantutf8_with_getCachedInstance.png]
>
> My modification was to use getCachedInstance for
> ConstantUtf8.getInstance(DataInput)
> 
> .
>
>
> Do you know why ConstantUtf8.getCachedInstance is unused?
>

I do not.

Gary


>
> Regards,
> Tomo
>
>
>
> On Wed, May 1, 2019 at 7:02 PM Gary Gregory 
> wrote:
>
>> On Wed, May 1, 2019 at 6:37 PM Tomo Suzuki 
>> wrote:
>>
>> > Gary,
>> > That’s right. I missed it. I think I just need to find a way to leverage
>> > the getCachedInstance method. Thank you for quick response.
>> >
>>
>> YW. Please let us know your outcome.
>>
>> Gary
>>
>>
>> >
>> > On Wed, May 1, 2019 at 18:00 Gary Gregory 
>> wrote:
>> >
>> > > Why not use getCachedInstance() ?
>> > >
>> > > Gary
>> > >
>> > > On Wed, May 1, 2019 at 5:20 PM Tomo Suzuki > >
>> > > wrote:
>> > >
>> > > > Hi BCEL developers,
>> > > >
>> > > > We use BCEL library to inspect Java class. Thank you for the great
>> > > library.
>> > > >
>> > > > When our tool checks classes in ~200 jar files, it creates more
>> than 2
>> > > > million BCEL ConstantUtf8 instances. I suspect many of them share
>> the
>> > > same
>> > > > values such as "java.lang.String".
>> > > >
>> > > > [image: many_constant_utf8.png]
>> > > >
>> > > > Given this observation, I got an idea to to reuse ConstantUtf8 with
>> > same
>> > > > value to save memory footprint. Because ConstantUtf8 is constant,
>> > sharing
>> > > > the instances across classes should not cause a problem. Note that
>> BCEL
>> > > is
>> > > > not designed thread-safe (doc
>> > > > ).
>> > > >
>> > > > If this is a good idea, I'm thinking to make a pull request around
>> > BCEL's
>> > > > ConstantUtf8.getInstance method:
>> > > >
>> > > >
>> > >
>> >
>> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java#L116
>> > > >
>> > > > Does anybody have any thought?
>> > > >
>> > > > --
>> > > > Regards,
>> > > > Tomo
>> > > >
>> > >
>> > --
>> > Regards,
>> > Tomo
>> >
>>
>
>
> --
> Regards,
> Tomo
>

Re: [All] Help with GitHub "support"

2019-05-02 Thread Eric Barnhill 
I am happy to review PRs and approve merges as well, it's become part of my
daily routine at work to use GitHub in this way, so it's no trouble.

On Thu, May 2, 2019 at 3:56 AM Gilles Sadowski  wrote:

> Hi.
>
> Some people are providing PRs[1] on GitHub without engaging with
> us, here, or on JIRA.
> When this happens for codes[2] which I'm the assumed reviewer,[3]
> I'd need help from someone, with a GitHub account, who would post
> a comment there, in order to let the "outside" contributors know that
> we won't apply PRs without tracking information (JIRA ticket and/or
> post on "dev"), as per the "contributions guidelines".[4]
>
> Thanks,
> Gilles
>
> [1] Last examples:
> https://github.com/apache/commons-math/pull/105
> https://github.com/apache/commons-statistics/pull/4
> [2] "RNG", "Numbers", "Statistics"
> [3] Unless someone else is willing to engage in reviewing the
> proposal on GitHub, and perform the merge.
> [4] http://commons.apache.org/patches.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [lang] Deamon thread factory

2019-05-02 Thread Oliver Heger 
Hi,

BasicThreadFactory has an option to create daemon threads. I assume, you
have found out in the meantime?

Oliver

Am 01.05.19 um 23:07 schrieb Gary Gregory:
> Hi All,
> 
> Hard to believe, but we do not have one yet.
> 
> https://issues.apache.org/jira/browse/LANG-1455
> 
> Assigned to your truly.
> 
> Gary
> 

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

Re: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances

2019-05-02 Thread Tomo Suzuki 
Gary,
I didn't find ConstantUtf8.getCachedInstance

is used in BCEL (latest 6.3.1). I tried my custom ConstantUtf8 modification
to leverage getCachedInstance method and it worked well:

Before

Without getCachedInstance, my tool created 2,6 million ConstantUtf8
instances (before failing OutOfMemoryError: GC overhead limit exceeded) to
check ~200 jar files
[image: 2644k_constantutf8_without_getCachedInstance.png]


After

With getCachedInstance, my tool created just 0.6 million ConstantUtf8
instances. It didn't throw the OutOfMemoryError.
[image: 621k_constantutf8_with_getCachedInstance.png]

My modification was to use getCachedInstance for
ConstantUtf8.getInstance(DataInput)

.


Do you know why ConstantUtf8.getCachedInstance is unused?

Regards,
Tomo



On Wed, May 1, 2019 at 7:02 PM Gary Gregory  wrote:

> On Wed, May 1, 2019 at 6:37 PM Tomo Suzuki 
> wrote:
>
> > Gary,
> > That’s right. I missed it. I think I just need to find a way to leverage
> > the getCachedInstance method. Thank you for quick response.
> >
>
> YW. Please let us know your outcome.
>
> Gary
>
>
> >
> > On Wed, May 1, 2019 at 18:00 Gary Gregory 
> wrote:
> >
> > > Why not use getCachedInstance() ?
> > >
> > > Gary
> > >
> > > On Wed, May 1, 2019 at 5:20 PM Tomo Suzuki  >
> > > wrote:
> > >
> > > > Hi BCEL developers,
> > > >
> > > > We use BCEL library to inspect Java class. Thank you for the great
> > > library.
> > > >
> > > > When our tool checks classes in ~200 jar files, it creates more than
> 2
> > > > million BCEL ConstantUtf8 instances. I suspect many of them share the
> > > same
> > > > values such as "java.lang.String".
> > > >
> > > > [image: many_constant_utf8.png]
> > > >
> > > > Given this observation, I got an idea to to reuse ConstantUtf8 with
> > same
> > > > value to save memory footprint. Because ConstantUtf8 is constant,
> > sharing
> > > > the instances across classes should not cause a problem. Note that
> BCEL
> > > is
> > > > not designed thread-safe (doc
> > > > ).
> > > >
> > > > If this is a good idea, I'm thinking to make a pull request around
> > BCEL's
> > > > ConstantUtf8.getInstance method:
> > > >
> > > >
> > >
> >
> https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java#L116
> > > >
> > > > Does anybody have any thought?
> > > >
> > > > --
> > > > Regards,
> > > > Tomo
> > > >
> > >
> > --
> > Regards,
> > Tomo
> >
>


-- 
Regards,
Tomo

Re: [All] Help with GitHub "support"

2019-05-02 Thread Gilles Sadowski 
Thank you Bruno and Alex!

Best,
Gilles

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

Re: [VFS] Deleting the git branch 'trunk'

2019-05-02 Thread sebb 
On Thu, 2 May 2019 at 00:09, Bruno P. Kinoshita
 wrote:
>
>  Yesterday I submitted a pull request against the wrong branch in GitHub. 
> Spent a couple of minutes scratching my head and trying to find out how to 
> change that... then found the option while editing it.
>
> GitHub help has a page explaining how to do that: 
> https://help.github.com/en/articles/changing-the-base-branch-of-a-pull-request

Thanks, it's pretty easy - apart from the issue of how to determine
whether commits will be removed from the timeline.


> CheersBruno
>
>
> On Thursday, 2 May 2019, 10:23:50 am NZST, sebb  wrote:
>
>  On Wed, 1 May 2019 at 23:02, Gary Gregory  wrote:
> >
> > On Wed, May 1, 2019 at 5:30 PM sebb  wrote:
> >
> > > On Wed, 1 May 2019 at 21:48, Gary Gregory  wrote:
> > > >
> > > > On Wed, May 1, 2019 at 3:54 PM Gary Gregory 
> > > wrote:
> > > >
> > > > > I created https://issues.apache.org/jira/browse/INFRA-18316
> > > > >
> > > >
> > > > And the work is done. Note that open PRs on trunk have been closed
> > > > automatically, so they would need to be re-opened.
> > >
> > > That sounds like a LOT of work.
> > >
> > > How can they be re-opened?
> > >
> >
> > Here:
> >
> > https://issues.apache.org/jira/browse/INFRA-18316?focusedCommentId=16831238=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16831238
> >
> > Mark T. says this is a manual process.
>
> Re-opening the PR is pretty easy.
>
> However the PRs then need to be modified to be against master rather than 
> trunk.
>
> How does one do that?
>
> > Gary
> >
> >
> > >
> > > > Gary
> > > >
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > > On Wed, May 1, 2019 at 3:55 AM Benedikt Ritter 
> > > wrote:
> > > > >
> > > > >> Am Di., 30. Apr. 2019 um 14:43 Uhr schrieb Gary Gregory <
> > > > >> garydgreg...@gmail.com>:
> > > > >>
> > > > >> > Should we take a broader stroke and remove ALL trunk branches from
> > > all
> > > > >> > Commons git repos?
> > > > >> >
> > > > >>
> > > > >> I think we should remove all trunk branches from git repos.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > Gary
> > > > >> >
> > > > >> > On Mon, Apr 29, 2019 at 11:25 AM Otto Fowler <
> > > ottobackwa...@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Probably need INFRA
> > > > >> > >
> > > > >> > >
> > > > >> > > On April 29, 2019 at 11:23:38, Gary Gregory (
> > > garydgreg...@gmail.com)
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > On Mon, Apr 29, 2019 at 11:22 AM Gary Gregory <
> > > garydgreg...@gmail.com
> > > > >> >
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Well, crud, neither these works:
> > > > >> > > >
> > > > >> > > > C:\git\commons-vfs>git push origin --delete trunk
> > > > >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> > > > >> > > > remote:
> > > > >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > > >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> > > > >> > > > error: failed to push some refs to '
> > > > >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > > > >> > > >
> > > > >> > > > C:\git\commons-vfs> git push origin :trunk
> > > > >> > > > remote: Rewinding refs/heads/trunk is forbidden.
> > > > >> > > > remote:
> > > > >> > > > To https://gitbox.apache.org/repos/asf/commons-vfs
> > > > >> > > > ! [remote rejected] trunk (pre-receive hook declined)
> > > > >> > > > error: failed to push some refs to '
> > > > >> > > > https://gitbox.apache.org/repos/asf/commons-vfs'
> > > > >> > > >
> > > > >> > > > Thoughts?
> > > > >> > > >
> > > > >> > >
> > > > >> > > BTW, I had deleted the branch locally OK with 'git branch -d
> > > trunk'
> > > > >> > >
> > > > >> > > Gary
> > > > >> > >
> > > > >> > >
> > > > >> > > >
> > > > >> > > > Gary
> > > > >> > > >
> > > > >> > > > On Mon, Apr 29, 2019 at 11:11 AM Rob Tompkins <
> > > chtom...@gmail.com>
> > > > >> > > wrote:
> > > > >> > > >
> > > > >> > > >> +1
> > > > >> > > >>
> > > > >> > > >> > On Apr 29, 2019, at 10:58 AM, Otto Fowler <
> > > > >> ottobackwa...@gmail.com>
> > > > >> > > >> wrote:
> > > > >> > > >> >
> > > > >> > > >> > +1
> > > > >> > > >> >
> > > > >> > > >> >
> > > > >> > > >> > On April 29, 2019 at 08:01:43, Gary Gregory (
> > > > >> garydgreg...@gmail.com
> > > > >> > )
> > > > >> > > >> wrote:
> > > > >> > > >> >
> > > > >> > > >> > I am going to delete the branch 'trunk'.
> > > > >> > > >> >
> > > > >> > > >> > It's too confusing.
> > > > >> > > >> >
> > > > >> > > >> > 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

Re: [All] Help with GitHub "support"

2019-05-02 Thread Alex Herbert 

Hi Gilles,

I saw the PR for Statistics and noted that it was a trivial change that 
may not be warranted, or at least not in the form provided. I'll make 
more time to watch PRs for those projects you mentioned.


Alex

On 02/05/2019 12:32, Bruno P. Kinoshita wrote:

  Commented on the two PRs linked here. I am almost through the 
commons-imaging-1.0-alpha1 release (finally!). After that I will finally be 
able to use more development time to run through components with pending PR's 
and issues, and try to reply to some of these contributors.
Thanks Gilles!
Bruno

 On Thursday, 2 May 2019, 10:56:25 pm NZST, Gilles Sadowski 
 wrote:
  
  Hi.


Some people are providing PRs[1] on GitHub without engaging with
us, here, or on JIRA.
When this happens for codes[2] which I'm the assumed reviewer,[3]
I'd need help from someone, with a GitHub account, who would post
a comment there, in order to let the "outside" contributors know that
we won't apply PRs without tracking information (JIRA ticket and/or
post on "dev"), as per the "contributions guidelines".[4]

Thanks,
Gilles

[1] Last examples:
     https://github.com/apache/commons-math/pull/105
     https://github.com/apache/commons-statistics/pull/4
[2] "RNG", "Numbers", "Statistics"
[3] Unless someone else is willing to engage in reviewing the
proposal on GitHub, and perform the merge.
[4] http://commons.apache.org/patches.html

-
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] Help with GitHub "support"

2019-05-02 Thread Bruno P. Kinoshita 
 Commented on the two PRs linked here. I am almost through the 
commons-imaging-1.0-alpha1 release (finally!). After that I will finally be 
able to use more development time to run through components with pending PR's 
and issues, and try to reply to some of these contributors.
Thanks Gilles!
Bruno

On Thursday, 2 May 2019, 10:56:25 pm NZST, Gilles Sadowski 
 wrote:  
 
 Hi.

Some people are providing PRs[1] on GitHub without engaging with
us, here, or on JIRA.
When this happens for codes[2] which I'm the assumed reviewer,[3]
I'd need help from someone, with a GitHub account, who would post
a comment there, in order to let the "outside" contributors know that
we won't apply PRs without tracking information (JIRA ticket and/or
post on "dev"), as per the "contributions guidelines".[4]

Thanks,
Gilles

[1] Last examples:
    https://github.com/apache/commons-math/pull/105
    https://github.com/apache/commons-statistics/pull/4
[2] "RNG", "Numbers", "Statistics"
[3] Unless someone else is willing to engage in reviewing the
proposal on GitHub, and perform the merge.
[4] http://commons.apache.org/patches.html

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

[All] Help with GitHub "support"

2019-05-02 Thread Gilles Sadowski 
Hi.

Some people are providing PRs[1] on GitHub without engaging with
us, here, or on JIRA.
When this happens for codes[2] which I'm the assumed reviewer,[3]
I'd need help from someone, with a GitHub account, who would post
a comment there, in order to let the "outside" contributors know that
we won't apply PRs without tracking information (JIRA ticket and/or
post on "dev"), as per the "contributions guidelines".[4]

Thanks,
Gilles

[1] Last examples:
https://github.com/apache/commons-math/pull/105
https://github.com/apache/commons-statistics/pull/4
[2] "RNG", "Numbers", "Statistics"
[3] Unless someone else is willing to engage in reviewing the
proposal on GitHub, and perform the merge.
[4] http://commons.apache.org/patches.html

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

Re: [VOTE] Release Apache Commons Imaging 1.0-alpha1 based on RC3

2019-05-02 Thread Bruno P. Kinoshita 
 This vote passes with +1s from:


Benedikt Ritter: +1,
Gary Gregory: +1,
Rob Tompkins: +1,
Bruno P. Kinoshita +1.


I will proceed with the release process.

Thanks,
Bruno

On Sunday, 28 April 2019, 12:22:52 am NZST, Bruno P. Kinoshita 
 wrote:  
 
 I would like to release Apache Commons Imaging 1.0-alpha1.

Apache Commons Imaging 1.0-alpha1 RC3 is available for review here:
    https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3 (svn 
revision 33801)

The Git tag commons-imaging-1.0-alpha1-RC3 commit for this RC is 
6f04ccc2cf8c867298579c355c6d88fd74da3e7b which you can browse here:
    
https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC3

Maven artifacts are here:
    
https://repository.apache.org/content/repositories/orgapachecommons-1438/org/apache/commons/commons-imaging/1.0-alpha1/

These are the Maven artifacts and their hashes in Nexus:

${commons.sha256list}
#Release SHA-512s
#Sat Apr 27 23:40:11 NZST 2019
commons-imaging-1.0-alpha1-sources-java-source=320ed4dae9045e38f4956558b38497593de35197051e6370cc5d959782e191ec40cbdf651cc0e5dfe62afd25d9fbad0dc73ff3db4a914757a058f1b88570a649
commons-imaging-1.0-alpha1-bin-zip=699124772e2ad47be85230fa6529eb710a26567c416e5d950445a637b426f86c3ad1c9577f41f7e2f6bd94016b14192077ba3305a85ff36601ca36703a935eb7
commons-imaging-1.0-alpha1-sources-jar.asc=2e8445b62c1a4afbbae0f7ccdd97d18f2ba2db57c5be649c089a70bce70e816c55422241ee44040ee3122bae45f05c664bf07764446a72b623272dc540cb255b
commons-imaging-1.0-alpha1-src-zip.asc=21acf6132380c42c6823f599ff6c31900868ac5131837ed17c9c40c7e99d3b88410a2d5331b922da605f54a9cf68ff70d705d3ca94cd6db7a4f9b5d0a9e1c3ee
commons-imaging-1.0-alpha1-pom.asc=38d13c75c3f134b39b31a8e6ad563e921bd9a7ad8008dd78854999841463a45ca98c52547b84657cb7700725bf683c22bf925be898107a4ce7c6d0f35ee83c61
commons-imaging-1.0-alpha1-tests-jar.asc=6f800eaaf02550e3b13d459b2e8885f5bf5b3bed02611997cf6c35fb782ef5a634eb21c907d046167778df6a3cfbd948c9cb464a34da88813ce08ccd5ebba386
commons-imaging-1.0-alpha1-javadoc-jar.asc=7c562516e9f88b7490b7123fc529d5dc33303453c5990bcf23ecfc9ca46fc6df5324c3cdc5bf49bfa4e7d3de49d80591d97721df6890369cdbf95aba700d577f
commons-imaging-1.0-alpha1-tests-test-jar=58a9ac4861a70a87d3490d09e2d90e6ef0293711a9edf3f7fab10776e9d37484c421f4be283531aa6985abbac474604e0f633442b509e0b1ccef1a95a788c754
commons-imaging-1.0-alpha1-jar.asc=18a007c1185de84b3395b1d8b2e1e1c466939020646c015fca29be4fc1d9647ec4d8afcc20bf562bfdae01d740b0117bd3b904fd022b7d6e944569c78517adc5
commons-imaging-1.0-alpha1-bin-tar.gz.asc=31995c5e035a753d86294f90850de1d73fef478a6bb234cebab6272b9c5521dcb1e5ec3a180508929e765f18af4202dbbe616b0264f7ab50c40be793cca1
commons-imaging-1.0-alpha1-test-sources-jar.asc=6f3265c73f2f3b4d67b4d084f2e309032591fdbd25b40b93cb854d8f9c61a719bc27b3de37ed5faf36caed295a944f1e48399e1120b55f307d9bb842b965d5b7
commons-imaging-1.0-alpha1-src-tar.gz=3c06195e75161e5bf2364f358169a2cd9231c8c30c526c060efa7d8972394ddcdb2bc2a9caa64073700e2c7eabf0830ccd33a84defafc72a444889a579e86073
commons-imaging-1.0-alpha1-bin-zip.asc=69dbfbb5f2aa2a85ae87c4510777643706214dec171c87b1ee992b5f5caab9401ef32ad54dcaf2e590a8cf694a9bb89d0e335c13fff0a95dc402454b287b99a6
commons-imaging-1.0-alpha1-javadoc-javadoc=7cde692d47ce4f2936803b9c8d54ad7c71a070507d6c8fd4533421d43fc019908e24ade7264b01080e1c614d26c71454237a000fb81a464e83907d35b6450730
commons-imaging-1.0-alpha1-src-zip=8eea523c614561b7da7c1e3203a0c48f1d3fdcaaf178e843c7834ff6b546ee7f09270385558adc16583bd1cd6e6d953a3b67ffcf117727bb7ad1b45d9b546a4a
commons-imaging-1.0-alpha1-bin-tar.gz=f7ac881d8439007d1b4f0ba83df3da75ebdc2b2b0e7632762cb0ad9e5ec57f6553ae72223a1d91c30cc7035dfd28009d778653f18fc5476cf27fc040f1df717f
commons-imaging-1.0-alpha1-test-sources-java-source=16cea0d32ae8a9da68d8bafa52a1519c5a9f20dd3097acb5826ddcc6364747af01d81b76b12c3ce9e40da049f3a2aaa78259ac7ea57ea8334c3f79c42cb75aae
commons-imaging-1.0-alpha1-src-tar.gz.asc=cdb66c75cdf944756ff857422c3f1172832abc0889ef501f0ee7f925643470beea1304c9f7782beb089e77c1ea65f2dc23bb2dc37f756dec5f8d5d52c83d9e01


(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using: 

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-47-generic", arch: "amd64", family: "unix"

Details of changes are in the release notes:
    
https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/RELEASE-NOTES.txt
    
https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/site/changes-report.html

Site:
    https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/site
    (note some *relative* links are broken and the 1.0-alpha1 directories are 
not yet created - these will be OK once the site is deployed.)

Note no

[RESULT][VOTE] Release Apache Commons Imaging 1.0-alpha1 based on RC3

2019-05-02 Thread Bruno P. Kinoshita 
 This vote passes with +1s from:


Benedikt Ritter: +1,

Gary Gregory: +1,
Rob Tompkins: +1,
Bruno P. Kinoshita +1.

I will proceed with the release process.


Thanks,

Bruno
ps: sent again with the correct subject this time


On Sunday, 28 April 2019, 12:22:52 am NZST, Bruno P. Kinoshita 
 wrote:  
 
 I would like to release Apache Commons Imaging 1.0-alpha1.

Apache Commons Imaging 1.0-alpha1 RC3 is available for review here:
    https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3 (svn 
revision 33801)

The Git tag commons-imaging-1.0-alpha1-RC3 commit for this RC is 
6f04ccc2cf8c867298579c355c6d88fd74da3e7b which you can browse here:
    
https://git-wip-us.apache.org/repos/asf?p=commons-imaging.git;a=tag;h=refs/tags/commons-imaging-1.0-alpha1-RC3

Maven artifacts are here:
    
https://repository.apache.org/content/repositories/orgapachecommons-1438/org/apache/commons/commons-imaging/1.0-alpha1/

These are the Maven artifacts and their hashes in Nexus:

${commons.sha256list}
#Release SHA-512s
#Sat Apr 27 23:40:11 NZST 2019
commons-imaging-1.0-alpha1-sources-java-source=320ed4dae9045e38f4956558b38497593de35197051e6370cc5d959782e191ec40cbdf651cc0e5dfe62afd25d9fbad0dc73ff3db4a914757a058f1b88570a649
commons-imaging-1.0-alpha1-bin-zip=699124772e2ad47be85230fa6529eb710a26567c416e5d950445a637b426f86c3ad1c9577f41f7e2f6bd94016b14192077ba3305a85ff36601ca36703a935eb7
commons-imaging-1.0-alpha1-sources-jar.asc=2e8445b62c1a4afbbae0f7ccdd97d18f2ba2db57c5be649c089a70bce70e816c55422241ee44040ee3122bae45f05c664bf07764446a72b623272dc540cb255b
commons-imaging-1.0-alpha1-src-zip.asc=21acf6132380c42c6823f599ff6c31900868ac5131837ed17c9c40c7e99d3b88410a2d5331b922da605f54a9cf68ff70d705d3ca94cd6db7a4f9b5d0a9e1c3ee
commons-imaging-1.0-alpha1-pom.asc=38d13c75c3f134b39b31a8e6ad563e921bd9a7ad8008dd78854999841463a45ca98c52547b84657cb7700725bf683c22bf925be898107a4ce7c6d0f35ee83c61
commons-imaging-1.0-alpha1-tests-jar.asc=6f800eaaf02550e3b13d459b2e8885f5bf5b3bed02611997cf6c35fb782ef5a634eb21c907d046167778df6a3cfbd948c9cb464a34da88813ce08ccd5ebba386
commons-imaging-1.0-alpha1-javadoc-jar.asc=7c562516e9f88b7490b7123fc529d5dc33303453c5990bcf23ecfc9ca46fc6df5324c3cdc5bf49bfa4e7d3de49d80591d97721df6890369cdbf95aba700d577f
commons-imaging-1.0-alpha1-tests-test-jar=58a9ac4861a70a87d3490d09e2d90e6ef0293711a9edf3f7fab10776e9d37484c421f4be283531aa6985abbac474604e0f633442b509e0b1ccef1a95a788c754
commons-imaging-1.0-alpha1-jar.asc=18a007c1185de84b3395b1d8b2e1e1c466939020646c015fca29be4fc1d9647ec4d8afcc20bf562bfdae01d740b0117bd3b904fd022b7d6e944569c78517adc5
commons-imaging-1.0-alpha1-bin-tar.gz.asc=31995c5e035a753d86294f90850de1d73fef478a6bb234cebab6272b9c5521dcb1e5ec3a180508929e765f18af4202dbbe616b0264f7ab50c40be793cca1
commons-imaging-1.0-alpha1-test-sources-jar.asc=6f3265c73f2f3b4d67b4d084f2e309032591fdbd25b40b93cb854d8f9c61a719bc27b3de37ed5faf36caed295a944f1e48399e1120b55f307d9bb842b965d5b7
commons-imaging-1.0-alpha1-src-tar.gz=3c06195e75161e5bf2364f358169a2cd9231c8c30c526c060efa7d8972394ddcdb2bc2a9caa64073700e2c7eabf0830ccd33a84defafc72a444889a579e86073
commons-imaging-1.0-alpha1-bin-zip.asc=69dbfbb5f2aa2a85ae87c4510777643706214dec171c87b1ee992b5f5caab9401ef32ad54dcaf2e590a8cf694a9bb89d0e335c13fff0a95dc402454b287b99a6
commons-imaging-1.0-alpha1-javadoc-javadoc=7cde692d47ce4f2936803b9c8d54ad7c71a070507d6c8fd4533421d43fc019908e24ade7264b01080e1c614d26c71454237a000fb81a464e83907d35b6450730
commons-imaging-1.0-alpha1-src-zip=8eea523c614561b7da7c1e3203a0c48f1d3fdcaaf178e843c7834ff6b546ee7f09270385558adc16583bd1cd6e6d953a3b67ffcf117727bb7ad1b45d9b546a4a
commons-imaging-1.0-alpha1-bin-tar.gz=f7ac881d8439007d1b4f0ba83df3da75ebdc2b2b0e7632762cb0ad9e5ec57f6553ae72223a1d91c30cc7035dfd28009d778653f18fc5476cf27fc040f1df717f
commons-imaging-1.0-alpha1-test-sources-java-source=16cea0d32ae8a9da68d8bafa52a1519c5a9f20dd3097acb5826ddcc6364747af01d81b76b12c3ce9e40da049f3a2aaa78259ac7ea57ea8334c3f79c42cb75aae
commons-imaging-1.0-alpha1-src-tar.gz.asc=cdb66c75cdf944756ff857422c3f1172832abc0889ef501f0ee7f925643470beea1304c9f7782beb089e77c1ea65f2dc23bb2dc37f756dec5f8d5d52c83d9e01


(no need for .asc hashes!)

I have tested this with ***'mvn clean install site'*** using: 

Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 
2018-06-18T06:33:14+12:00)
Maven home: /opt/apache-maven-3.5.4
Java version: 1.8.0_191, vendor: Oracle Corporation, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_NZ, platform encoding: UTF-8
OS name: "linux", version: "4.15.0-47-generic", arch: "amd64", family: "unix"

Details of changes are in the release notes:
    
https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/RELEASE-NOTES.txt
    
https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/site/changes-report.html

Site:
    https://dist.apache.org/repos/dist/dev/commons/imaging/1.0-alpha1-RC3/site
    (note some *relative* links are broken and the 1.0-alpha1 directories are 
not yet created - these