Re: [lang] Todo utility class

[Gilles]

Hi.

On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
I have often thought about creating a utility class that allows me to 
write
skeletal code that still compiles but will remind me to go back and 
finish
it. This is a weird meta area of programming, but here are some basic 
usage

examples:

Foo foo = Todo.todo(); //returns null
Bar bar = Todo.todo(THROWING_EXCEPTION); //throws 
NotImplementedException
Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null 
and

prints a message to System.err

I would also think it a good (if odd) idea to make the whole class
deprecated so that its use is flagged in tools, etc.

Does the community think this code would be suited to the 
commons-lang

component?


Perhaps "Commons Testing".
IIUC, such calls are not meant to appear in released code.

Regards,
Gilles



Matt



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

Re: Github usage

[Gilles]

Thanks for all the suggestions.
I see that there are things to try before bothering INFRA. ;-)

Regards,
Gilles

On Thu, 15 Mar 2018 14:03:35 -0400, Otto Fowler wrote:


https://github.com/apache/metron/tree/master/dev-utilities/committer-utils
if you just want the bash


On March 15, 2018 at 13:51:00, ajs6f (aj...@apache.org) wrote:

One gotcha that has bit me before-- if the PR isn't rebased over the
current master (assuming you are merging into master) it may still be
merge-able because maybe there aren't any conflicts. (E.g. maybe no 
one has
worked on that section of the codebase since the PR's branch was 
branched.)


But if you merge without rebasing, Apache's mirroring won't realize 
that
the PR should be closed (as I understand it, because the commits will 
have

different hashes since they are diffs between different places on the
tree). So best to rebase if needed, but you forget and this happens 
to you,

you can still rebase and force-push the PR branch, and then Apache's
mirroring will catch up and close the PR "posthumously". Or of course 
you

can always close it manually on Github.

I make this mistake about once a month or so. :(

ajs6f


On Mar 14, 2018, at 12:27 PM, Matt Sicker  wrote:

When you have a GitHub origin, you can checkout pulls/42/head to 
check

out
PR#42. You can pull/merge from that branch as well to merge the PR 
(by
committing and pushing that merge, GitHub will notice and mark the 
PR as

merged). You can also use the "hub" command line tool that GitHub

publishes

which adds a bunch of convenience commands to do the same thing.

On 14 March 2018 at 10:19, Gilles  
wrote:



Hi.

On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:


I should be more specific, this is for looking at github pr’s.
So if your submitters are forking, submitting prs on github.

We also have scripts for committing, but we are doing git -> 
github

mirror




My knowledge of "git" is small; my knowledge of GitHub smaller
(and zero for functionalities that require being logged in). :-}

Assuming a "git" repository (where "origin" is on an Apache server)
with a local "clone" (i.e. on my machine), is it possible to create
a branch, say "gimo_work", such that

$ git checkout gimo_work
$ git ... ? ... (equivalent to "pull" wrt "origin")

will retrieve the latest Gimo's commits on the fork made
from the Apache repository?

Gilles

On March 14, 2018 at 10:15:04, Otto Fowler 
(ottobackwa...@gmail.com)

wrote:

We have script to help reviewers checkout PR’s in git, either in 
their

own

repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:

checkout-pr 999




in the tmp directory, and end up with a local version that I can 
then

build
and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles 
(gil...@harfang.homelinux.org)

wrote:

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

On Mar 13, 2018, at 11:20 AM, Gilles 


wrote:


I didn't find it very easy to cooperate with developers who fork 
on
GitHub and submit PRs. I've now found the "git" command that 
creates

a
branch from a PR, but it would be so much more comfortable to 
just

switch directory and do "git pull".


Just as a point of information, it is possible to reverse the 
Github

<- Apache mirroring most projects use to be Github -> Apache.



It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC 
participant.


Does it make sense?

Thanks,
Gilles

What
that means is that merging PRs from Github becomes one click in 
the

Github UI.

