date:20180320

[RESULT][VOTE] Release Commons Text 1.3 based on RC1

2018-03-20 Thread Rob Tompkins

This [VOTE] passes with the following +1 votes:

Gary Gregory,
Oliver Heger,
Pascal Schumacher, and
myself.

I will go ahead and perform the promotion mechanics (tomorrow morning…I’ve got 
a bit of a bug too). And, many thanks for the validations.

Cheers,
-Rob


> On Mar 16, 2018, at 11:35 AM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).
> 
> Tag name:
>   commons-text-1.3-RC1 (signature can be checked from git using 'git tag
> -v')
> 
> Tag URL:
>   
> https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358
> 
> Commit ID the tag points at:
>4ac48357180c9222f032dd8b055d90e1192e4a47
> 
> Site Zip:
>   https://dist.apache.org/repos/dist/dev/commons/text/site.zip
> 
> Distribution files (committed at revision 25771):
>   https://dist.apache.org/repos/dist/dev/commons/text/
> 
> Distribution files hashes (SHA1):
>   commons-text-1.3-bin.tar.gz
>   (SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
>   commons-text-1.3-bin.zip
>   (SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
>   commons-text-1.3-src.tar.gz
>   (SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
>   commons-text-1.3-src.zip
>   (SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)
> 
> These are the Maven artifacts and their hashes:
>   commons-text-1.3-javadoc.jar
>   (SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
>   commons-text-1.3-sources.jar
>   (SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
>   commons-text-1.3-test-sources.jar
>   (SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
>   commons-text-1.3-tests.jar
>   (SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
>   commons-text-1.3.jar
>   (SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
>   commons-text-1.3.pom
>   (SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1319
> 
> Please select one of the following options[1]:
>  [ ] +1 Release it.
>  [ ] +0 Go ahead; I don't care.
>  [ ] -0 There are a few minor glitches: ...
>  [ ] -1 No, do not release it because ...
> 
> This vote will be open at least 72 hours, i.e. until 
> 2018-03-19T16:00:00Z
> (this is UTC time).
> 
> 
> Cheers,
> -Rob
> 
> [1] http://apache.org/foundation/voting.html


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

Re: [VOTE] Release Commons Text 1.3 based on RC1

2018-03-20 Thread Rob Tompkins

Here’s my +1.

> On Mar 16, 2018, at 11:35 AM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).
> 
> Tag name:
>   commons-text-1.3-RC1 (signature can be checked from git using 'git tag
> -v')
> 
> Tag URL:
>   
> https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358
> 
> Commit ID the tag points at:
>4ac48357180c9222f032dd8b055d90e1192e4a47
> 
> Site Zip:
>   https://dist.apache.org/repos/dist/dev/commons/text/site.zip
> 
> Distribution files (committed at revision 25771):
>   https://dist.apache.org/repos/dist/dev/commons/text/
> 
> Distribution files hashes (SHA1):
>   commons-text-1.3-bin.tar.gz
>   (SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
>   commons-text-1.3-bin.zip
>   (SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
>   commons-text-1.3-src.tar.gz
>   (SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
>   commons-text-1.3-src.zip
>   (SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)
> 
> These are the Maven artifacts and their hashes:
>   commons-text-1.3-javadoc.jar
>   (SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
>   commons-text-1.3-sources.jar
>   (SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
>   commons-text-1.3-test-sources.jar
>   (SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
>   commons-text-1.3-tests.jar
>   (SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
>   commons-text-1.3.jar
>   (SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
>   commons-text-1.3.pom
>   (SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1319
> 
> Please select one of the following options[1]:
>  [ ] +1 Release it.
>  [ ] +0 Go ahead; I don't care.
>  [ ] -0 There are a few minor glitches: ...
>  [ ] -1 No, do not release it because ...
> 
> This vote will be open at least 72 hours, i.e. until 
> 2018-03-19T16:00:00Z
> (this is UTC time).
> 
> 
> Cheers,
> -Rob
> 
> [1] http://apache.org/foundation/voting.html


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

Re: [ANNOUNCE] Commons Parent 45 released.

2018-03-20 Thread Rob Tompkins

No problem, pardon having to roll a new release.

> On Mar 20, 2018, at 12:00 PM, Gary Gregory  wrote:
> 
> Thanks Rob!
> 
> Gary
> 
> On Thu, Mar 15, 2018 at 12:58 PM, Rob Tompkins  wrote:
> 
>> [This announcement is only going to the dev list.]
>> 
>> Hello All,
>> 
>> Commons Parent 45 has been released.
>> 
>> The change from release 44 is:
>> 
>>- Rearranging plugin order in -Prelease, removing
>> commons-release-plugin from build>pluginManagement
>> 
>> The changes from release 43 are:
>> 
>>- new profile module-name to add 'Automatic-Module-Name' entry to the
>> manifest
>>- felix:maven-bundle-plugin 3.4.0 -> 3.5.0.
>>- build artifacts -test.jar, -sources.jar and -test-sources.jar
>> always, not
>> only at release time
>>- maven-enforcer-plugin set version to 3.0.0-M1 and update Maven
>> requirement
>> from 3.0.0 to 3.0.5 (the latest 3.0.x.)
>>- jacoco-maven-plugin 0.7.9 -> 0.8.0.
>>- Fix japicmp config: add to reporting section and define
>> ignoreMissingNewVersion explicitly
>>- org.apache:apache 18 -> 19
>>- add commons-release-plugin:1.1
>>- add spotbugs-maven-plugin: 3.1.3
>>- maven-surefire-plugin 2.20.1 -> 2.21.0
>>- maven-failsafe-plugin 2.20.1 -> 2.21.0
>> 
>> Note, the inclusion of the release plugin, means that (for a non multi
>> module
>> build), you will want to add the following two properties to your pom:
>> 
>> commons.release.isDistModule=true
>> commons.distSvnStagingUrl=https://dist.apache.org/repos/
>> dist/dev/commons/foo
>>  (for component foo).
>> 
>> Then for a release when you build, you run:
>> 
>>mvn -Duser.name= -Prelease -Ptest-deploy clean
>> test site
>> deploy
>> 
>> for a test deployment, and:
>> 
>>mvn -Duser.name= -Prelease clean test site deploy
>> 
>> for an actual deployment. To see the artifacts being staged properly, look
>> under
>> “./target/commons-release-plugin/scm” as that is what should end up
>> checked into
>> the dev distribution location.
>> 
>> Note, also that I plan to add the above notes, with more detail to the
>> preparing
>> a release page, and the commons-parent page on the main site. I simply
>> wanted to
>> give directions if anyone was particularly anxious to use the plugin/parent
>> immediately.
>> -
>> 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: [DISCUSS] new component for timing?

2018-03-20 Thread Romain Manni-Bucau

I would be happy to revive sirona @asf but dont think [monitoring] as just
a few classes would bring enough value compare to a lambda not worthing any
lib/dep in apps - just my opinion indeed.

For circuit breaker: geronimo safeguard can be interested in hosting that
utility part and drop failsafe dependency. Maybe something to discuss in
another thread.

Le 20 mars 2018 23:27, "Otto Fowler"  a écrit :

> Sirona is gone, it is a closed incubator project.  Romain has forked it to
> his own repo.
>
>
>
> On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> > If monitoring was started a new, and not re-viving the old
> > monitoring?
>
> Can the feature be contributed to "Sirona"? Otto, are you
> interested in this?
> Does it make sense to have "Commons Monitoring" revived based
> on part/all of "Sirona"?
> Romain, are you interested in this?
> What would be the scope/description of "Commons Monitoring"?
>
> Noting Romain's experience that the original "Commons" project
> evolved into "Sirona", it would be strange to start from scratch
> without a plan to not follow the same route again...
>
> Gilles
>
> > On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> > brunodepau...@yahoo.com.br.invalid) wrote:
> >
> > I think StopWatch and CircuitBreakers could be moved together to the
> > same
> > component. However, a circuit breaker can be time-related, or not
> > (e.g. a
> > circuit breaker for memory size). So probably commons-timing could be
> > a
> > good place for StopWatch, but maybe not for circuit-breaker. But I
> > think
> > both could be under commons-monitoring perhaps?
> >
> > From: Otto Fowler 
> > To: Romain Manni-Bucau ; Commons Developers
> > List <
> > dev@commons.apache.org>
> > Sent: Wednesday, 21 March 2018 10:30 AM
> > Subject: Re: [DISCUSS] new component for timing?
> >
> > I would love to get this on track. I apologize if I have made it
> > more
> > confusing than it needs to be,
> > I’m trying to be open to all the suggestions.
> >
> > If we assume that stack watch is worth ‘having’, then the question is
> > where
> > to put it.
> > commons-monitoring / sirota seems to me to be a ‘complete’ solution
> > as
> > opposed to
> > a set of or collection of like classes.
> >
> > Setting the community support / project aspect of sirota aside, it
> > seems
> > strange to put
> > a separate class into a more complete and uniform system. Unless
> > there is
> > some generically
> > useful set of timing utility classes that could be taken out of
> > sirota to
> > go into commons-,
> > along with things identified ( StopWatch?) out of commons lang and
> > possibly
> > other commons projects.
> >
> > commons-timing seems reasonable. Thoughts?
> >
> >
> >
> > On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> > (rmannibu...@gmail.com)
> > wrote:
> >
> > Yes but consequence was a lack of community increase which is a
> > killer for
> > an incubator project on the long run.
> >
> > Le 17 mars 2018 15:19, "Gilles"  a
> > écrit :
> >
> >> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
> >>
> >>> Le 17 mars 2018 11:49, "Gilles"  a
> >>> écrit :
> >>>
> >>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
> >>>
> >>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
> 
>  If we can come to consensus on the way forward, I’ll be happy to
>  do the
> 
> > work ( although I’ll need help of course ).
> > I guess I’m the straw that broke the camel’s back then? ;)
> >
> >
> >
> >
> > On March 15, 2018 at 08:09:45, Gilles
> > (gil...@harfang.homelinux.org)
> > wrote:
> >
> > Hi.
> >
> > On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> > > I think bringing back commons-monitoring/sirota would only be
> > > possible if
> > > it were to be modular enough that you could bring in the ‘core’
> > > classes
> > > without needing to bring in all of what sirota ended up being,
> > which
> > > was an
> > > end to end solution.
> >
> > Isn't it possible? [I didn't look; Romain should tell whether he
> > would be interested in taking that route.]
> >
> >
> > Sirona was done modular, just the API, the in memory part, etc...
>  But this kind of impl needs way more just after so not sure it
>  does
> > worth
>  splitting it to put it back altogether after.
> 
>  What is the rational to try to push a very small part @commons
>  instead
> > of
>  creating a community @incubator with an E2E solution? This is what
>  I
> > fail
>  to see.
>  My experience - coming exactly from here - tends to make me think
> > commons
>  will not fit very long or will not bring enough value pretty
>  quickly
> >

Re: [DISCUSS] new component for timing?

2018-03-20 Thread Gilles

On Tue, 20 Mar 2018 15:27:45 -0700, Otto Fowler wrote:
Sirona is gone, it is a closed incubator project.  Romain has forked 
it to

his own repo.

The code is there; the rationale is the same: some functionality
started "here" and got "there".
Is anyone interested to get (part of) it back "here"?

Gilles

On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org) 
wrote:

On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:

If monitoring was started a new, and not re-viving the old
monitoring?

Can the feature be contributed to "Sirona"? Otto, are you
interested in this?
Does it make sense to have "Commons Monitoring" revived based
on part/all of "Sirona"?
Romain, are you interested in this?
What would be the scope/description of "Commons Monitoring"?

Noting Romain's experience that the original "Commons" project
evolved into "Sirona", it would be strange to start from scratch
without a plan to not follow the same route again...

Gilles

On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the
same
component. However, a circuit breaker can be time-related, or not
(e.g. a
circuit breaker for memory size). So probably commons-timing could 
be

a
good place for StopWatch, but maybe not for circuit-breaker. But I
think
both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers
List <
dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track. I apologize if I have made it
more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question 
is

where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution
as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it
seems
strange to put
a separate class into a more complete and uniform system. Unless
there is
some generically
useful set of timing utility classes that could be taken out of
sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and
possibly
other commons projects.

commons-timing seems reasonable. Thoughts?

On March 17, 2018 at 11:24:32, Romain Manni-Bucau
(rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a
killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a
écrit :

On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:

Le 17 mars 2018 11:49, "Gilles"  a
écrit :

On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

2018-03-15 14:36 GMT+01:00 Otto Fowler :

If we can come to consensus on the way forward, I’ll be happy to
do the

work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)

On March 15, 2018 at 08:09:45, Gilles
(gil...@harfang.homelinux.org)
wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the 
‘core’

> classes
> without needing to bring in all of what sirota ended up being,
which
> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]

Sirona was done modular, just the API, the in memory part, 
etc...

But this kind of impl needs way more just after so not sure it
does

worth

splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons
instead

of
creating a community @incubator with an E2E solution? This is 
what

I

fail

to see.
My experience - coming exactly from here - tends to make me think

commons

will not fit very long or will not bring enough value pretty
quickly

but

that's just my opinion.

Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate. Unless we learn
1. why the precursor needed to become TLP, and
2. why the TLP didn't succeed,
we'd go in circles.

We failed at community@asf and pby communication/promotion levels 
I

think.
Other parts were successful (prod etc).

[It seems that part of your message went missing.]

Lack of marketing skills should not entail failure, especially
not since communication is a transverse concern.

Gilles

Would it make sense that Sirona becomes (again?) "Commons
Monitoring"?

Does the "StackWatck" (Otto's contribution that started this
discussion)
already exist in a Sirona module? If not, can it be done, so that
usage
is similar to what Otto had in mind?

Regards,
Gilles

commons-monitoring or

Re: [DISCUSS] new component for timing?

2018-03-20 Thread Otto Fowler

Sirona is gone, it is a closed incubator project.  Romain has forked it to
his own repo.



On March 20, 2018 at 18:24:06, Gilles (gil...@harfang.homelinux.org) wrote:

On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
> If monitoring was started a new, and not re-viving the old
> monitoring?

Can the feature be contributed to "Sirona"? Otto, are you
interested in this?
Does it make sense to have "Commons Monitoring" revived based
on part/all of "Sirona"?
Romain, are you interested in this?
What would be the scope/description of "Commons Monitoring"?

Noting Romain's experience that the original "Commons" project
evolved into "Sirona", it would be strange to start from scratch
without a plan to not follow the same route again...

Gilles

> On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
> brunodepau...@yahoo.com.br.invalid) wrote:
>
> I think StopWatch and CircuitBreakers could be moved together to the
> same
> component. However, a circuit breaker can be time-related, or not
> (e.g. a
> circuit breaker for memory size). So probably commons-timing could be
> a
> good place for StopWatch, but maybe not for circuit-breaker. But I
> think
> both could be under commons-monitoring perhaps?
>
> From: Otto Fowler 
> To: Romain Manni-Bucau ; Commons Developers
> List <
> dev@commons.apache.org>
> Sent: Wednesday, 21 March 2018 10:30 AM
> Subject: Re: [DISCUSS] new component for timing?
>
> I would love to get this on track. I apologize if I have made it
> more
> confusing than it needs to be,
> I’m trying to be open to all the suggestions.
>
> If we assume that stack watch is worth ‘having’, then the question is
> where
> to put it.
> commons-monitoring / sirota seems to me to be a ‘complete’ solution
> as
> opposed to
> a set of or collection of like classes.
>
> Setting the community support / project aspect of sirota aside, it
> seems
> strange to put
> a separate class into a more complete and uniform system. Unless
> there is
> some generically
> useful set of timing utility classes that could be taken out of
> sirota to
> go into commons-,
> along with things identified ( StopWatch?) out of commons lang and
> possibly
> other commons projects.
>
> commons-timing seems reasonable. Thoughts?
>
>
>
> On March 17, 2018 at 11:24:32, Romain Manni-Bucau
> (rmannibu...@gmail.com)
> wrote:
>
> Yes but consequence was a lack of community increase which is a
> killer for
> an incubator project on the long run.
>
> Le 17 mars 2018 15:19, "Gilles"  a
> écrit :
>
>> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>>
>>> Le 17 mars 2018 11:49, "Gilles"  a
>>> écrit :
>>>
>>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>>
>>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :

 If we can come to consensus on the way forward, I’ll be happy to
 do the

> work ( although I’ll need help of course ).
> I guess I’m the straw that broke the camel’s back then? ;)
>
>
>
>
> On March 15, 2018 at 08:09:45, Gilles
> (gil...@harfang.homelinux.org)
> wrote:
>
> Hi.
>
> On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> > I think bringing back commons-monitoring/sirota would only be
> > possible if
> > it were to be modular enough that you could bring in the ‘core’
> > classes
> > without needing to bring in all of what sirota ended up being,
> which
> > was an
> > end to end solution.
>
> Isn't it possible? [I didn't look; Romain should tell whether he
> would be interested in taking that route.]
>
>
> Sirona was done modular, just the API, the in memory part, etc...
 But this kind of impl needs way more just after so not sure it
 does
> worth
 splitting it to put it back altogether after.

 What is the rational to try to push a very small part @commons
 instead
> of
 creating a community @incubator with an E2E solution? This is what
 I
> fail
 to see.
 My experience - coming exactly from here - tends to make me think
> commons
 will not fit very long or will not bring enough value pretty
 quickly
> but
 that's just my opinion.


>>> Not "just" an opinion since you evoke Sirona's precursor as being
>>> the kind of component we'd reinstate. Unless we learn
>>> 1. why the precursor needed to become TLP, and
>>> 2. why the TLP didn't succeed,
>>> we'd go in circles.
>>>
>>>
>>> We failed at community@asf and pby communication/promotion levels I
>>> think.
>>> Other parts were successful (prod etc).
>>>
>>>
>> [It seems that part of your message went missing.]
>>
>> Lack of marketing skills should not entail failure, especially
>> not since communication is a transverse concern.
>>
>> Gilles
>>
>> Would it make sense that Sirona becomes (again?) "Commons
>> Monitoring"?
>>> Does the

Re: [DISCUSS] new component for timing?

2018-03-20 Thread Gilles

On Tue, 20 Mar 2018 15:00:41 -0700, Otto Fowler wrote:
If monitoring was started a new, and not re-viving the old 
monitoring?

Can the feature be contributed to "Sirona"?  Otto, are you
interested in this?
Does it make sense to have "Commons Monitoring" revived based
on part/all of "Sirona"?
Romain, are you interested in this?
What would be the scope/description of "Commons Monitoring"?

Noting Romain's experience that the original "Commons" project
evolved into "Sirona", it would be strange to start from scratch
without a plan to not follow the same route again...

Gilles

On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the 
same
component. However, a circuit breaker can be time-related, or not 
(e.g. a
circuit breaker for memory size). So probably commons-timing could be 
a
good place for StopWatch, but maybe not for circuit-breaker. But I 
think

both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers 
List <

dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it 
more

confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is 
where

to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution 
as

opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it 
seems

strange to put
a separate class into a more complete and uniform system.  Unless 
there is

some generically
useful set of timing utility classes that could be taken out of 
sirota to

go into commons-,
along with things identified ( StopWatch?) out of commons lang and 
possibly

other commons projects.

commons-timing seems reasonable.  Thoughts?

On March 17, 2018 at 11:24:32, Romain Manni-Bucau 
(rmannibu...@gmail.com)

wrote:

Yes but consequence was a lack of community increase which is a 
killer for

an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a 
écrit :

On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:

Le 17 mars 2018 11:49, "Gilles"  a 
écrit :

On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:

2018-03-15 14:36 GMT+01:00 Otto Fowler :

If we can come to consensus on the way forward, I’ll be happy to 
do the

work ( although I’ll need help of course ).
I guess I’m the straw that broke the camel’s back then? ;)

On March 15, 2018 at 08:09:45, Gilles 
(gil...@harfang.homelinux.org)

wrote:

Hi.

On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
> I think bringing back commons-monitoring/sirota would only be
> possible if
> it were to be modular enough that you could bring in the ‘core’
> classes
> without needing to bring in all of what sirota ended up being, 
which

> was an
> end to end solution.

Isn't it possible? [I didn't look; Romain should tell whether he
would be interested in taking that route.]

Sirona was done modular, just the API, the in memory part, etc...
But this kind of impl needs way more just after so not sure it 
does

worth

splitting it to put it back altogether after.

What is the rational to try to push a very small part @commons 
instead

of
creating a community @incubator with an E2E solution? This is what 
I

fail

to see.
My experience - coming exactly from here - tends to make me think

commons
will not fit very long or will not bring enough value pretty 
quickly

but

that's just my opinion.

Not "just" an opinion since you evoke Sirona's precursor as being
the kind of component we'd reinstate. Unless we learn
1. why the precursor needed to become TLP, and
2. why the TLP didn't succeed,
we'd go in circles.

We failed at community@asf and pby communication/promotion levels I
think.
Other parts were successful (prod etc).

[It seems that part of your message went missing.]

Lack of marketing skills should not entail failure, especially
not since communication is a transverse concern.

Gilles

Would it make sense that Sirona becomes (again?) "Commons 
Monitoring"?
Does the "StackWatck" (Otto's contribution that started this 
discussion)
already exist in a Sirona module? If not, can it be done, so that 
usage

is similar to what Otto had in mind?

Regards,
Gilles

commons-monitoring or commons-timing seem to be the correct thing

> however,
> but I would like to think that there would be more impetus

I'm afraid that it's rather the lack of manpower.
[And my inner conviction is that that state of things often
led to rush to cramming more code into existing components,
rather than "distribute" more uniformly according to subject
matters.

Re: [VOTE] Release Commons Text 1.3 based on RC1

2018-03-20 Thread Pascal Schumacher


+1

Am 16.03.2018 um 16:35 schrieb Rob Tompkins:

Hello all,

This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).

Tag name:
commons-text-1.3-RC1 (signature can be checked from git using 'git tag
-v')

Tag URL:

https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358

Commit ID the tag points at:
 4ac48357180c9222f032dd8b055d90e1192e4a47

Site Zip:
https://dist.apache.org/repos/dist/dev/commons/text/site.zip

Distribution files (committed at revision 25771):
https://dist.apache.org/repos/dist/dev/commons/text/

Distribution files hashes (SHA1):
commons-text-1.3-bin.tar.gz
(SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
commons-text-1.3-bin.zip
(SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
commons-text-1.3-src.tar.gz
(SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
commons-text-1.3-src.zip
(SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)

These are the Maven artifacts and their hashes:
commons-text-1.3-javadoc.jar
(SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
commons-text-1.3-sources.jar
(SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
commons-text-1.3-test-sources.jar
(SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
commons-text-1.3-tests.jar
(SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
commons-text-1.3.jar
(SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
commons-text-1.3.pom
(SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)

KEYS file to check signatures:
http://www.apache.org/dist/commons/KEYS

Maven artifacts:
https://repository.apache.org/content/repositories/orgapachecommons-1319

Please select one of the following options[1]:
   [ ] +1 Release it.
   [ ] +0 Go ahead; I don't care.
   [ ] -0 There are a few minor glitches: ...
   [ ] -1 No, do not release it because ...

This vote will be open at least 72 hours, i.e. until
2018-03-19T16:00:00Z
(this is UTC time).


Cheers,
-Rob

[1] http://apache.org/foundation/voting.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: [DISCUSS] new component for timing?

2018-03-20 Thread Bruno P. Kinoshita

Not sure. I'm not familiar with sirona/commons-monitoring.
Sirona seems to already have a StopWatch, and looks like there's some users 
already? No strong opinion here, so happy with either of these.

  From: Otto Fowler 
 To: Romain Manni-Bucau ; Bruno P. Kinoshita 
; Commons Developers List 

 Sent: Wednesday, 21 March 2018 11:00 AM
 Subject: Re: [DISCUSS] new component for timing?

If monitoring was started a new, and not re-viving the old monitoring?

On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the same
component. However, a circuit breaker can be time-related, or not (e.g. a
circuit breaker for memory size). So probably commons-timing could be a
good place for StopWatch, but maybe not for circuit-breaker. But I think
both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers List <
dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?

On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
 work ( although I’ll need help of course ).
 I guess I’m the straw that broke the camel’s back then? ;)

 On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
 wrote:

 Hi.

 On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
 > I think bringing back commons-monitoring/sirota would only be
 > possible if
 > it were to be modular enough that you could bring in the ‘core’
 > classes
 > without needing to bring in all of what sirota ended up being, which
 > was an
 > end to end solution.

 Isn't it possible? [I didn't look; Romain should tell whether he
 would be interested in taking that route.]

 Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
 > however,
 > but I would like to think that there would be more impetus

 I'm afraid that it's rather the

Re: [VFS] FILE_OR_FOLDER breaking tests

2018-03-20 Thread Gary Gregory

You need someone from cold storage! ;-)

Gary

On Tue, Mar 20, 2018 at 3:53 PM, Otto Fowler 
wrote:

> Anybody from VFS-past around?
>
>
> On March 8, 2018 at 23:55:54, Gary Gregory (garydgreg...@gmail.com) wrote:
>
> On Thu, Mar 8, 2018 at 8:54 AM, Otto Fowler 
> wrote:
>
> > FILE_OR_FOLDER just doesn’t seem to be supported in the system
> completely.
> > Does anyone remember when it came about and why?
> >
>
> Good question. I hope someone will pipe in.
>
> Gary
>
>
> >
> >
> > On March 7, 2018 at 17:41:56, Otto Fowler (ottobackwa...@gmail.com)
> wrote:
> >
> > FileType normalisePath
> >
> > In UriParser is an issue as well, trying to derive a FOLDER or FILE by
> the
> > name doesn’t work if the system is FILE_OR_FOLDER….
> >
> >
> > On March 6, 2018 at 15:17:50, Otto Fowler (ottobackwa...@gmail.com)
> wrote:
> >
> > protected void addBaseTests() throws Exception {
> > addTests(ProviderCacheStrategyTests.class);
> > addTests(UriTests.class);
> > addTests(NamingTests.class);
> > // --> file or folder rework addTests(ContentTests.class);
> > // --> file or folder rework addTests(ProviderReadTests.class);
> > addTests(ProviderWriteTests.class);
> > addTests(ProviderWriteAppendTests.class);
> > addTests(ProviderRandomReadTests.class);
> > addTests(ProviderRandomReadWriteTests.class);
> > addTests(ProviderRandomSetLengthTests.class);
> > addTests(ProviderRenameTests.class);
> > addTests(ProviderDeleteTests.class);
> > addTests(LastModifiedTests.class);
> > addTests(UrlTests.class);
> > // -> file or folder rework addTests(UrlStructureTests.class);
> > }
> >
> >
> > These are the tests that I have run. They are the standard set minus the
> > classloader.
> > All the tests pass, other than the commented out tests, because these
> tests
> > explicitly check for File or Folder,
> > that you cannot write or read data from a folder etc.
> >
> > I’m playing around with a Zookeeper FS. I haven’t posted it to my github
> > yet, but I will if you want to look. So, with zookeeper you have nodes
> and
> > paths etc.
> > each node may have children and may have data. So FILE_OR_FOLDER is the
> > correct designation.
> >
> >
> > RE : Resource and URL -> Only the MIME provider returns FILE_OR_FOLDER,
> the
> > others either delegate to the canonical type, or are FILE or IMAGINARY.
> So
> > I don’t
> > think they count.
> > An the MIME provider has NO tests…. so yeah.
> >
> >
> > On March 6, 2018 at 14:25:46, Bernd Eckenfels (e...@zusammenkunft.net)
> > wrote:
> >
> > Those tests should be behind a capability for sure, but I thought they
> are
> > already (as the resource and URL fikesystem already passes the tests).
> >
> > What filesystem do you have in mind and what are examples of failing
> > testcases? I think I had fixed a few for WebDav back in the days.
> >
> > Gruss
> > Bernd
> >
> > Von: Otto Fowler
> > Gesendet: Dienstag, 6. März 2018 13:41
> > An: Commons Developers List
> > Betreff: [VFS] FILE_OR_FOLDER breaking tests
> >
> > If you have a filesystem, where everything could be a FILE_OR_FOLDER
> type (
> > or VIRTUAL until attached ), then it seems like you need to replace some
> of
> > the testcases in the
> > provider suites, since they assume or check for FILE and FOLDER
> explicitly.
> >
> > I guess my question is, are the tests as they are wrong and need to be
> > refactored or do we actually need alternate tests for content etc where
> we
> > check?
> >
>
>

Re: [DISCUSS] new component for timing?

2018-03-20 Thread Otto Fowler

If monitoring was started a new, and not re-viving the old monitoring?

On March 20, 2018 at 17:56:44, Bruno P. Kinoshita (
brunodepau...@yahoo.com.br.invalid) wrote:

I think StopWatch and CircuitBreakers could be moved together to the same
component. However, a circuit breaker can be time-related, or not (e.g. a
circuit breaker for memory size). So probably commons-timing could be a
good place for StopWatch, but maybe not for circuit-breaker. But I think
both could be under commons-monitoring perhaps?

From: Otto Fowler 
To: Romain Manni-Bucau ; Commons Developers List <
dev@commons.apache.org>
Sent: Wednesday, 21 March 2018 10:30 AM
Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?

On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
 work ( although I’ll need help of course ).
 I guess I’m the straw that broke the camel’s back then? ;)

 On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
 wrote:

 Hi.

 On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
 > I think bringing back commons-monitoring/sirota would only be
 > possible if
 > it were to be modular enough that you could bring in the ‘core’
 > classes
 > without needing to bring in all of what sirota ended up being, which
 > was an
 > end to end solution.

 Isn't it possible? [I didn't look; Romain should tell whether he
 would be interested in taking that route.]

 Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
 > however,
 > but I would like to think that there would be more impetus

 I'm afraid that it's rather the lack of manpower.
 [And my inner conviction is that that state of things often
 led to rush to cramming more code into existing components,
 rather than "distribute" more uniformly according to subject
 matters. When scarce human resources ("community") disappear,
 cruft accumulates, sometimes up to stifle clean-up, maintenance,
 improvement, and even development.]

 > to do this than
 > thinking StackWatch is ‘too big’ for lang.time.

 It isn't any more

Re: [DISCUSS] new component for timing?

2018-03-20 Thread Bruno P. Kinoshita

I think StopWatch and CircuitBreakers could be moved together to the same 
component. However, a circuit breaker can be time-related, or not (e.g. a 
circuit breaker for memory size). So probably commons-timing could be a good 
place for StopWatch, but maybe not for circuit-breaker. But I think both could 
be under commons-monitoring perhaps?

  From: Otto Fowler 
 To: Romain Manni-Bucau ; Commons Developers List 

 Sent: Wednesday, 21 March 2018 10:30 AM
 Subject: Re: [DISCUSS] new component for timing?

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?

On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
 work ( although I’ll need help of course ).
 I guess I’m the straw that broke the camel’s back then? ;)

 On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
 wrote:

 Hi.

 On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
 > I think bringing back commons-monitoring/sirota would only be
 > possible if
 > it were to be modular enough that you could bring in the ‘core’
 > classes
 > without needing to bring in all of what sirota ended up being, which
 > was an
 > end to end solution.

 Isn't it possible? [I didn't look; Romain should tell whether he
 would be interested in taking that route.]

 Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
 > however,
 > but I would like to think that there would be more impetus

 I'm afraid that it's rather the lack of manpower.
 [And my inner conviction is that that state of things often
 led to rush to cramming more code into existing components,
 rather than "distribute" more uniformly according to subject
 matters. When scarce human resources ("community") disappear,
 cruft accumulates, sometimes up to stifle clean-up, maintenance,
 improvement, and even development.]

 > to do this than
 > thinking StackWatch is ‘too big’ for lang.time.

 It isn't any more than many other functionalities that were
 introduced but shouldn't have been.
 Depending on what the "Commons" PMC wants to favour ("code"

Re: [VFS] FILE_OR_FOLDER breaking tests

2018-03-20 Thread Otto Fowler

Anybody from VFS-past around?


On March 8, 2018 at 23:55:54, Gary Gregory (garydgreg...@gmail.com) wrote:

On Thu, Mar 8, 2018 at 8:54 AM, Otto Fowler 
wrote:

> FILE_OR_FOLDER just doesn’t seem to be supported in the system
completely.
> Does anyone remember when it came about and why?
>

Good question. I hope someone will pipe in.

Gary


>
>
> On March 7, 2018 at 17:41:56, Otto Fowler (ottobackwa...@gmail.com)
wrote:
>
> FileType normalisePath
>
> In UriParser is an issue as well, trying to derive a FOLDER or FILE by
the
> name doesn’t work if the system is FILE_OR_FOLDER….
>
>
> On March 6, 2018 at 15:17:50, Otto Fowler (ottobackwa...@gmail.com)
wrote:
>
> protected void addBaseTests() throws Exception {
> addTests(ProviderCacheStrategyTests.class);
> addTests(UriTests.class);
> addTests(NamingTests.class);
> // --> file or folder rework addTests(ContentTests.class);
> // --> file or folder rework addTests(ProviderReadTests.class);
> addTests(ProviderWriteTests.class);
> addTests(ProviderWriteAppendTests.class);
> addTests(ProviderRandomReadTests.class);
> addTests(ProviderRandomReadWriteTests.class);
> addTests(ProviderRandomSetLengthTests.class);
> addTests(ProviderRenameTests.class);
> addTests(ProviderDeleteTests.class);
> addTests(LastModifiedTests.class);
> addTests(UrlTests.class);
> // -> file or folder rework addTests(UrlStructureTests.class);
> }
>
>
> These are the tests that I have run. They are the standard set minus the
> classloader.
> All the tests pass, other than the commented out tests, because these
tests
> explicitly check for File or Folder,
> that you cannot write or read data from a folder etc.
>
> I’m playing around with a Zookeeper FS. I haven’t posted it to my github
> yet, but I will if you want to look. So, with zookeeper you have nodes
and
> paths etc.
> each node may have children and may have data. So FILE_OR_FOLDER is the
> correct designation.
>
>
> RE : Resource and URL -> Only the MIME provider returns FILE_OR_FOLDER,
the
> others either delegate to the canonical type, or are FILE or IMAGINARY.
So
> I don’t
> think they count.
> An the MIME provider has NO tests…. so yeah.
>
>
> On March 6, 2018 at 14:25:46, Bernd Eckenfels (e...@zusammenkunft.net)
> wrote:
>
> Those tests should be behind a capability for sure, but I thought they
are
> already (as the resource and URL fikesystem already passes the tests).
>
> What filesystem do you have in mind and what are examples of failing
> testcases? I think I had fixed a few for WebDav back in the days.
>
> Gruss
> Bernd
>
> Von: Otto Fowler
> Gesendet: Dienstag, 6. März 2018 13:41
> An: Commons Developers List
> Betreff: [VFS] FILE_OR_FOLDER breaking tests
>
> If you have a filesystem, where everything could be a FILE_OR_FOLDER type
(
> or VIRTUAL until attached ), then it seems like you need to replace some
of
> the testcases in the
> provider suites, since they assume or check for FILE and FOLDER
explicitly.
>
> I guess my question is, are the tests as they are wrong and need to be
> refactored or do we actually need alternate tests for content etc where
we
> check?
>

Re: [DISCUSS] new component for timing?

2018-03-20 Thread Otto Fowler

I would love to get this on track.  I apologize if I have made it more
confusing than it needs to be,
I’m trying to be open to all the suggestions.

If we assume that stack watch is worth ‘having’, then the question is where
to put it.
commons-monitoring / sirota seems to me to be a ‘complete’ solution as
opposed to
a set of or collection of like classes.

Setting the community support / project aspect of sirota aside, it seems
strange to put
a separate class into a more complete and uniform system.  Unless there is
some generically
useful set of timing utility classes that could be taken out of sirota to
go into commons-,
along with things identified ( StopWatch?) out of commons lang and possibly
other commons projects.

commons-timing seems reasonable.  Thoughts?

On March 17, 2018 at 11:24:32, Romain Manni-Bucau (rmannibu...@gmail.com)
wrote:

Yes but consequence was a lack of community increase which is a killer for
an incubator project on the long run.

Le 17 mars 2018 15:19, "Gilles"  a écrit :

> On Sat, 17 Mar 2018 12:47:40 +0100, Romain Manni-Bucau wrote:
>
>> Le 17 mars 2018 11:49, "Gilles"  a écrit :
>>
>> On Thu, 15 Mar 2018 15:13:39 +0100, Romain Manni-Bucau wrote:
>>
>> 2018-03-15 14:36 GMT+01:00 Otto Fowler :
>>>
>>> If we can come to consensus on the way forward, I’ll be happy to do the
>>>
 work ( although I’ll need help of course ).
 I guess I’m the straw that broke the camel’s back then? ;)

 On March 15, 2018 at 08:09:45, Gilles (gil...@harfang.homelinux.org)
 wrote:

 Hi.

 On Thu, 15 Mar 2018 03:52:58 -0700, Otto Fowler wrote:
 > I think bringing back commons-monitoring/sirota would only be
 > possible if
 > it were to be modular enough that you could bring in the ‘core’
 > classes
 > without needing to bring in all of what sirota ended up being, which
 > was an
 > end to end solution.

 Isn't it possible? [I didn't look; Romain should tell whether he
 would be interested in taking that route.]

 Sirona was done modular, just the API, the in memory part, etc...
>>> But this kind of impl needs way more just after so not sure it does
worth
>>> splitting it to put it back altogether after.
>>>
>>> What is the rational to try to push a very small part @commons instead
of
>>> creating a community @incubator with an E2E solution? This is what I
fail
>>> to see.
>>> My experience - coming exactly from here - tends to make me think
commons
>>> will not fit very long or will not bring enough value pretty quickly
but
>>> that's just my opinion.
>>>
>>>
>> Not "just" an opinion since you evoke Sirona's precursor as being
>> the kind of component we'd reinstate. Unless we learn
>> 1. why the precursor needed to become TLP, and
>> 2. why the TLP didn't succeed,
>> we'd go in circles.
>>
>>
>> We failed at community@asf and pby communication/promotion levels I
>> think.
>> Other parts were successful (prod etc).
>>
>>
> [It seems that part of your message went missing.]
>
> Lack of marketing skills should not entail failure, especially
> not since communication is a transverse concern.
>
> Gilles
>
> Would it make sense that Sirona becomes (again?) "Commons Monitoring"?
>> Does the "StackWatck" (Otto's contribution that started this discussion)
>> already exist in a Sirona module? If not, can it be done, so that usage
>> is similar to what Otto had in mind?
>>
>> Regards,
>> Gilles
>>
>>
>> commons-monitoring or commons-timing seem to be the correct thing
>>>
 > however,
 > but I would like to think that there would be more impetus

 I'm afraid that it's rather the lack of manpower.
 [And my inner conviction is that that state of things often
 led to rush to cramming more code into existing components,
 rather than "distribute" more uniformly according to subject
 matters. When scarce human resources ("community") disappear,
 cruft accumulates, sometimes up to stifle clean-up, maintenance,
 improvement, and even development.]

 > to do this than
 > thinking StackWatch is ‘too big’ for lang.time.

 It isn't any more than many other functionalities that were
 introduced but shouldn't have been.
 Depending on what the "Commons" PMC wants to favour ("code"
 *or* "community"?), the choice is between continuing with the
 accumulation, or back-pedaling through the creation of as
 many *real* components as they are developers willing to
 maintain them.

 > It really isn’t that complicated a thing.

 Sure.
 The issue is somewhere else.
 Note that, personally, I hadn't imagined that there would
 be an issue for regular developers of [Lang] (or I wouldn't
 have spent time reviewing the "details" ;-).
 But I of course agree that the question should be asked; the
 more so that, with [Math], we've

Re: [VOTE] Release Commons Text 1.3 based on RC1

2018-03-20 Thread Oliver Heger

Build works fine with Java 1.7 and 1.8. Artifacts and site look good.

So +1.

Minor nit: The site has a japicmp report which is just an empty page.

Oliver

Am 16.03.2018 um 16:35 schrieb Rob Tompkins:
> Hello all,
> 
> This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).
> 
> Tag name:
>commons-text-1.3-RC1 (signature can be checked from git using 'git tag
> -v')
> 
> Tag URL:
>
> https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358
> 
> Commit ID the tag points at:
> 4ac48357180c9222f032dd8b055d90e1192e4a47
> 
> Site Zip:
>https://dist.apache.org/repos/dist/dev/commons/text/site.zip
> 
> Distribution files (committed at revision 25771):
>https://dist.apache.org/repos/dist/dev/commons/text/
> 
> Distribution files hashes (SHA1):
>commons-text-1.3-bin.tar.gz
>(SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
>commons-text-1.3-bin.zip
>(SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
>commons-text-1.3-src.tar.gz
>(SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
>commons-text-1.3-src.zip
>(SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)
> 
> These are the Maven artifacts and their hashes:
>commons-text-1.3-javadoc.jar
>(SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
>commons-text-1.3-sources.jar
>(SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
>commons-text-1.3-test-sources.jar
>(SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
>commons-text-1.3-tests.jar
>(SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
>commons-text-1.3.jar
>(SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
>commons-text-1.3.pom
>(SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)
> 
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>https://repository.apache.org/content/repositories/orgapachecommons-1319
> 
> Please select one of the following options[1]:
>   [ ] +1 Release it.
>   [ ] +0 Go ahead; I don't care.
>   [ ] -0 There are a few minor glitches: ...
>   [ ] -1 No, do not release it because ...
> 
> This vote will be open at least 72 hours, i.e. until 
> 2018-03-19T16:00:00Z
> (this is UTC time).
> 
> 
> Cheers,
> -Rob
> 
> [1] http://apache.org/foundation/voting.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: [VOTE] Release Commons Text 1.3 based on RC1

2018-03-20 Thread Gary Gregory

Hi,

Thank you for preparing this RC.

+1

from src zip: ASC, MD5, SHA1 OK.

Apache RAT check OK.
CLIRR check OK.

'mvn clean verify site' OK

Using:

Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297;
2018-02-24T12:49:05-07:00)
Maven home: C:\Java\apache-maven-3.5.3
Java version: 1.8.0_162, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_162\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

Reports look good.

Gary

On Fri, Mar 16, 2018 at 9:35 AM, Rob Tompkins  wrote:

> Hello all,
>
> This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).
>
> Tag name:
>commons-text-1.3-RC1 (signature can be checked from git using 'git tag
> -v')
>
> Tag URL:
>https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=
> 6e7a377e76bc7e34c286b5c5ee0433f00dc0d358
>
> Commit ID the tag points at:
> 4ac48357180c9222f032dd8b055d90e1192e4a47
>
> Site Zip:
>https://dist.apache.org/repos/dist/dev/commons/text/site.zip
>
> Distribution files (committed at revision 25771):
>https://dist.apache.org/repos/dist/dev/commons/text/
>
> Distribution files hashes (SHA1):
>commons-text-1.3-bin.tar.gz
>(SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
>commons-text-1.3-bin.zip
>(SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
>commons-text-1.3-src.tar.gz
>(SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
>commons-text-1.3-src.zip
>(SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)
>
> These are the Maven artifacts and their hashes:
>commons-text-1.3-javadoc.jar
>(SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
>commons-text-1.3-sources.jar
>(SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
>commons-text-1.3-test-sources.jar
>(SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
>commons-text-1.3-tests.jar
>(SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
>commons-text-1.3.jar
>(SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
>commons-text-1.3.pom
>(SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)
>
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>https://repository.apache.org/content/repositories/
> orgapachecommons-1319
>
> Please select one of the following options[1]:
>   [ ] +1 Release it.
>   [ ] +0 Go ahead; I don't care.
>   [ ] -0 There are a few minor glitches: ...
>   [ ] -1 No, do not release it because ...
>
> This vote will be open at least 72 hours, i.e. until
> 2018-03-19T16:00:00Z
> (this is UTC time).
> 
>
> Cheers,
> -Rob
>
> [1] http://apache.org/foundation/voting.html
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Commons Text 1.3 based on RC1

2018-03-20 Thread Gary Gregory

I've been down with the flu and just coming out of it noticed this VOTE
thread. I will review today. I encourage others to do the same.

Gary

On Fri, Mar 16, 2018 at 9:35 AM, Rob Tompkins  wrote:

> Hello all,
>
> This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).
>
> Tag name:
>commons-text-1.3-RC1 (signature can be checked from git using 'git tag
> -v')
>
> Tag URL:
>https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=
> 6e7a377e76bc7e34c286b5c5ee0433f00dc0d358
>
> Commit ID the tag points at:
> 4ac48357180c9222f032dd8b055d90e1192e4a47
>
> Site Zip:
>https://dist.apache.org/repos/dist/dev/commons/text/site.zip
>
> Distribution files (committed at revision 25771):
>https://dist.apache.org/repos/dist/dev/commons/text/
>
> Distribution files hashes (SHA1):
>commons-text-1.3-bin.tar.gz
>(SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
>commons-text-1.3-bin.zip
>(SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
>commons-text-1.3-src.tar.gz
>(SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
>commons-text-1.3-src.zip
>(SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)
>
> These are the Maven artifacts and their hashes:
>commons-text-1.3-javadoc.jar
>(SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
>commons-text-1.3-sources.jar
>(SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
>commons-text-1.3-test-sources.jar
>(SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
>commons-text-1.3-tests.jar
>(SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
>commons-text-1.3.jar
>(SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
>commons-text-1.3.pom
>(SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)
>
> KEYS file to check signatures:
>http://www.apache.org/dist/commons/KEYS
>
> Maven artifacts:
>https://repository.apache.org/content/repositories/
> orgapachecommons-1319
>
> Please select one of the following options[1]:
>   [ ] +1 Release it.
>   [ ] +0 Go ahead; I don't care.
>   [ ] -0 There are a few minor glitches: ...
>   [ ] -1 No, do not release it because ...
>
> This vote will be open at least 72 hours, i.e. until
> 2018-03-19T16:00:00Z
> (this is UTC time).
> 
>
> Cheers,
> -Rob
>
> [1] http://apache.org/foundation/voting.html
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ANNOUNCE] Commons Parent 45 released.

2018-03-20 Thread Gary Gregory

Thanks Rob!

Gary

On Thu, Mar 15, 2018 at 12:58 PM, Rob Tompkins  wrote:

> [This announcement is only going to the dev list.]
>
> Hello All,
>
> Commons Parent 45 has been released.
>
> The change from release 44 is:
>
> - Rearranging plugin order in -Prelease, removing
> commons-release-plugin from build>pluginManagement
>
> The changes from release 43 are:
>
> - new profile module-name to add 'Automatic-Module-Name' entry to the
> manifest
> - felix:maven-bundle-plugin 3.4.0 -> 3.5.0.
> - build artifacts -test.jar, -sources.jar and -test-sources.jar
> always, not
> only at release time
> - maven-enforcer-plugin set version to 3.0.0-M1 and update Maven
> requirement
> from 3.0.0 to 3.0.5 (the latest 3.0.x.)
> - jacoco-maven-plugin 0.7.9 -> 0.8.0.
> - Fix japicmp config: add to reporting section and define
> ignoreMissingNewVersion explicitly
> - org.apache:apache 18 -> 19
> - add commons-release-plugin:1.1
> - add spotbugs-maven-plugin: 3.1.3
> - maven-surefire-plugin 2.20.1 -> 2.21.0
> - maven-failsafe-plugin 2.20.1 -> 2.21.0
>
> Note, the inclusion of the release plugin, means that (for a non multi
> module
> build), you will want to add the following two properties to your pom:
>
> commons.release.isDistModule=true
> commons.distSvnStagingUrl=https://dist.apache.org/repos/
> dist/dev/commons/foo
>  (for component foo).
>
> Then for a release when you build, you run:
>
> mvn -Duser.name= -Prelease -Ptest-deploy clean
> test site
> deploy
>
> for a test deployment, and:
>
> mvn -Duser.name= -Prelease clean test site deploy
>
> for an actual deployment. To see the artifacts being staged properly, look
> under
> “./target/commons-release-plugin/scm” as that is what should end up
> checked into
> the dev distribution location.
> 
> Note, also that I plan to add the above notes, with more detail to the
> preparing
> a release page, and the commons-parent page on the main site. I simply
> wanted to
> give directions if anyone was particularly anxious to use the plugin/parent
> immediately.
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [report] Draft board report

2018-03-20 Thread Gary Gregory

Our report has been submitted.

Gary

On Mon, Mar 19, 2018 at 6:53 PM, Gary Gregory 
wrote:

> Thank you for the review Rob.
>
> Gary
>
> On Mon, Mar 19, 2018, 14:15 Rob Tompkins  wrote:
>
>> Looks reasonable from a quick read.
>>
>> -Rob
>>
>> > On Mar 19, 2018, at 1:34 PM, Gary Gregory 
>> wrote:
>> >
>> > Hi All:
>> >
>> > I've been ill with the flu since Wednesday so this is report is almost
>> > late. Your feedback is appreciated. I will submit it in a couple of
>> hours.
>> > Sorry about the late notice
>> >
>> > Gary
>> >
>> > ## Description:
>> > - The Apache Commons project focuses on all aspects of reusable Java
>> > components.
>> >
>> > - The Apache Commons components are widely used in many projects, both
>> > within
>> >  Apache and without. Any ASF committer can commit to Apache Commons.
>> >
>> > - The last report was for the meeting of December 20, 2017.
>> >
>> > ## Issues:
>> > - There are no issues requiring board attention at this time.
>> >
>> > ## Activity:
>> > - The project is active with nine (9) releases this reporting period.
>> >
>> > ## Health report:
>> > - Most components in Commons are mature, but are still actively
>> maintained
>> >   (9 releases). The dev list is active. JIRA is active. Speed of
>> responses
>> >   to users is reasonable in most cases. We have no new PMC members, no
>> new
>> >   committers, and Commons is still open to any Apache Committer.
>> > - Previous growing pains toward Commons Math 4 might see resolution
>> with a
>> >   plan toward splitting off Commons Math into new components like
>> Commons
>> > Numbers.
>> >
>> > ## PMC changes:
>> >
>> > - Currently 38 PMC members.
>> > - No new PMC members added in the last 3 months
>> > - Last PMC addition was Rob Tompkins on Fri Jun 30 2017
>> >
>> > ## Committer base changes:
>> >
>> > - Currently 146 committers.
>> > - No new committers added in the last 3 months
>> > - Last committer addition was Sergio Fernández at Sat Nov 04 2017
>> >
>> > ## Releases:
>> >
>> > - COMPRESS-1.16 was released on Sun Feb 04 2018
>> > - COMPRESS-1.16.1 was released on Fri Feb 09 2018
>> > - DBCP-2.2.0 was released on Sun Dec 24 2017
>> > - PARENT-43 was released on Fri Jan 05 2018
>> > - PARENT-44 was released on Sat Mar 10 2018
>> > - PARENT-45 was released on Wed Mar 14 2018
>> > - RDF-0.5.0 was released on Fri Dec 22 2017
>> > - RELEASEPLUGIN-1.1 was released on Sun Mar 04 2018
>> > - release-plugin-1.0 was released on Tue Jan 16 2018
>> >
>> > ## JIRA activity:
>> >
>> > - 216 JIRA tickets created in the last 3 months
>> > - 165 JIRA tickets closed/resolved in the last 3 months
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>

Re: [Statistics] Port codes from Commons Math

2018-03-20 Thread Gimhana Nadeeshan

Hello devs,

I have updated my draft proposal with @Gilles's suggestions[Draft Proposal
V1.1
]
and I think I need some more clarifications on below suggestions


> == "Background" section ==
>

>
number of listed/active contributors
> histogram of component's sizes (lines of code)


How to recognize "active contributors" ? In the ML or GitHub ? What do you
mean by "histogram of component's sizes (lines of code)" ?


== "Deliverables" section ==
>
>  * less dependencies" (an example?)
>  * "Advanced mathematical functionalities": other than what
>exists now?  Or do you mean new interfaces (e.g. in
>accordance with the APIs provided by JDK8)?
>

Most of the classes in "math4.stat" contains "math4.exception" classes. And
some classes in "correlations module" dependent to "RealMatix" interfaces.
Can those be considered as dependencies ? Can't exceptions be substituted
with inbuilt java exceptions ? @Gilles would you please explain this matrix
issue because I didn't get it much


> == "Implementation" section ==

* "Design goals": give concrete examples.


I noted some examples for Design Goals in my proposal.  But I'm not sure I
that I wrote it correctly. (And don't know those are the examples you
expect me to mention.) Please clarify those too.

== "Results" section ==
>
> Hope to get comment from PMC...
> [Wish list, design requirements, mentor(s), etc.]
>

mentor(s)?? @Gilles,@Eric wont't you guys be the mentors of this project ??
I'm asking this because I'm new to ASF and GSoC !! And I'm appreciate to
know how this is working !!

In the meantime, you could also review the open issues for "Commons
> Numbers":
>   https://issues.apache.org/jira/projects/NUMBERS/
>
> This is quite important as almost all other "Commons Math"
> spin-offs will have some dependency on this new component;
> hence a release of "Commons Numbers" must precede a release
> of either "Commons Statistics" or "Commons Geometry".
>

Yep Wow sure...I'm on my way right now CM Numbers!!


Nadeeshan Gimhana

Batch Representative (15' batch)

Department of Computer Science & Engineering

University of Moratuwa

*Mobile :+94775744613*


*Website : https://ngimhana94.wixsite.com/gimhanadesilva/
*

*L**inkedin **:www.linkedin.com/in/nadeeshangimhana/
*


* *


* *



On 19 March 2018 at 03:46, Gilles  wrote:

> Hello.
>
> On Sun, 18 Mar 2018 23:29:44 +0530, Gimhana Nadeeshan wrote:
>
>> Hi ,
>>
>> Thanks a lot Gilles for your valuable suggestions and give the reviews so
>> quickly. I'll apply those corrections asked for any clarifications in
>> here.
>> By the way since I'm new to Apache Community I'm not yet familiar with
>> some
>> abbreviations used in the list. [such as ML archive, PMC ]
>>
>
> Sorry!
> ML = Mailing List
> PMC = Project Management Committee
>
>
>> AFAICT, porting "o.a.c.math4.geometry" will be much
>>
>>> easier and likely to be finished before "Commons
>>> Statistics". :-}
>>>
>>>
>> Since the design structure is the same, this would be interesting and
>> easier. But is it allowed in GSoC? [Since it not labeled as GSoC idea at
>> JIRA !!]
>>
>
> If it's just a matter of creating a GSoC task, not a big problem. ;-)
> For would-be "Commons Geometry", I'm waiting for the green light
> from our expert contributor, Matt Juntunen.
> In the meantime, you could also review the open issues for "Commons
> Numbers":
>   https://issues.apache.org/jira/projects/NUMBERS/
>
> This is quite important as almost all other "Commons Math"
> spin-offs will have some dependency on this new component;
> hence a release of "Commons Numbers" must precede a release
> of either "Commons Statistics" or "Commons Geometry".
>
> Best,
> Gilles
>
> Best Regards,
>> Gimhana.
>>
>> [...]

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

[RESULT][VOTE] Release Commons Text 1.3 based on RC1

Re: [VOTE] Release Commons Text 1.3 based on RC1

Re: [ANNOUNCE] Commons Parent 45 released.

Re: [DISCUSS] new component for timing?

Re: [DISCUSS] new component for timing?

Re: [DISCUSS] new component for timing?

Re: [DISCUSS] new component for timing?

Re: [VOTE] Release Commons Text 1.3 based on RC1

Re: [DISCUSS] new component for timing?

Re: [VFS] FILE_OR_FOLDER breaking tests

Re: [DISCUSS] new component for timing?

Re: [DISCUSS] new component for timing?

Re: [VFS] FILE_OR_FOLDER breaking tests

Re: [DISCUSS] new component for timing?

Re: [VOTE] Release Commons Text 1.3 based on RC1

Re: [VOTE] Release Commons Text 1.3 based on RC1

Re: [VOTE] Release Commons Text 1.3 based on RC1

Re: [ANNOUNCE] Commons Parent 45 released.

Re: [report] Draft board report

Re: [Statistics] Port codes from Commons Math

20 matches

Site Navigation

Mail list logo

Footer information