AW: [lang] Todo utility class

[jhm]

That class is not a regular dependency (test/runtime). 
It is more a tool - especially with the mojo you suggested.

So, where we could host tools?

Jan


> -Ursprüngliche Nachricht-
> Von: Matt Benson [mailto:mben...@apache.org]
> Gesendet: Freitag, 16. März 2018 22:22
> An: Commons Developers List
> Betreff: Re: [lang] Todo utility class
> 
> I also don't think it belongs in a testing module. OTOH, I appreciate
> the desire not to have such hang around in finished code. I think I
> might create a dedicated project around this (elsewhere) with a Maven
> plugin to provide safeguards around unfinished uses of Todo.
> 
> Thanks for considering this,
> Matt
> 
> On Mar 16, 2018 6:09 AM, "Gilles"  wrote:
> 
> > On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:
> >
> >> On Thu, Mar 15, 2018 at 4:05 PM, Gilles
> >> 
> >> wrote:
> >>
> >>> 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.
> >>>
> >>
> >> I would recommend against commons testing. i would assume that
> >> component would be a dependency with a test scope in most projects,
> >> making it impossible to use it in the main code.
> >>
> >
> > That is the feature: when about to release, all "Commons Testing"
> > modules must be in "test" scope, and if they are used in "main",
> > compilation will fail.
> > In development, "main" would depend on "Commons Testing" to allow
> > usage of "Todo".
> >
> > Gilles
> >
> > Regards,
> >> Bindul
> >>
> >>
> >
> > -
> > 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?

[Romain Manni-Bucau]

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

Re: [DISCUSS] new component for timing?

[Gilles]

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

Re: [DISCUSS] new component for timing?

[Romain Manni-Bucau]

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



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

Re: [DISCUSS] new component for timing?

[Gilles]

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.

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