There are other consequences, of course, especially related to 
other
integrations Commons may be using (e.g. integration between 
Github

and
JIRA).

Of course, INFRA are the folks to talk to if this sounds 
interesting.
At Apache Jena, we looked into it but have taken no action 
because we

still have some open questions about when some of our workflow
integrations will become possible with "reversed mirroring".

Adam Soroka ; aj...@apache.org



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

[ANNOUNCE] Commons Parent 45 released.

[Rob Tompkins]

[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: Github usage

[Otto Fowler]

https://github.com/apache/metron/tree/master/dev-utilities/committer-utils
if you just want the bash


On March 15, 2018 at 13:51:00, ajs6f (aj...@apache.org) wrote:

One gotcha that has bit me before-- if the PR isn't rebased over the
current master (assuming you are merging into master) it may still be
merge-able because maybe there aren't any conflicts. (E.g. maybe no one has
worked on that section of the codebase since the PR's branch was branched.)

But if you merge without rebasing, Apache's mirroring won't realize that
the PR should be closed (as I understand it, because the commits will have
different hashes since they are diffs between different places on the
tree). So best to rebase if needed, but you forget and this happens to you,
you can still rebase and force-push the PR branch, and then Apache's
mirroring will catch up and close the PR "posthumously". Or of course you
can always close it manually on Github.

I make this mistake about once a month or so. :(

ajs6f

> On Mar 14, 2018, at 12:27 PM, Matt Sicker  wrote:
>
> When you have a GitHub origin, you can checkout pulls/42/head to check
out
> PR#42. You can pull/merge from that branch as well to merge the PR (by
> committing and pushing that merge, GitHub will notice and mark the PR as
> merged). You can also use the "hub" command line tool that GitHub
publishes
> which adds a bunch of convenience commands to do the same thing.
>
> On 14 March 2018 at 10:19, Gilles  wrote:
>
>> Hi.
>>
>> On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:
>>
>>> I should be more specific, this is for looking at github pr’s.
>>> So if your submitters are forking, submitting prs on github.
>>>
>>> We also have scripts for committing, but we are doing git -> github
mirror
>>>
>>
>> My knowledge of "git" is small; my knowledge of GitHub smaller
>> (and zero for functionalities that require being logged in). :-}
>>
>> Assuming a "git" repository (where "origin" is on an Apache server)
>> with a local "clone" (i.e. on my machine), is it possible to create
>> a branch, say "gimo_work", such that
>>
>> $ git checkout gimo_work
>> $ git ... ? ... (equivalent to "pull" wrt "origin")
>>
>> will retrieve the latest Gimo's commits on the fork made
>> from the Apache repository?
>>
>> Gilles
>>
>> On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com)
>>> wrote:
>>>
>>> We have script to help reviewers checkout PR’s in git, either in their
own
>>> repo
>>> or just doing it in ~/tmp or something into a new repo.
>>>
>>> So, I would run:
>>>
>>> checkout-pr 999

>>>
>>> in the tmp directory, and end up with a local version that I can then
>>> build
>>> and do whatever with.
>>> would that help?
>>>
>>>
>>> On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org)
>>> wrote:
>>>
>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>>
 On Mar 13, 2018, at 11:20 AM, Gilles 
> wrote:
>
>
> I didn't find it very easy to cooperate with developers who fork on
> GitHub and submit PRs. I've now found the "git" command that creates
a
> branch from a PR, but it would be so much more comfortable to just
> switch directory and do "git pull".
>
>
 Just as a point of information, it is possible to reverse the Github
 <- Apache mirroring most projects use to be Github -> Apache.

>>>
>>> It seems that a good-enough-for-me solution would be to "clone"
>>> (on my local system) the repository forked by the GSoC participant.
>>>
>>> Does it make sense?
>>>
>>> Thanks,
>>> Gilles
>>>
>>> What
 that means is that merging PRs from Github becomes one click in the
 Github UI.

 There are other consequences, of course, especially related to other
 integrations Commons may be using (e.g. integration between Github
 and
 JIRA).

 Of course, INFRA are the folks to talk to if this sounds interesting.
 At Apache Jena, we looked into it but have taken no action because we
 still have some open questions about when some of our workflow
 integrations will become possible with "reversed mirroring".

 Adam Soroka ; aj...@apache.org

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


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

Re: Github usage

[ajs6f]

One gotcha that has bit me before-- if the PR isn't rebased over the current 
master (assuming you are merging into master) it may still be merge-able 
because maybe there aren't any conflicts. (E.g. maybe no one has worked on that 
section of the codebase since the PR's branch was branched.)

But if you merge without rebasing, Apache's mirroring won't realize that the PR 
should be closed (as I understand it, because the commits will have different 
hashes since they are diffs between different places on the tree). So best to 
rebase if needed, but you forget and this happens to you, you can still rebase 
and force-push the PR branch, and then Apache's mirroring will catch up and 
close the PR "posthumously". Or of course you can always close it manually on 
Github.

I make this mistake about once a month or so. :(

ajs6f

> On Mar 14, 2018, at 12:27 PM, Matt Sicker  wrote:
> 
> When you have a GitHub origin, you can checkout pulls/42/head to check out
> PR#42. You can pull/merge from that branch as well to merge the PR (by
> committing and pushing that merge, GitHub will notice and mark the PR as
> merged). You can also use the "hub" command line tool that GitHub publishes
> which adds a bunch of convenience commands to do the same thing.
> 
> On 14 March 2018 at 10:19, Gilles  wrote:
> 
>> Hi.
>> 
>> On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:
>> 
>>> I should be more specific, this is for looking at github pr’s.
>>> So if your submitters are forking, submitting prs on github.
>>> 
>>> We also have scripts for committing, but we are doing git -> github mirror
>>> 
>> 
>> My knowledge of "git" is small; my knowledge of GitHub smaller
>> (and zero for functionalities that require being logged in). :-}
>> 
>> Assuming a "git" repository (where "origin" is on an Apache server)
>> with a local "clone" (i.e. on my machine), is it possible to create
>> a branch, say "gimo_work", such that
>> 
>> $ git checkout gimo_work
>> $ git ... ? ... (equivalent to "pull" wrt "origin")
>> 
>> will retrieve the latest Gimo's commits on the fork made
>> from the Apache repository?
>> 
>> Gilles
>> 
>> On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com)
>>> wrote:
>>> 
>>> We have script to help reviewers checkout PR’s in git, either in their own
>>> repo
>>> or just doing it in ~/tmp or something into a new repo.
>>> 
>>> So, I would run:
>>> 
>>> checkout-pr 999
 
>>> 
>>> in the tmp directory, and end up with a local version that I can then
>>> build
>>> and do whatever with.
>>> would that help?
>>> 
>>> 
>>> On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org)
>>> wrote:
>>> 
>>> On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:
>>> 
 On Mar 13, 2018, at 11:20 AM, Gilles 
> wrote:
> 
> 
> I didn't find it very easy to cooperate with developers who fork on
> GitHub and submit PRs. I've now found the "git" command that creates a
> branch from a PR, but it would be so much more comfortable to just
> switch directory and do "git pull".
> 
> 
 Just as a point of information, it is possible to reverse the Github
 <- Apache mirroring most projects use to be Github -> Apache.
 
>>> 
>>> It seems that a good-enough-for-me solution would be to "clone"
>>> (on my local system) the repository forked by the GSoC participant.
>>> 
>>> Does it make sense?
>>> 
>>> Thanks,
>>> Gilles
>>> 
>>> What
 that means is that merging PRs from Github becomes one click in the
 Github UI.
 
 There are other consequences, of course, especially related to other
 integrations Commons may be using (e.g. integration between Github
 and
 JIRA).
 
 Of course, INFRA are the folks to talk to if this sounds interesting.
 At Apache Jena, we looked into it but have taken no action because we
 still have some open questions about when some of our workflow
 integrations will become possible with "reversed mirroring".
 
 Adam Soroka ; aj...@apache.org
 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 
> 
> 
> -- 
> Matt Sicker 


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

Re: Github usage

[Matt Sicker]

Oh, I was looking at the wrong version of Debian I think.

On 15 March 2018 at 11:01, Gilles  wrote:

> On Thu, 15 Mar 2018 10:39:50 -0500, Matt Sicker wrote:
>
>> I can't find that package on debian's package search page.
>>
>
> https://packages.debian.org/stretch/git-hub
>
> I'm not sure if
>> they package it there
>>
>
> There is a slew of golang-related packages.
>
> (it's a go program, so it's pretty easy to install if
>> you have go already).
>>
>
> I don't have it installed.
>
> Here's the official site: https://hub.github.com/
>>
>
> If possible, I'd prefer installing it through the distribution.
>
> Regards,
> Gilles
>
> [...]

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


-- 
Matt Sicker 

Re: Github usage

[Gilles]

On Thu, 15 Mar 2018 10:39:50 -0500, Matt Sicker wrote:

I can't find that package on debian's package search page.


https://packages.debian.org/stretch/git-hub


I'm not sure if
they package it there


There is a slew of golang-related packages.


(it's a go program, so it's pretty easy to install if
you have go already).


I don't have it installed.


Here's the official site: https://hub.github.com/


If possible, I'd prefer installing it through the distribution.

Regards,
Gilles


[...]



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

Re: Github usage

[Matt Sicker]

I can't find that package on debian's package search page. I'm not sure if
they package it there (it's a go program, so it's pretty easy to install if
you have go already). Here's the official site: https://hub.github.com/

On 15 March 2018 at 10:19, Gilles  wrote:

> Hi.
>
> On Wed, 14 Mar 2018 11:27:38 -0500, Matt Sicker wrote:
>
>> When you have a GitHub origin, you can checkout pulls/42/head to check out
>> PR#42. You can pull/merge from that branch as well to merge the PR (by
>> committing and pushing that merge, GitHub will notice and mark the PR as
>> merged). You can also use the "hub" command line tool that GitHub
>> publishes
>> which adds a bunch of convenience commands to do the same thing.
>>
>
> Following your hint, I've installed (Debian) a package named
> "git-hub"; assuming this is the tool.
>
> Now, I'll need the link to Gimo's "forked" repository of the
> "Commons Statistics" GitHub mirror...
>
> Regards,
> Gilles
>
>
> On 14 March 2018 at 10:19, Gilles  wrote:
>>
>> Hi.
>>>
>>> On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:
>>>
>>> I should be more specific, this is for looking at github pr’s.
 So if your submitters are forking, submitting prs on github.

 We also have scripts for committing, but we are doing git -> github
 mirror


>>> My knowledge of "git" is small; my knowledge of GitHub smaller
>>> (and zero for functionalities that require being logged in). :-}
>>>
>>> Assuming a "git" repository (where "origin" is on an Apache server)
>>> with a local "clone" (i.e. on my machine), is it possible to create
>>> a branch, say "gimo_work", such that
>>>
>>>  $ git checkout gimo_work
>>>  $ git ... ? ... (equivalent to "pull" wrt "origin")
>>>
>>> will retrieve the latest Gimo's commits on the fork made
>>> from the Apache repository?
>>>
>>> Gilles
>>>
>>> On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com)
>>>
 wrote:

 We have script to help reviewers checkout PR’s in git, either in their
 own
 repo
 or just doing it in ~/tmp or something into a new repo.

 So, I would run:

 checkout-pr 999

>
>
 in the tmp directory, and end up with a local version that I can then
 build
 and do whatever with.
 would that help?


 On March 14, 2018 at 10:08:47, Gilles (gil...@harfang.homelinux.org)
 wrote:

 On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

 On Mar 13, 2018, at 11:20 AM, Gilles 
>
>> wrote:
>>
>>
>> I didn't find it very easy to cooperate with developers who fork on
>> GitHub and submit PRs. I've now found the "git" command that creates a
>> branch from a PR, but it would be so much more comfortable to just
>> switch directory and do "git pull".
>>
>>
>> Just as a point of information, it is possible to reverse the Github
> <- Apache mirroring most projects use to be Github -> Apache.
>
>
 It seems that a good-enough-for-me solution would be to "clone"
 (on my local system) the repository forked by the GSoC participant.

 Does it make sense?

 Thanks,
 Gilles

 What

> that means is that merging PRs from Github becomes one click in the
> Github UI.
>
> There are other consequences, of course, especially related to other
> integrations Commons may be using (e.g. integration between Github
> and
> JIRA).
>
> Of course, INFRA are the folks to talk to if this sounds interesting.
> At Apache Jena, we looked into it but have taken no action because we
> still have some open questions about when some of our workflow
> integrations will become possible with "reversed mirroring".
>
> Adam Soroka ; aj...@apache.org
>
>

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


-- 
Matt Sicker 

Re: Github usage

[Gilles]

Hi.

On Wed, 14 Mar 2018 11:27:38 -0500, Matt Sicker wrote:
When you have a GitHub origin, you can checkout pulls/42/head to 
check out
PR#42. You can pull/merge from that branch as well to merge the PR 
(by
committing and pushing that merge, GitHub will notice and mark the PR 
as
merged). You can also use the "hub" command line tool that GitHub 
publishes

which adds a bunch of convenience commands to do the same thing.


Following your hint, I've installed (Debian) a package named
"git-hub"; assuming this is the tool.

Now, I'll need the link to Gimo's "forked" repository of the
"Commons Statistics" GitHub mirror...

Regards,
Gilles

On 14 March 2018 at 10:19, Gilles  
wrote:



Hi.

On Wed, 14 Mar 2018 14:16:42 +, Otto Fowler wrote:


I should be more specific, this is for looking at github pr’s.
So if your submitters are forking, submitting prs on github.

We also have scripts for committing, but we are doing git -> github 
mirror




My knowledge of "git" is small; my knowledge of GitHub smaller
(and zero for functionalities that require being logged in). :-}

Assuming a "git" repository (where "origin" is on an Apache server)
with a local "clone" (i.e. on my machine), is it possible to create
a branch, say "gimo_work", such that

 $ git checkout gimo_work
 $ git ... ? ... (equivalent to "pull" wrt "origin")

will retrieve the latest Gimo's commits on the fork made
from the Apache repository?

Gilles

On March 14, 2018 at 10:15:04, Otto Fowler (ottobackwa...@gmail.com)

wrote:

We have script to help reviewers checkout PR’s in git, either in 
their own

repo
or just doing it in ~/tmp or something into a new repo.

So, I would run:

checkout-pr 999




in the tmp directory, and end up with a local version that I can 
then

build
and do whatever with.
would that help?


On March 14, 2018 at 10:08:47, Gilles 
(gil...@harfang.homelinux.org)

wrote:

On Tue, 13 Mar 2018 11:43:17 -0400, ajs6f wrote:

On Mar 13, 2018, at 11:20 AM, Gilles 


wrote:


I didn't find it very easy to cooperate with developers who fork 
on
GitHub and submit PRs. I've now found the "git" command that 
creates a
branch from a PR, but it would be so much more comfortable to 
just

switch directory and do "git pull".


Just as a point of information, it is possible to reverse the 
Github

<- Apache mirroring most projects use to be Github -> Apache.



It seems that a good-enough-for-me solution would be to "clone"
(on my local system) the repository forked by the GSoC participant.

Does it make sense?

Thanks,
Gilles

What
that means is that merging PRs from Github becomes one click in 
the

Github UI.

There are other consequences, of course, especially related to 
other

integrations Commons may be using (e.g. integration between Github
and
JIRA).

Of course, INFRA are the folks to talk to if this sounds 
interesting.
At Apache Jena, we looked into it but have taken no action because 
we

still have some open questions about when some of our workflow
integrations will become possible with "reversed mirroring".

Adam Soroka ; aj...@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?

[Romain Manni-Bucau]

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.


>
> > 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 a striking example of what
> awaits a library that lacks boundary checks and explicit
> road map.
>
> Regards,
> Gilles
>
> > On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org)
> > wrote:
> >
> > On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
> >> -1 to "commons-misc". It feels to me like a copout and unfocused
> >> like
> >> SomethingUtils.
> >> We need a proper home.
> >
> > +1
> >
> >> How about the idea of commons-measure.
> >
> > Just because the first feature would happen to be a timer?
> > What other content do you foresee?
> >
> >> Then there
> >> still the idea of resurrecting other Apache projects. Kind of going
> >> in
> >> circles...
> >
> > Indeed, IIRC the questions were asked (whether the feature could
> > be contributed to ex-Sirona and whether that project would be
> > repatriated to "Commons") but not answered (unless I'm mistaken)...
> >
> > Best,
> > Gilles
> >
> >
> >> Gary
> >>
> >> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
> >>
> >> So, could think about commons-misc or something?
> >> I don’t think we are going to come up with a perfect module for
> >> these
> >> things.
> >>
> >> Maybe the way it can work is:
> >>
> >> commons-misc exists.
> >>
> >> It is the landing place for things that seem to be outside the scope
> >> of
> >> commons-, but don’t justify
> >> a new module or sandbox effort.
> >>
> >> Things in misc can be reevaluated for inclusion in new modules at
> >> things
> >> go, and at that point @Depricated
> >> out of misc.
> >>
> >> ?
> >>
> >>
> >>
> >> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:
> >>
> >> On 2 March 2018 at 13:31, Oliver Heger
> >> 
> >> wrote:
> >>>
> >>> One other suggestion: It was stated in the past that the concurrent
> >>> classes are also a bit out of scope for [lang], especially the
> >>> circuit
> >>> breaker implementations. Would it make sense to move those into a
> >>> new
> >>> module, and could this be a home for the watch classes, too?
> >>>
> >>
> >> Considering the amount of retry libraries there are out there, I
> >> think it
> >> makes perfect sense for circuit breaker libraries to be their own
> >> thing,
> >> too. See Hysterix for example.
> >>
> >> --
> >> Matt Sicker 
>
>
> 

[RESULT][LAZY][VOTE] Release Commons Parent 45 based on RC1.

[Rob Tompkins]

This [LAZY][VOTE] passes with the following votes:

Gary Gregory: +1,
Rob Tompkins: +1

I will promote the requisite artifacts.

-Rob

> On Mar 12, 2018, at 8:49 AM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> This is a [LAZY][VOTE] for releasing Apache Commons Parent 45 (from RC1). 
> [Pardon my miss in commons-parent-44-RC3, I am truly sorry for that].
> 
> Note on validation:
>   Please read the 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/RELEASE-NOTES.txt,
>  as
>   there is an erroneous non-failing stack trace that occurs during the build.
> 
> Tag name:
>   commons-parent-45-RC1
> 
> Tag URL:
>   
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-45-RC1/
> 
> Commit ID the tag points at:
>1826542
> 
> Site Zip:
>   https://dist.apache.org/repos/dist/dev/commons/commons-parent/site.zip
> 
> Distribution files (committed at revision 25660):
>   https://dist.apache.org/repos/dist/dev/commons/commons-parent/
> 
> Distribution files hashes (SHA1):
>   commons-parent-45-src.tar.gz
>   (SHA1: a72ab38c3f1b654a753a477071e6d3f9bfc73b50)
>   commons-parent-45-src.zip
>   (SHA1: 343dc5bf8e7d47528bd4b115b6074c7924599f23)
> 
> These are the Maven artifacts and their hashes:
>   commons-parent-45-site.xml
>   (SHA1: 02b3b54d26d97a72fd55b20d027040ca0daf52b7)
>   commons-parent-45.pom
>   (SHA1: 71201c6eea226cd986f03adb1b6ec326dd860786)
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1315
> 
> 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-15T13: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: [LAZY][VOTE] Release Commons Parent 45 based on RC1.

[Rob Tompkins]

Here’s my +1 based upon my doing a dry run for the text release locally.

-Rob

> On Mar 12, 2018, at 8:49 AM, Rob Tompkins  wrote:
> 
> Hello all,
> 
> This is a [LAZY][VOTE] for releasing Apache Commons Parent 45 (from RC1). 
> [Pardon my miss in commons-parent-44-RC3, I am truly sorry for that].
> 
> Note on validation:
>   Please read the 
> https://dist.apache.org/repos/dist/dev/commons/commons-parent/RELEASE-NOTES.txt,
>  as
>   there is an erroneous non-failing stack trace that occurs during the build.
> 
> Tag name:
>   commons-parent-45-RC1
> 
> Tag URL:
>   
> https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-45-RC1/
> 
> Commit ID the tag points at:
>1826542
> 
> Site Zip:
>   https://dist.apache.org/repos/dist/dev/commons/commons-parent/site.zip
> 
> Distribution files (committed at revision 25660):
>   https://dist.apache.org/repos/dist/dev/commons/commons-parent/
> 
> Distribution files hashes (SHA1):
>   commons-parent-45-src.tar.gz
>   (SHA1: a72ab38c3f1b654a753a477071e6d3f9bfc73b50)
>   commons-parent-45-src.zip
>   (SHA1: 343dc5bf8e7d47528bd4b115b6074c7924599f23)
> 
> These are the Maven artifacts and their hashes:
>   commons-parent-45-site.xml
>   (SHA1: 02b3b54d26d97a72fd55b20d027040ca0daf52b7)
>   commons-parent-45.pom
>   (SHA1: 71201c6eea226cd986f03adb1b6ec326dd860786)
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>   https://repository.apache.org/content/repositories/orgapachecommons-1315
> 
> 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-15T13: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: [DISCUSS] new component for timing?

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

> 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 a striking example of what
awaits a library that lacks boundary checks and explicit
road map.

Regards,
Gilles

> On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org)
> wrote:
>
> On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
>> -1 to "commons-misc". It feels to me like a copout and unfocused
>> like
>> SomethingUtils.
>> We need a proper home.
>
> +1
>
>> How about the idea of commons-measure.
>
> Just because the first feature would happen to be a timer?
> What other content do you foresee?
>
>> Then there
>> still the idea of resurrecting other Apache projects. Kind of going
>> in
>> circles...
>
> Indeed, IIRC the questions were asked (whether the feature could
> be contributed to ex-Sirona and whether that project would be
> repatriated to "Commons") but not answered (unless I'm mistaken)...
>
> Best,
> Gilles
>
>
>> Gary
>>
>> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
>>
>> So, could think about commons-misc or something?
>> I don’t think we are going to come up with a perfect module for
>> these
>> things.
>>
>> Maybe the way it can work is:
>>
>> commons-misc exists.
>>
>> It is the landing place for things that seem to be outside the scope
>> of
>> commons-, but don’t justify
>> a new module or sandbox effort.
>>
>> Things in misc can be reevaluated for inclusion in new modules at
>> things
>> go, and at that point @Depricated
>> out of misc.
>>
>> ?
>>
>>
>>
>> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:
>>
>> On 2 March 2018 at 13:31, Oliver Heger
>> 
>> wrote:
>>>
>>> One other suggestion: It was stated in the past that the concurrent
>>> classes are also a bit out of scope for [lang], especially the
>>> circuit
>>> breaker implementations. Would it make sense to move those into a
>>> new
>>> module, and could this be a home for the watch classes, too?
>>>
>>
>> Considering the amount of retry libraries there are out there, I
>> think it
>> makes perfect sense for circuit breaker libraries to be their own
>> thing,
>> too. See Hysterix for example.
>>
>> --
>> Matt Sicker 


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

[Gilles]

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

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 a striking example of what
awaits a library that lacks boundary checks and explicit
road map.

Regards,
Gilles

On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org) 
wrote:


On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
-1 to "commons-misc". It feels to me like a copout and unfocused 
like

SomethingUtils.
We need a proper home.


+1


How about the idea of commons-measure.


Just because the first feature would happen to be a timer?
What other content do you foresee?


Then there
still the idea of resurrecting other Apache projects. Kind of going
in
circles...


Indeed, IIRC the questions were asked (whether the feature could
be contributed to ex-Sirona and whether that project would be
repatriated to "Commons") but not answered (unless I'm mistaken)...

Best,
Gilles



Gary

On Mar 8, 2018 08:58, "Otto Fowler"  wrote:

So, could think about commons-misc or something?
I don’t think we are going to come up with a perfect module for 
these

things.

Maybe the way it can work is:

commons-misc exists.

It is the landing place for things that seem to be outside the scope
of
commons-, but don’t justify
a new module or sandbox effort.

Things in misc can be reevaluated for inclusion in new modules at
things
go, and at that point @Depricated
out of misc.

?



On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:

On 2 March 2018 at 13:31, Oliver Heger 


wrote:


One other suggestion: It was stated in the past that the concurrent
classes are also a bit out of scope for [lang], especially the
circuit
breaker implementations. Would it make sense to move those into a
new
module, and could this be a home for the watch classes, too?



Considering the amount of retry libraries there are out there, I
think it
makes perfect sense for circuit breaker libraries to be their own
thing,
too. See Hysterix for example.

--
Matt Sicker 



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

[Otto Fowler]

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.

commons-monitoring or commons-timing seem to be the correct thing however,
but I would like to think that there would be more impetus to do this than
thinking StackWatch is ‘too big’ for lang.time.

It really isn’t that complicated a thing.


On March 8, 2018 at 11:50:17, Gilles (gil...@harfang.homelinux.org) wrote:

On Thu, 08 Mar 2018 16:03:24 +, Gary Gregory wrote:
> -1 to "commons-misc". It feels to me like a copout and unfocused like
> SomethingUtils.
> We need a proper home.

+1

> How about the idea of commons-measure.

Just because the first feature would happen to be a timer?
What other content do you foresee?

> Then there
> still the idea of resurrecting other Apache projects. Kind of going
> in
> circles...

Indeed, IIRC the questions were asked (whether the feature could
be contributed to ex-Sirona and whether that project would be
repatriated to "Commons") but not answered (unless I'm mistaken)...

Best,
Gilles


> Gary
>
> On Mar 8, 2018 08:58, "Otto Fowler"  wrote:
>
> So, could think about commons-misc or something?
> I don’t think we are going to come up with a perfect module for these
> things.
>
> Maybe the way it can work is:
>
> commons-misc exists.
>
> It is the landing place for things that seem to be outside the scope
> of
> commons-, but don’t justify
> a new module or sandbox effort.
>
> Things in misc can be reevaluated for inclusion in new modules at
> things
> go, and at that point @Depricated
> out of misc.
>
> ?
>
>
>
> On March 3, 2018 at 00:42:12, Matt Sicker (boa...@gmail.com) wrote:
>
> On 2 March 2018 at 13:31, Oliver Heger 
> wrote:
>>
>> One other suggestion: It was stated in the past that the concurrent
>> classes are also a bit out of scope for [lang], especially the
>> circuit
>> breaker implementations. Would it make sense to move those into a
>> new
>> module, and could this be a home for the watch classes, too?
>>
>
> Considering the amount of retry libraries there are out there, I
> think it
> makes perfect sense for circuit breaker libraries to be their own
> thing,
> too. See Hysterix for example.
>
> --
> Matt Sicker 


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