[RESULT][VOTE][LAZY] Migrate Apache Commons CSV to git

[Benedikt Ritter]

Hi

Benedikt Ritter  schrieb am Mo., 6. Juni 2016 um
21:17 Uhr:

> Hello,
>
> as done before for other components, I'd like to call a VOTE by LAZY
> consensus for migrating the Apache Commons CSV component to git. Please
> object to this vote if you see a problem with this. Otherwise this vote
> will be considered as passed after 72 hours from now (9th June 2016, 21:30
> CEST)
>

This vote by lazy consensus passes.

The following people have voted +1:

- Jochen Wiedmann
- James Carman
- Gary Gregory
- Sergio Fernández

I'll take care of the migration and keep the ML updated about the progress.

Regards,
Benedikt


>
> Thank you,
> Benedikt
>

Re: [RESULT][VOTE][LAZY] Migrate Apache Commons CSV to git

[Jochen Wiedmann]

On Fri, Jun 10, 2016 at 9:05 AM, Benedikt Ritter  wrote:

> I'll take care of the migration and keep the ML updated about the progress.


Thanks, Benedikt.

Who's next in the queue?

Jochen



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[Kristian Rosenvold]

This vote passes by lazy consensus.

The following people have voted +1:

- Jochen Wiedmann
- Sergio Fernández
- Gary Gregory
- James Carman

I'll take care of the migration and keep the ML updated about the progress.

Regards,
Kristian (Master of ^C^V)

2016-06-07 12:46 GMT+02:00 James Carman :
> +1
>
> On Tue, Jun 7, 2016 at 2:37 AM Kristian Rosenvold 
> wrote:
>
>> Hello,
>>
>> I'd like to call a VOTE by LAZY
>> consensus for migrating the Apache Commons IO component to git. Please
>> object to this vote if you see a problem with this. Otherwise this vote
>> will be considered as passed after 72 hours from now (10th June 2016, 09:00
>> CET)
>>
>> Thank you,
>> Kristian
>>

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

Re: [Math] Commons Math (r)evolution

[Gilles]

Hi.

On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:

[snip]


_Some_ developer(s) should be able to support whatever is in
development.
Otherwise how can it be deemed "in development"?

Just today, two issues were reported on JIRA:
   https://issues.apache.org/jira/browse/MATH-172
   https://issues.apache.org/jira/browse/MATH-1375

They, unfortunately, illustrate my point.


No, it does not.

MATH-172 is about an enhancement. Unfortunately no-one can currently
implement it, so we have to wait until someone can or the issue stays 
simply
unresolved again. You've requested for help and that was the proper 
action.
However, there has been no problem to release 3.0 in this state, so 
why

should it be a problem now for 4.0?


Because the context has changed: in 3.0 there was support, now there 
isn't.


MATH-1735 is a bug report for a problem which is currently not 
reproducible.

Again you did the right action, but without more input and without a
possibility to reproduce the problem, there's not much we can do. 
Again, why

should this issue prevent a release of 4.0?


The code in question should not have been in CM. [That was my position 
back

then (cf. archive).]

And every bug report for it is a reminder that unmaintainable code 
should

not be released.

Moreover what could be true for VFS is not for CM where there are 
many,
many different areas that have nothing in common (except perhaps 
some
ubiquitous very-low utilities which might be worth their own 
component

to serve as a, maybe "internal", dependency).

Also, compare the source basic statistics (lines of code):
   VFS  CM
Java code24215   90834
Unit tests8926   95595

All in all, CM is more than 5 times larger than VFS (not even 
counting

documentation).


Any why is size suddenly a problem?


Not suddenly.
I've raised this issue for years.  Please look at the archives!


[snip]


That's why I strongly favour cutting this monolith into pieces
with a limited scope.


Nobody objects, but if you look at vfs, it is still *one* Apache
Commons
component, just with multiple artifacts. All these artifacts are
released
*together*.


Sorry I'm lost, I looked there:
   http://commons.apache.org/proper/commons-vfs/download_vfs.cgi

And, it seems that all the functionality is in a single JAR.
[Other files contain the sources, tests, examples.]


Then look at commons-weaver.


Anyways, it is obvious that, in VFS, there is a well defined scope
(a unifying rationale).

No such thing in CM.

What I want to achieve is indeed to create a set of components that 
are

more like VFS!


Fine. But talk about artifacts, not components. Apache Commons Math 
is still
*one* component of Apache Commons. It does not matter if you divide 
the code

into different artifacts as long as anything is released together.


I know.

What you can't seem to get to is that I consider it a bad idea to 
release

unsupported code.

I think that "I do not know (and nobody else does)" is not an 
acceptable

answer to user requests.
If we _know_ that some parts of the code would be unsupported (such 
that it
would elicit this kind of answer for bug reports), then it's 
_deceiving_ to

release that code.

Individual release cycles for the different parts can only happen if 
Math is
TLP, but not in Apache Commons. We will certainly not allow and 
create again

any sub-umbrellas (search the Jakarta archives).


Who talked about sub-umbrellas?  I didn't.

I've explained that
 1. CM cannot be released as it was before
 2. for some parts, the necessary _minimal_ support has "disappeared"
 3. some parts can be turned into independent components (with _full_
support)
 4. Some people are ready to perform the necessary steps in order to
create these components

Please comment on how this contradicts Commons policy.

This is particularly obvious with the RNGs where there is one 
unifying

interface, a factory method and multiple implementations.
[Of course, in that case, the new component will be much simpler 
than

VFS (which is a "good thing", isn't it?).]


Turning math into a multi-project has nothing to do with your
plans to drop mature code,


I am not dropping anything (others did that); I am stating facts and 
I
now want to spend my time on something (hopefully) worth it.  
[Working

to modularize unsupported code is a (huge) waste of time.]

Also, in the case of CM, "mature code" is meaningless as an overall
qualifier: some codes are
  * new (and never released, e.g. 64-bits-based RNGs)
  * algorithms introduced relatively recently (and perhaps never 
used)
  * old (and sometimes outdated and impossible to fix without 
breaking

compatibility)
  * mostly functional (but impossible to maintain, cf. MATH-1375)
  * resulting from a refactoring (hence even when the functionality 
has

existed for a long time, the code is not "mature")

IMHO, maturity should be visible in the code.  It's an impression 
that

builds up b

[IMAGING] Working towards a release?

[Benedikt Ritter]

Hello Gary,

are you planning to roll a (long over due) release for Imaging?

Benedikt

Re: [compress] Preparing for 1.12

[Torsten Curdt]

>
>
> You'll see that findbugs is unhappy about inconsistent synchronization
> introduced when I made the finish method of BZip2CompressorOutputStream
> synchronized due to COMPRESS-357
>
> Yes, blockSorter is accessed unsynchronized in different places, but we
> don't need to care as the class isn't thread safe anyway and all we
> wanted to do is to avoid a race condition with GC. I'd prefer to
> suppress the warning over synchronizing more of the class.
>
> Any feedback more than welcome.
>

My feedback: I'd rather recommend to get rid of the finalize over adding
synchronization. Using finalize is rarely a good idea. I wasn't aware we
have that in the code base.

Re: [crypto] Logging dependency

[Torsten Curdt]

FWIW

I am not a fan of libraries and frameworks just logging away anyway.

What I usually do this days:
Have an interface in the library itself. Along the lines of

public interface Console {
void debug( String message );
}

and then have the user of the library pass in an implementation of his/her
liking.
Let others do the log framework discussions.

Re: [crypto] Logging dependency

[Gilles]

Hi.

On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:

FWIW

I am not a fan of libraries and frameworks just logging away anyway.

What I usually do this days:
Have an interface in the library itself. Along the lines of

public interface Console {
void debug( String message );
}


What you do here (simple usage) is the same as what "slf4j-api" or
"log4j2-api" do.

Whether the library developers choose one or the other, the application
developers still can choose one or the other framework (as both provide
a bridge to the other one).

Regards,
Gilles

and then have the user of the library pass in an implementation of 
his/her

liking.
Let others do the log framework discussions.



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

Re: [crypto] Logging dependency

[sebb]

On 10 June 2016 at 10:46, Gilles  wrote:
> Hi.
>
> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>>
>> FWIW
>>
>> I am not a fan of libraries and frameworks just logging away anyway.
>>
>> What I usually do this days:
>> Have an interface in the library itself. Along the lines of
>>
>> public interface Console {
>> void debug( String message );
>> }
>
>
> What you do here (simple usage) is the same as what "slf4j-api" or
> "log4j2-api" do.

Not really, because you also need a run-time implementation.
That's two extra jars, regardless of whether any output is needed.

And the user has to provide a configuration file (at least with log4j)

> Whether the library developers choose one or the other, the application
> developers still can choose one or the other framework (as both provide
> a bridge to the other one).
>
> Regards,
> Gilles
>
>> and then have the user of the library pass in an implementation of his/her
>> liking.
>> Let others do the log framework discussions.
>
>
>
> -
> 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: [Math] Commons Math (r)evolution

[Jörg Schaible]

Hi Gilles,

Gilles wrote:

> Hi.
> 
> On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:

[snip]

>> MATH-172 is about an enhancement. Unfortunately no-one can currently
>> implement it, so we have to wait until someone can or the issue stays
>> simply
>> unresolved again. You've requested for help and that was the proper
>> action.
>> However, there has been no problem to release 3.0 in this state, so
>> why
>> should it be a problem now for 4.0?
> 
> Because the context has changed: in 3.0 there was support, now there
> isn't.


That does not state the fact, that the code is already released and it does 
not matter at all if users ask questions for release 3.0 or 4.0.


>> MATH-1735 is a bug report for a problem which is currently not
>> reproducible.
>> Again you did the right action, but without more input and without a
>> possibility to reproduce the problem, there's not much we can do.
>> Again, why
>> should this issue prevent a release of 4.0?
> 
> The code in question should not have been in CM. [That was my position
> back
> then (cf. archive).]


Again, you cannot change history, it is already released. And a new release 
of the code does not make the situation worse.

 
> And every bug report for it is a reminder that unmaintainable code
> should
> not be released.


That is your interpretation. For me it is a normal bug report and we can 
eigher solve it on our own or have to wait for a contribution.

 
>>> Moreover what could be true for VFS is not for CM where there are
>>> many,
>>> many different areas that have nothing in common (except perhaps
>>> some
>>> ubiquitous very-low utilities which might be worth their own
>>> component
>>> to serve as a, maybe "internal", dependency).
>>>
>>> Also, compare the source basic statistics (lines of code):
>>>VFS  CM
>>> Java code24215   90834
>>> Unit tests8926   95595
>>>
>>> All in all, CM is more than 5 times larger than VFS (not even
>>> counting
>>> documentation).
>>
>> Any why is size suddenly a problem?
> 
> Not suddenly.
> I've raised this issue for years.  Please look at the archives!


Then: Why is size a problem? It is only a problem if *you* try to support 
all of it at once. Nobody expects that.

[snip]


>> Fine. But talk about artifacts, not components. Apache Commons Math
>> is still
>> *one* component of Apache Commons. It does not matter if you divide
>> the code
>> into different artifacts as long as anything is released together.
> 
> I know.
> 
> What you can't seem to get to is that I consider it a bad idea to
> release
> unsupported code.


You've stated that multiple times now.


> I think that "I do not know (and nobody else does)" is not an
> acceptable
> answer to user requests.


See, this is the difference. To me this *is* acceptible. Especially if users 
have to be kind of experts themselves to use this code.


> If we _know_ that some parts of the code would be unsupported (such
> that it
> would elicit this kind of answer for bug reports), then it's
> _deceiving_ to
> release that code.


A new release does not change the situation at all. With such a definition 
we could move quite some of our components directly to the attic, because 
the original authors are no longer around and we might currently have no 
expert around.


>> Individual release cycles for the different parts can only happen if
>> Math is
>> TLP, but not in Apache Commons. We will certainly not allow and
>> create again
>> any sub-umbrellas (search the Jakarta archives).
> 
> Who talked about sub-umbrellas?  I didn't.


I talk about it, because it is what the result looks to me.

 
> I've explained that
>   1. CM cannot be released as it was before


You've expressed that *you* don't want to release it as it was before (well-
founded however).


>   2. for some parts, the necessary _minimal_ support has "disappeared"


That does not immediately invalidate the existing code. One fact that you 
don't want to see.


>   3. some parts can be turned into independent components (with _full_
>  support)


Have we some kind of agreement here to introduce new Commons components? As 
far as I know, we just did not oppose to break Math into individual 
artifacts.


>   4. Some people are ready to perform the necessary steps in order to
>  create these components


The work on the code is still independent of a monolithic Math component vs. 
inidividual (let's say) Maven projects. The refactoring is the same if you 
simply want to minimize the dependencies between the Java packages in Math.


> Please comment on how this contradicts Commons policy.


The ASF in general does not like umbrella TLPs at all. Apache Commons 
actually has been near this category all the times. We try to manage a 
(large) set of general purpose libraries with the intent to provide long 
time compatibility (sometimes possibly exaggerated) or provide clear upgrade 
paths if a redesign was necessary. We do this, because we are aware that our 
c

Re: [crypto] Logging dependency

[Torsten Curdt]

On Fri, Jun 10, 2016 at 12:14 PM, sebb  wrote:

> On 10 June 2016 at 10:46, Gilles  wrote:
> > Hi.
> >
> > On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
> >>
> >> FWIW
> >>
> >> I am not a fan of libraries and frameworks just logging away anyway.
> >>
> >> What I usually do this days:
> >> Have an interface in the library itself. Along the lines of
> >>
> >> public interface Console {
> >> void debug( String message );
> >> }
> >
> >
> > What you do here (simple usage) is the same as what "slf4j-api" or
> > "log4j2-api" do.
>
> Not really, because you also need a run-time implementation.
> That's two extra jars, regardless of whether any output is needed.
>
> And the user has to provide a configuration file (at least with log4j)
>

Exactly. It's so simple and it doesn't introduce any deps.
Whether that's goal one can align with is another matter.
But it means no logging framework discussions anymore ;)

Re: [crypto] Logging dependency

[Gilles]

On Fri, 10 Jun 2016 12:34:10 +0200, Torsten Curdt wrote:

On Fri, Jun 10, 2016 at 12:14 PM, sebb  wrote:

On 10 June 2016 at 10:46, Gilles  
wrote:

> Hi.
>
> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>>
>> FWIW
>>
>> I am not a fan of libraries and frameworks just logging away 
anyway.

>>
>> What I usually do this days:
>> Have an interface in the library itself. Along the lines of
>>
>> public interface Console {
>> void debug( String message );
>> }
>
>
> What you do here (simple usage) is the same as what "slf4j-api" or
> "log4j2-api" do.

Not really, because you also need a run-time implementation.
That's two extra jars, regardless of whether any output is needed.

And the user has to provide a configuration file (at least with 
log4j)




Exactly. It's so simple and it doesn't introduce any deps.
Whether that's goal one can align with is another matter.
But it means no logging framework discussions anymore ;)


But I guarantee that there will be other discussions:
  Wouldn't you add an "error" method to "Console"?
And there we go again...

Gilles


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

Re: [crypto] Logging dependency

[Torsten Curdt]

>
> But I guarantee that there will be other discussions:
>   Wouldn't you add an "error" method to "Console"?
> And there we go again...


Not quite the same discussions though.
And I was just saying: it works for me.

As a side note: I personally think libraries should return errors - not log
them. The error logging should happen in the app - not the library. If you
have to log errors in the framework there is a good chance your API is not
how it should be.

Re: [crypto] Logging dependency

[sebb]

On 10 June 2016 at 11:55, Torsten Curdt  wrote:
>>
>> But I guarantee that there will be other discussions:
>>   Wouldn't you add an "error" method to "Console"?
>> And there we go again...
>
>
> Not quite the same discussions though.
> And I was just saying: it works for me.
>
> As a side note: I personally think libraries should return errors - not log
> them. The error logging should happen in the app - not the library. If you
> have to log errors in the framework there is a good chance your API is not
> how it should be.

+1

Only the app can decide what an error means in the context of the app,
so only the app can log a sensible error message.

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

Re: [crypto] Logging dependency

[James Carman]

I can get on board with that model I suppose. What we talked about long ago
was an event listener model for knowing what's going on internally with a
library. These events could be delivered asynchronously from the calls
coming from an application.
On Fri, Jun 10, 2016 at 7:03 AM sebb  wrote:

> On 10 June 2016 at 11:55, Torsten Curdt  wrote:
> >>
> >> But I guarantee that there will be other discussions:
> >>   Wouldn't you add an "error" method to "Console"?
> >> And there we go again...
> >
> >
> > Not quite the same discussions though.
> > And I was just saying: it works for me.
> >
> > As a side note: I personally think libraries should return errors - not
> log
> > them. The error logging should happen in the app - not the library. If
> you
> > have to log errors in the framework there is a good chance your API is
> not
> > how it should be.
>
> +1
>
> Only the app can decide what an error means in the context of the app,
> so only the app can log a sensible error message.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

RE: [Math] Commons Math (r)evolution

[Patrick Meyer]

I think it would be better to spend the time trying to recruit new contributors 
than it would be to alienate existing ones. Also, the effort required to divide 
the library into smaller parts would be better spent creating patches. 

Does anyone have ideas for actively recruiting contributors? Do you know of 
mathematics departments that also teach students Java programming? A recruiting 
campaign with the message like "here's what we do at CM, we'd like your help" 
could attract new contributors. It will take time, but a constructive approach 
like this one will do more to sustain CM.

Thanks,
Patrick

-Original Message-
From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com] 
Sent: Friday, June 10, 2016 6:20 AM
To: dev@commons.apache.org
Subject: Re: [Math] Commons Math (r)evolution

Hi Gilles,

Gilles wrote:

> Hi.
> 
> On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:

[snip]

>> MATH-172 is about an enhancement. Unfortunately no-one can currently 
>> implement it, so we have to wait until someone can or the issue stays 
>> simply unresolved again. You've requested for help and that was the 
>> proper action.
>> However, there has been no problem to release 3.0 in this state, so 
>> why should it be a problem now for 4.0?
> 
> Because the context has changed: in 3.0 there was support, now there 
> isn't.


That does not state the fact, that the code is already released and it does not 
matter at all if users ask questions for release 3.0 or 4.0.


>> MATH-1735 is a bug report for a problem which is currently not
>> reproducible.
>> Again you did the right action, but without more input and without a
>> possibility to reproduce the problem, there's not much we can do.
>> Again, why
>> should this issue prevent a release of 4.0?
> 
> The code in question should not have been in CM. [That was my position
> back
> then (cf. archive).]


Again, you cannot change history, it is already released. And a new release 
of the code does not make the situation worse.

 
> And every bug report for it is a reminder that unmaintainable code
> should
> not be released.


That is your interpretation. For me it is a normal bug report and we can 
eigher solve it on our own or have to wait for a contribution.

 
>>> Moreover what could be true for VFS is not for CM where there are
>>> many,
>>> many different areas that have nothing in common (except perhaps
>>> some
>>> ubiquitous very-low utilities which might be worth their own
>>> component
>>> to serve as a, maybe "internal", dependency).
>>>
>>> Also, compare the source basic statistics (lines of code):
>>>VFS  CM
>>> Java code24215   90834
>>> Unit tests8926   95595
>>>
>>> All in all, CM is more than 5 times larger than VFS (not even
>>> counting
>>> documentation).
>>
>> Any why is size suddenly a problem?
> 
> Not suddenly.
> I've raised this issue for years.  Please look at the archives!


Then: Why is size a problem? It is only a problem if *you* try to support 
all of it at once. Nobody expects that.

[snip]


>> Fine. But talk about artifacts, not components. Apache Commons Math
>> is still
>> *one* component of Apache Commons. It does not matter if you divide
>> the code
>> into different artifacts as long as anything is released together.
> 
> I know.
> 
> What you can't seem to get to is that I consider it a bad idea to
> release
> unsupported code.


You've stated that multiple times now.


> I think that "I do not know (and nobody else does)" is not an
> acceptable
> answer to user requests.


See, this is the difference. To me this *is* acceptible. Especially if users 
have to be kind of experts themselves to use this code.


> If we _know_ that some parts of the code would be unsupported (such
> that it
> would elicit this kind of answer for bug reports), then it's
> _deceiving_ to
> release that code.


A new release does not change the situation at all. With such a definition 
we could move quite some of our components directly to the attic, because 
the original authors are no longer around and we might currently have no 
expert around.


>> Individual release cycles for the different parts can only happen if
>> Math is
>> TLP, but not in Apache Commons. We will certainly not allow and
>> create again
>> any sub-umbrellas (search the Jakarta archives).
> 
> Who talked about sub-umbrellas?  I didn't.


I talk about it, because it is what the result looks to me.

 
> I've explained that
>   1. CM cannot be released as it was before


You've expressed that *you* don't want to release it as it was before (well-
founded however).


>   2. for some parts, the necessary _minimal_ support has "disappeared"


That does not immediately invalidate the existing code. One fact that you 
don't want to see.


>   3. some parts can be turned into independent components (with _full_
>  support)


Have we some kind of agreement here to introduce new Commons components? As 
far as I know, we just did not oppose to br

Re: [compress] Preparing for 1.12

[Stefan Bodewig]

On 2016-06-10, Torsten Curdt wrote:

>> You'll see that findbugs is unhappy about inconsistent synchronization
>> introduced when I made the finish method of BZip2CompressorOutputStream
>> synchronized due to COMPRESS-357

> My feedback: I'd rather recommend to get rid of the finalize over adding
> synchronization. Using finalize is rarely a good idea. I wasn't aware we
> have that in the code base.

We have it in two cases, ZipFile and BZip2CompressorOutputStream -
ZipFile uses a volatile flag rather than synchronization and
null-assignment, maybe that's the better option anyway.

Even if we agree that having finalize in BZip2CompressorOutputStream we
can't easily change the behavior without breaking code that relies on
not being forced to finish the stream.

Stefan

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

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[Jochen Wiedmann]

On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
 wrote:

> This vote passes by lazy consensus.

So, again: Who's next?



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [crypto] Logging dependency

[Gilles]

On Fri, 10 Jun 2016 12:55:18 +0200, Torsten Curdt wrote:


But I guarantee that there will be other discussions:
  Wouldn't you add an "error" method to "Console"?
And there we go again...



Not quite the same discussions though.
And I was just saying: it works for me.

As a side note: I personally think libraries should return errors - 
not log
them. The error logging should happen in the app - not the library. 
If you
have to log errors in the framework there is a good chance your API 
is not

how it should be.


"error" was just an example.
I meant that you'll end up with perfectly valid requests for all the 
levels

supported by the API of full-fledged frameworks.

Gilles

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

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

+1

Ralph

> On Jun 10, 2016, at 4:37 AM, Patrick Meyer  wrote:
> 
> I think it would be better to spend the time trying to recruit new 
> contributors than it would be to alienate existing ones. Also, the effort 
> required to divide the library into smaller parts would be better spent 
> creating patches. 
> 
> Does anyone have ideas for actively recruiting contributors? Do you know of 
> mathematics departments that also teach students Java programming? A 
> recruiting campaign with the message like "here's what we do at CM, we'd like 
> your help" could attract new contributors. It will take time, but a 
> constructive approach like this one will do more to sustain CM.
> 
> Thanks,
> Patrick
> 
> -Original Message-
> From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com] 
> Sent: Friday, June 10, 2016 6:20 AM
> To: dev@commons.apache.org
> Subject: Re: [Math] Commons Math (r)evolution
> 
> Hi Gilles,
> 
> Gilles wrote:
> 
>> Hi.
>> 
>> On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:
> 
> [snip]
> 
>>> MATH-172 is about an enhancement. Unfortunately no-one can currently 
>>> implement it, so we have to wait until someone can or the issue stays 
>>> simply unresolved again. You've requested for help and that was the 
>>> proper action.
>>> However, there has been no problem to release 3.0 in this state, so 
>>> why should it be a problem now for 4.0?
>> 
>> Because the context has changed: in 3.0 there was support, now there 
>> isn't.
> 
> 
> That does not state the fact, that the code is already released and it does 
> not matter at all if users ask questions for release 3.0 or 4.0.
> 
> 
>>> MATH-1735 is a bug report for a problem which is currently not
>>> reproducible.
>>> Again you did the right action, but without more input and without a
>>> possibility to reproduce the problem, there's not much we can do.
>>> Again, why
>>> should this issue prevent a release of 4.0?
>> 
>> The code in question should not have been in CM. [That was my position
>> back
>> then (cf. archive).]
> 
> 
> Again, you cannot change history, it is already released. And a new release 
> of the code does not make the situation worse.
> 
> 
>> And every bug report for it is a reminder that unmaintainable code
>> should
>> not be released.
> 
> 
> That is your interpretation. For me it is a normal bug report and we can 
> eigher solve it on our own or have to wait for a contribution.
> 
> 
 Moreover what could be true for VFS is not for CM where there are
 many,
 many different areas that have nothing in common (except perhaps
 some
 ubiquitous very-low utilities which might be worth their own
 component
 to serve as a, maybe "internal", dependency).
 
 Also, compare the source basic statistics (lines of code):
   VFS  CM
 Java code24215   90834
 Unit tests8926   95595
 
 All in all, CM is more than 5 times larger than VFS (not even
 counting
 documentation).
>>> 
>>> Any why is size suddenly a problem?
>> 
>> Not suddenly.
>> I've raised this issue for years.  Please look at the archives!
> 
> 
> Then: Why is size a problem? It is only a problem if *you* try to support 
> all of it at once. Nobody expects that.
> 
> [snip]
> 
> 
>>> Fine. But talk about artifacts, not components. Apache Commons Math
>>> is still
>>> *one* component of Apache Commons. It does not matter if you divide
>>> the code
>>> into different artifacts as long as anything is released together.
>> 
>> I know.
>> 
>> What you can't seem to get to is that I consider it a bad idea to
>> release
>> unsupported code.
> 
> 
> You've stated that multiple times now.
> 
> 
>> I think that "I do not know (and nobody else does)" is not an
>> acceptable
>> answer to user requests.
> 
> 
> See, this is the difference. To me this *is* acceptible. Especially if users 
> have to be kind of experts themselves to use this code.
> 
> 
>> If we _know_ that some parts of the code would be unsupported (such
>> that it
>> would elicit this kind of answer for bug reports), then it's
>> _deceiving_ to
>> release that code.
> 
> 
> A new release does not change the situation at all. With such a definition 
> we could move quite some of our components directly to the attic, because 
> the original authors are no longer around and we might currently have no 
> expert around.
> 
> 
>>> Individual release cycles for the different parts can only happen if
>>> Math is
>>> TLP, but not in Apache Commons. We will certainly not allow and
>>> create again
>>> any sub-umbrellas (search the Jakarta archives).
>> 
>> Who talked about sub-umbrellas?  I didn't.
> 
> 
> I talk about it, because it is what the result looks to me.
> 
> 
>> I've explained that
>>  1. CM cannot be released as it was before
> 
> 
> You've expressed that *you* don't want to release it as it was before (well-
> founded however).
> 
> 
>>  2. for some parts, the necessary _minimal_ support has "disappeared"
> 

Re: [crypto] Logging dependency

[Ralph Goers]

> On Jun 10, 2016, at 3:34 AM, Torsten Curdt  wrote:
> 
> On Fri, Jun 10, 2016 at 12:14 PM, sebb  wrote:
> 
>> On 10 June 2016 at 10:46, Gilles  wrote:
>>> Hi.
>>> 
>>> On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
 
 FWIW
 
 I am not a fan of libraries and frameworks just logging away anyway.
 
 What I usually do this days:
 Have an interface in the library itself. Along the lines of
 
public interface Console {
void debug( String message );
}
>>> 
>>> 
>>> What you do here (simple usage) is the same as what "slf4j-api" or
>>> "log4j2-api" do.
>> 
>> Not really, because you also need a run-time implementation.
>> That's two extra jars, regardless of whether any output is needed.
>> 
>> And the user has to provide a configuration file (at least with log4j)
>> 
> 
> Exactly. It's so simple and it doesn't introduce any deps.
> Whether that's goal one can align with is another matter.
> But it means no logging framework discussions anymore ;)

The disadvantage of this approach is that you loose the location information - 
every log event will come from your debug method instead of the code actually 
doing the logging.

Ralph



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

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[Benedikt Ritter]

Jochen Wiedmann  schrieb am Fr., 10. Juni 2016
um 14:14 Uhr:

> On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
>  wrote:
>
> > This vote passes by lazy consensus.
>
> So, again: Who's next?
>

Pick one you like. How about FileUpload?


>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[James Carman]

Is anyone opposed at this time to moving everything at once?

On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter  wrote:

> Jochen Wiedmann  schrieb am Fr., 10. Juni 2016
> um 14:14 Uhr:
>
> > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
> >  wrote:
> >
> > > This vote passes by lazy consensus.
> >
> > So, again: Who's next?
> >
>
> Pick one you like. How about FileUpload?
>
>
> >
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: [compress] Preparing for 1.12

[Stefan Bodewig]

On 2016-06-10, Stefan Bodewig wrote:

> We have it in two cases, ZipFile and BZip2CompressorOutputStream -
> ZipFile uses a volatile flag rather than synchronization and
> null-assignment, maybe that's the better option anyway.

I've changed the code and findbugs is happy again, updated site build at

http://stefan.samaflost.de/staging/COMPRESS-1.12/

Stefan

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

Re: [crypto] Logging dependency

[sebb]

On 10 June 2016 at 13:39, Ralph Goers  wrote:
>
>> On Jun 10, 2016, at 3:34 AM, Torsten Curdt  wrote:
>>
>> On Fri, Jun 10, 2016 at 12:14 PM, sebb  wrote:
>>
>>> On 10 June 2016 at 10:46, Gilles  wrote:
 Hi.

 On Fri, 10 Jun 2016 11:12:23 +0200, Torsten Curdt wrote:
>
> FWIW
>
> I am not a fan of libraries and frameworks just logging away anyway.
>
> What I usually do this days:
> Have an interface in the library itself. Along the lines of
>
>public interface Console {
>void debug( String message );
>}


 What you do here (simple usage) is the same as what "slf4j-api" or
 "log4j2-api" do.
>>>
>>> Not really, because you also need a run-time implementation.
>>> That's two extra jars, regardless of whether any output is needed.
>>>
>>> And the user has to provide a configuration file (at least with log4j)
>>>
>>
>> Exactly. It's so simple and it doesn't introduce any deps.
>> Whether that's goal one can align with is another matter.
>> But it means no logging framework discussions anymore ;)
>
> The disadvantage of this approach is that you loose the location information 
> - every log event will come from your debug method instead of the code 
> actually doing the logging.

Depends on what the implementation does.

For example:

@Override
void debug( String message ){
new Throwable(message).printStackTrace();
}

> Ralph
>
>
>
> -
> 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][LAZY] Migrate Apache Commons IO to git

[sebb]

Yes

On 10 June 2016 at 13:57, James Carman  wrote:
> Is anyone opposed at this time to moving everything at once?
>
> On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter  wrote:
>
>> Jochen Wiedmann  schrieb am Fr., 10. Juni 2016
>> um 14:14 Uhr:
>>
>> > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
>> >  wrote:
>> >
>> > > This vote passes by lazy consensus.
>> >
>> > So, again: Who's next?
>> >
>>
>> Pick one you like. How about FileUpload?
>>
>>
>> >
>> >
>> >
>> > --
>> > The next time you hear: "Don't reinvent the wheel!"
>> >
>> >
>> >
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>> >
>> > -
>> > 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][LAZY] Migrate Apache Commons IO to git

[James Carman]

Perhaps I should re-phrase (may not make a difference, but it could).  Can
we just say that any component that wishes to migrate can feel free to do
so at this time?  We don't need a VOTE or anything.  If someone gets the
cycles and inspiration to do so, they can feel free to go right ahead.
That's what I mean.  I don't mean force everyone to move right now.

On Fri, Jun 10, 2016 at 8:57 AM James Carman 
wrote:

> Is anyone opposed at this time to moving everything at once?
>
> On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter 
> wrote:
>
>> Jochen Wiedmann  schrieb am Fr., 10. Juni 2016
>> um 14:14 Uhr:
>>
>> > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
>> >  wrote:
>> >
>> > > This vote passes by lazy consensus.
>> >
>> > So, again: Who's next?
>> >
>>
>> Pick one you like. How about FileUpload?
>>
>>
>> >
>> >
>> >
>> > --
>> > The next time you hear: "Don't reinvent the wheel!"
>> >
>> >
>> >
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> > For additional commands, e-mail: dev-h...@commons.apache.org
>> >
>> >
>>
>

Re: commons-compress git commit: better set that flag earlier

[sebb]

On 10 June 2016 at 14:01,   wrote:
> Repository: commons-compress
> Updated Branches:
>   refs/heads/master 8769bb698 -> bdc5ad445
>
>
> better set that flag earlier

Surely if it matters when the flag is set, then it also matters that
there is still a window between checking the flag and setting it?

As it stands, if the finish method can be called from two threads then
both can end up writing the trailer.
Isn't that why the code was synch in the first place?

Maybe try:

AtomicBoolean closed = new AtomicBoolean(false);

if (!closed.getAndSet(true)) {
}

>
> Project: http://git-wip-us.apache.org/repos/asf/commons-compress/repo
> Commit: 
> http://git-wip-us.apache.org/repos/asf/commons-compress/commit/bdc5ad44
> Tree: http://git-wip-us.apache.org/repos/asf/commons-compress/tree/bdc5ad44
> Diff: http://git-wip-us.apache.org/repos/asf/commons-compress/diff/bdc5ad44
>
> Branch: refs/heads/master
> Commit: bdc5ad445101133b7c92f4b2efbad1993913e160
> Parents: 8769bb6
> Author: Stefan Bodewig 
> Authored: Fri Jun 10 15:00:53 2016 +0200
> Committer: Stefan Bodewig 
> Committed: Fri Jun 10 15:00:53 2016 +0200
>
> --
>  .../compress/compressors/bzip2/BZip2CompressorOutputStream.java| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/commons-compress/blob/bdc5ad44/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
> --
> diff --git 
> a/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
>  
> b/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
> index 483d844..8cc6c39 100644
> --- 
> a/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
> +++ 
> b/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
> @@ -479,6 +479,7 @@ public class BZip2CompressorOutputStream extends 
> CompressorOutputStream
>
>  public void finish() throws IOException {
>  if (!closed) {
> +closed = true;
>  try {
>  if (this.runLength > 0) {
>  writeRun();
> @@ -487,7 +488,6 @@ public class BZip2CompressorOutputStream extends 
> CompressorOutputStream
>  endBlock();
>  endCompression();
>  } finally {
> -closed = true;
>  this.out = null;
>  this.data = null;
>  this.blockSorter = null;
>

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

Re: commons-compress git commit: better set that flag earlier

[sebb]

Sorry, ignore that - the code was synchronised in order to ensure safe
publication rather than preventing concurrect access.

On 10 June 2016 at 15:18, sebb  wrote:
> On 10 June 2016 at 14:01,   wrote:
>> Repository: commons-compress
>> Updated Branches:
>>   refs/heads/master 8769bb698 -> bdc5ad445
>>
>>
>> better set that flag earlier
>
> Surely if it matters when the flag is set, then it also matters that
> there is still a window between checking the flag and setting it?
>
> As it stands, if the finish method can be called from two threads then
> both can end up writing the trailer.
> Isn't that why the code was synch in the first place?
>
> Maybe try:
>
> AtomicBoolean closed = new AtomicBoolean(false);
>
> if (!closed.getAndSet(true)) {
> }
>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/commons-compress/repo
>> Commit: 
>> http://git-wip-us.apache.org/repos/asf/commons-compress/commit/bdc5ad44
>> Tree: http://git-wip-us.apache.org/repos/asf/commons-compress/tree/bdc5ad44
>> Diff: http://git-wip-us.apache.org/repos/asf/commons-compress/diff/bdc5ad44
>>
>> Branch: refs/heads/master
>> Commit: bdc5ad445101133b7c92f4b2efbad1993913e160
>> Parents: 8769bb6
>> Author: Stefan Bodewig 
>> Authored: Fri Jun 10 15:00:53 2016 +0200
>> Committer: Stefan Bodewig 
>> Committed: Fri Jun 10 15:00:53 2016 +0200
>>
>> --
>>  .../compress/compressors/bzip2/BZip2CompressorOutputStream.java| 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/commons-compress/blob/bdc5ad44/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
>> --
>> diff --git 
>> a/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
>>  
>> b/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
>> index 483d844..8cc6c39 100644
>> --- 
>> a/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
>> +++ 
>> b/src/main/java/org/apache/commons/compress/compressors/bzip2/BZip2CompressorOutputStream.java
>> @@ -479,6 +479,7 @@ public class BZip2CompressorOutputStream extends 
>> CompressorOutputStream
>>
>>  public void finish() throws IOException {
>>  if (!closed) {
>> +closed = true;
>>  try {
>>  if (this.runLength > 0) {
>>  writeRun();
>> @@ -487,7 +488,6 @@ public class BZip2CompressorOutputStream extends 
>> CompressorOutputStream
>>  endBlock();
>>  endCompression();
>>  } finally {
>> -closed = true;
>>  this.out = null;
>>  this.data = null;
>>  this.blockSorter = null;
>>

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

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[Jochen Wiedmann]

On Fri, Jun 10, 2016 at 2:55 PM, Benedikt Ritter  wrote:
> Jochen Wiedmann  schrieb am Fr., 10. Juni 2016
> um 14:14 Uhr:
>
>> On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
>>  wrote:
>>
>> > This vote passes by lazy consensus.
>>
>> So, again: Who's next?
>>
>
> Pick one you like. How about FileUpload?

Hooray for my good ole FileUpload!



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [crypto] Logging dependency

[Jochen Wiedmann]

On Fri, Jun 10, 2016 at 4:02 PM, sebb  wrote:

> Depends on what the implementation does.
>
> For example:
>
> @Override
> void debug( String message ){
> new Throwable(message).printStackTrace();
> }

Even a dumb application developer like me would at least like to see a
*bit* of performace. :-)

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

Re: [crypto] Logging dependency

[Matt Sicker]

Without Java 9, that's pretty much the only way to get the caller line
number and other metadata besides the caller class.

On 10 June 2016 at 09:44, Jochen Wiedmann  wrote:

> On Fri, Jun 10, 2016 at 4:02 PM, sebb  wrote:
>
> > Depends on what the implementation does.
> >
> > For example:
> >
> > @Override
> > void debug( String message ){
> > new Throwable(message).printStackTrace();
> > }
>
> Even a dumb application developer like me would at least like to see a
> *bit* of performace. :-)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Matt Sicker 

Re: [crypto] Logging dependency

[Ralph Goers]

Matt, there is a big difference between printing the stack trace and walking it 
to find the info. printing it on every debug call would be insane.

Ralph

> On Jun 10, 2016, at 8:09 AM, Matt Sicker  wrote:
> 
> Without Java 9, that's pretty much the only way to get the caller line
> number and other metadata besides the caller class.
> 
> On 10 June 2016 at 09:44, Jochen Wiedmann  wrote:
> 
>> On Fri, Jun 10, 2016 at 4:02 PM, sebb  wrote:
>> 
>>> Depends on what the implementation does.
>>> 
>>> For example:
>>> 
>>> @Override
>>> void debug( String message ){
>>>new Throwable(message).printStackTrace();
>>> }
>> 
>> Even a dumb application developer like me would at least like to see a
>> *bit* of performace. :-)
>> 
>> -
>> 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: [crypto] Logging dependency

[Matt Sicker]

Oh, I didn't even notice the printStackTrace() part until now. Good point.

On 10 June 2016 at 10:23, Ralph Goers  wrote:

> Matt, there is a big difference between printing the stack trace and
> walking it to find the info. printing it on every debug call would be
> insane.
>
> Ralph
>
> > On Jun 10, 2016, at 8:09 AM, Matt Sicker  wrote:
> >
> > Without Java 9, that's pretty much the only way to get the caller line
> > number and other metadata besides the caller class.
> >
> > On 10 June 2016 at 09:44, Jochen Wiedmann 
> wrote:
> >
> >> On Fri, Jun 10, 2016 at 4:02 PM, sebb  wrote:
> >>
> >>> Depends on what the implementation does.
> >>>
> >>> For example:
> >>>
> >>> @Override
> >>> void debug( String message ){
> >>>new Throwable(message).printStackTrace();
> >>> }
> >>
> >> Even a dumb application developer like me would at least like to see a
> >> *bit* of performace. :-)
> >>
> >> -
> >> 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
>
>


-- 
Matt Sicker 

Re: [crypto] Logging dependency

[sebb]

In any case, if the message String does not give sufficient context to
be able to understand where the message originated, then arguably it's
not a very good message.

On 10 June 2016 at 16:34, Matt Sicker  wrote:
> Oh, I didn't even notice the printStackTrace() part until now. Good point.
>
> On 10 June 2016 at 10:23, Ralph Goers  wrote:
>
>> Matt, there is a big difference between printing the stack trace and
>> walking it to find the info. printing it on every debug call would be
>> insane.
>>
>> Ralph
>>
>> > On Jun 10, 2016, at 8:09 AM, Matt Sicker  wrote:
>> >
>> > Without Java 9, that's pretty much the only way to get the caller line
>> > number and other metadata besides the caller class.
>> >
>> > On 10 June 2016 at 09:44, Jochen Wiedmann 
>> wrote:
>> >
>> >> On Fri, Jun 10, 2016 at 4:02 PM, sebb  wrote:
>> >>
>> >>> Depends on what the implementation does.
>> >>>
>> >>> For example:
>> >>>
>> >>> @Override
>> >>> void debug( String message ){
>> >>>new Throwable(message).printStackTrace();
>> >>> }
>> >>
>> >> Even a dumb application developer like me would at least like to see a
>> >> *bit* of performace. :-)
>> >>
>> >> -
>> >> 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
>>
>>
>
>
> --
> Matt Sicker 

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

Re: [IMAGING] Working towards a release?

[Gary Gregory]

Not ATM. It seems to me we had a little flurry of activity a couple of
years ago but then nothing happened. I remember messages about releasing
what we have as a 1.0 and then following up with a non-BC 2.0 or something
like that.

The issue is time and the need for someone to take a look from a SME POV
and API POV to see if what we have is what we want to put in stone for a
1.0.

Gary

On Fri, Jun 10, 2016 at 2:03 AM, Benedikt Ritter  wrote:

> Hello Gary,
>
> are you planning to roll a (long over due) release for Imaging?
>
> Benedikt
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Commons Math (r)evolution

[Gary Gregory]

I agree with Jörg's email below. Furthermore, to me, the best chance [math]
has a shot to survive and prosper (I'm a glass-half-full kinda guy) is to
stay in Commons in its current single module form (KISS) _because_ a bunch
of [math] developer's have left. We have a bunch of people in Commons that
are smart and _can_ fix _some_ of the problems, can _shepherd_ patches, and
_mentor_ newcomers; all of which could not happen in a new TLP unless all
Commons committers came along.

$2 (inflation)
Gary

On Fri, Jun 10, 2016 at 3:19 AM, Jörg Schaible <
joerg.schai...@bpm-inspire.com> wrote:

> Hi Gilles,
>
> Gilles wrote:
>
> > Hi.
> >
> > On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:
>
> [snip]
>
> >> MATH-172 is about an enhancement. Unfortunately no-one can currently
> >> implement it, so we have to wait until someone can or the issue stays
> >> simply
> >> unresolved again. You've requested for help and that was the proper
> >> action.
> >> However, there has been no problem to release 3.0 in this state, so
> >> why
> >> should it be a problem now for 4.0?
> >
> > Because the context has changed: in 3.0 there was support, now there
> > isn't.
>
>
> That does not state the fact, that the code is already released and it does
> not matter at all if users ask questions for release 3.0 or 4.0.
>
>
> >> MATH-1735 is a bug report for a problem which is currently not
> >> reproducible.
> >> Again you did the right action, but without more input and without a
> >> possibility to reproduce the problem, there's not much we can do.
> >> Again, why
> >> should this issue prevent a release of 4.0?
> >
> > The code in question should not have been in CM. [That was my position
> > back
> > then (cf. archive).]
>
>
> Again, you cannot change history, it is already released. And a new release
> of the code does not make the situation worse.
>
>
> > And every bug report for it is a reminder that unmaintainable code
> > should
> > not be released.
>
>
> That is your interpretation. For me it is a normal bug report and we can
> eigher solve it on our own or have to wait for a contribution.
>
>
> >>> Moreover what could be true for VFS is not for CM where there are
> >>> many,
> >>> many different areas that have nothing in common (except perhaps
> >>> some
> >>> ubiquitous very-low utilities which might be worth their own
> >>> component
> >>> to serve as a, maybe "internal", dependency).
> >>>
> >>> Also, compare the source basic statistics (lines of code):
> >>>VFS  CM
> >>> Java code24215   90834
> >>> Unit tests8926   95595
> >>>
> >>> All in all, CM is more than 5 times larger than VFS (not even
> >>> counting
> >>> documentation).
> >>
> >> Any why is size suddenly a problem?
> >
> > Not suddenly.
> > I've raised this issue for years.  Please look at the archives!
>
>
> Then: Why is size a problem? It is only a problem if *you* try to support
> all of it at once. Nobody expects that.
>
> [snip]
>
>
> >> Fine. But talk about artifacts, not components. Apache Commons Math
> >> is still
> >> *one* component of Apache Commons. It does not matter if you divide
> >> the code
> >> into different artifacts as long as anything is released together.
> >
> > I know.
> >
> > What you can't seem to get to is that I consider it a bad idea to
> > release
> > unsupported code.
>
>
> You've stated that multiple times now.
>
>
> > I think that "I do not know (and nobody else does)" is not an
> > acceptable
> > answer to user requests.
>
>
> See, this is the difference. To me this *is* acceptible. Especially if
> users
> have to be kind of experts themselves to use this code.
>
>
> > If we _know_ that some parts of the code would be unsupported (such
> > that it
> > would elicit this kind of answer for bug reports), then it's
> > _deceiving_ to
> > release that code.
>
>
> A new release does not change the situation at all. With such a definition
> we could move quite some of our components directly to the attic, because
> the original authors are no longer around and we might currently have no
> expert around.
>
>
> >> Individual release cycles for the different parts can only happen if
> >> Math is
> >> TLP, but not in Apache Commons. We will certainly not allow and
> >> create again
> >> any sub-umbrellas (search the Jakarta archives).
> >
> > Who talked about sub-umbrellas?  I didn't.
>
>
> I talk about it, because it is what the result looks to me.
>
>
> > I've explained that
> >   1. CM cannot be released as it was before
>
>
> You've expressed that *you* don't want to release it as it was before
> (well-
> founded however).
>
>
> >   2. for some parts, the necessary _minimal_ support has "disappeared"
>
>
> That does not immediately invalidate the existing code. One fact that you
> don't want to see.
>
>
> >   3. some parts can be turned into independent components (with _full_
> >  support)
>
>
> Have we some kind of agreement here to introduce new Commons components? As
> far as I know, we j

Re: [crypto] Logging dependency

[Ralph Goers]

Now we are getting way off topic, but I would argue that a message that 
contains no specific context information would still be a good message. There 
is nothing wrong with a debug message of logger.debug(“User: {}, userId); as 
this contains all the context information you need to determine where it 
originated.

Generally it is quite a PITA to constantly have to code:

debug(“Performing action X in method foo in class “ + MyClass.class);

It is also more expensive since you are doing String concatenation whether you 
want debug messages or not. Logging frameworks exist to a) make logging easier 
and b) to separate generating the log events from what happens with them. 

The other problem with using a simple debug() construct is that typically you 
will have Application —> library1.method1 
—>library1.method2—>library2.method1—>library3.method1—>debug msg which makes 
it difficult to determine where the message originated if the message only 
contains general information about the error. At least with the typical 
conventions followed when using Loggers you will have a logger name that helps 
identify where the error occurred even without the class, member and line 
number information. But event then, those can be included in the log event if 
the configuration says they should without having to change the code.

Ralph



> On Jun 10, 2016, at 9:09 AM, sebb  wrote:
> 
> In any case, if the message String does not give sufficient context to
> be able to understand where the message originated, then arguably it's
> not a very good message.
> 
> On 10 June 2016 at 16:34, Matt Sicker  wrote:
>> Oh, I didn't even notice the printStackTrace() part until now. Good point.
>> 
>> On 10 June 2016 at 10:23, Ralph Goers  wrote:
>> 
>>> Matt, there is a big difference between printing the stack trace and
>>> walking it to find the info. printing it on every debug call would be
>>> insane.
>>> 
>>> Ralph
>>> 
 On Jun 10, 2016, at 8:09 AM, Matt Sicker  wrote:
 
 Without Java 9, that's pretty much the only way to get the caller line
 number and other metadata besides the caller class.
 
 On 10 June 2016 at 09:44, Jochen Wiedmann 
>>> wrote:
 
> On Fri, Jun 10, 2016 at 4:02 PM, sebb  wrote:
> 
>> Depends on what the implementation does.
>> 
>> For example:
>> 
>> @Override
>> void debug( String message ){
>>   new Throwable(message).printStackTrace();
>> }
> 
> Even a dumb application developer like me would at least like to see a
> *bit* of performace. :-)
> 
> -
> 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
>>> 
>>> 
>> 
>> 
>> --
>> Matt Sicker 
> 
> -
> 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: [Math] Commons Math (r)evolution

[James Carman]

On Fri, Jun 10, 2016 at 12:52 PM Gary Gregory 
wrote:

> I agree with Jörg's email below. Furthermore, to me, the best chance [math]
> has a shot to survive and prosper (I'm a glass-half-full kinda guy) is to
> stay in Commons in its current single module form (KISS) _because_ a bunch
> of [math] developer's have left. We have a bunch of people in Commons that
> are smart and _can_ fix _some_ of the problems, can _shepherd_ patches, and
> _mentor_ newcomers; all of which could not happen in a new TLP unless all
> Commons committers came along.
>
>
So, go be part of the new TLP if you want.  Maybe offer to be the champion
through the incubator?

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[Gary Gregory]

On Fri, Jun 10, 2016 at 7:14 AM, James Carman 
wrote:

> Perhaps I should re-phrase (may not make a difference, but it could).  Can
> we just say that any component that wishes to migrate can feel free to do
> so at this time?  We don't need a VOTE or anything.  If someone gets the
> cycles and inspiration to do so, they can feel free to go right ahead.
> That's what I mean.  I don't mean force everyone to move right now.
>

I think mailing the list for each component is nice. It seems polite, less
overbearing and less brute-force; IOW more community oriented. The VOTE is
nice because it gives folks a few days to voice and record their objection
(I do not plan on objecting ;-). You could [POLL] the list with a "what
components should move" message and then have a single [VOTE].

This is an important change in workflow and I am not sure our release
instruction page is 100% up to date for Git, that needs to happen ASAP,
perhaps _before_ more polling, voting, and migrations take place.

Also as an RM, you'll still need to deal with SVN (the site), so this is
not a panacea for whatever ill some folks have toward SVN.

Gary


>
> On Fri, Jun 10, 2016 at 8:57 AM James Carman 
> wrote:
>
> > Is anyone opposed at this time to moving everything at once?
> >
> > On Fri, Jun 10, 2016 at 8:56 AM Benedikt Ritter 
> > wrote:
> >
> >> Jochen Wiedmann  schrieb am Fr., 10. Juni
> 2016
> >> um 14:14 Uhr:
> >>
> >> > On Fri, Jun 10, 2016 at 9:28 AM, Kristian Rosenvold
> >> >  wrote:
> >> >
> >> > > This vote passes by lazy consensus.
> >> >
> >> > So, again: Who's next?
> >> >
> >>
> >> Pick one you like. How about FileUpload?
> >>
> >>
> >> >
> >> >
> >> >
> >> > --
> >> > The next time you hear: "Don't reinvent the wheel!"
> >> >
> >> >
> >> >
> >>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >> >
> >>
> >
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE][LAZY] Migrate Apache Commons IO to git

[James Carman]

On Fri, Jun 10, 2016 at 1:05 PM Gary Gregory  wrote:

>
> I think mailing the list for each component is nice. It seems polite, less
> overbearing and less brute-force; IOW more community oriented. The VOTE is
> nice because it gives folks a few days to voice and record their objection
> (I do not plan on objecting ;-). You could [POLL] the list with a "what
> components should move" message and then have a single [VOTE].
>
>
If none of us object to the components moving if they see fit, then let's
just say that and avoid the formality.  Sure, a nice heads-up from the
component saying "foo is getting ready to move to Git", but they shouldn't
really need to ask permission if we're all okay with it.


> This is an important change in workflow and I am not sure our release
> instruction page is 100% up to date for Git, that needs to happen ASAP,
> perhaps _before_ more polling, voting, and migrations take place.
>
>
If it was good enough for all that have moved thus far, then it's good
enough for the future ones, I'd think.


> Also as an RM, you'll still need to deal with SVN (the site), so this is
> not a panacea for whatever ill some folks have toward SVN.
>
>
Yep, understood.

Re: [crypto] Logging dependency

[Gary Gregory]

On Fri, Jun 10, 2016 at 3:55 AM, Torsten Curdt  wrote:

> >
> > But I guarantee that there will be other discussions:
> >   Wouldn't you add an "error" method to "Console"?
> > And there we go again...
>
>
> Not quite the same discussions though.
> And I was just saying: it works for me.
>
> As a side note: I personally think libraries should return errors - not log
> them. The error logging should happen in the app - not the library. If you
> have to log errors in the framework there is a good chance your API is not
> how it should be.
>

That's not a good answer for all libraries. For example, I am so happy the
HttpComponents does logging, it has saved me countless hours and headaches.

Gary



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Commons Math (r)evolution

[Gary Gregory]

On Fri, Jun 10, 2016 at 9:56 AM, James Carman 
wrote:

> On Fri, Jun 10, 2016 at 12:52 PM Gary Gregory 
> wrote:
>
> > I agree with Jörg's email below. Furthermore, to me, the best chance
> [math]
> > has a shot to survive and prosper (I'm a glass-half-full kinda guy) is to
> > stay in Commons in its current single module form (KISS) _because_ a
> bunch
> > of [math] developer's have left. We have a bunch of people in Commons
> that
> > are smart and _can_ fix _some_ of the problems, can _shepherd_ patches,
> and
> > _mentor_ newcomers; all of which could not happen in a new TLP unless all
> > Commons committers came along.
> >
> >
> So, go be part of the new TLP if you want.  Maybe offer to be the champion
> through the incubator?
>

That's backward from what I am proposing above. I must have not expressed
myself well enough. Where is my coffee?!

G



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Commons Math (r)evolution

[Jörg Schaible]

Hi Gary,

Gary Gregory wrote:

> I agree with Jörg's email below. Furthermore, to me, the best chance
> [math] has a shot to survive and prosper (I'm a glass-half-full kinda guy)
> is to stay in Commons in its current single module form (KISS) _because_ a
> bunch of [math] developer's have left. We have a bunch of people in
> Commons that are smart and _can_ fix _some_ of the problems, can
> _shepherd_ patches, and _mentor_ newcomers; all of which could not happen
> in a new TLP unless all Commons committers came along.


For me, we have two options: Either keep it as one component that contains 
all of the current stuff or go TLP and split it into individual components.

Gilles cannot live with the former and we do not have a community left for 
the latter. Catch-22.

Cheers,
Jörg


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

Re: [Math] Commons Math (r)evolution

[Gary Gregory]

On Fri, Jun 10, 2016 at 11:00 AM, Jörg Schaible 
wrote:

> Hi Gary,
>
> Gary Gregory wrote:
>
> > I agree with Jörg's email below. Furthermore, to me, the best chance
> > [math] has a shot to survive and prosper (I'm a glass-half-full kinda
> guy)
> > is to stay in Commons in its current single module form (KISS) _because_
> a
> > bunch of [math] developer's have left. We have a bunch of people in
> > Commons that are smart and _can_ fix _some_ of the problems, can
> > _shepherd_ patches, and _mentor_ newcomers; all of which could not happen
> > in a new TLP unless all Commons committers came along.
>
>
> For me, we have two options: Either keep it as one component that contains
> all of the current stuff or go TLP and split it into individual components.
>
> Gilles cannot live with the former and we do not have a community left for
> the latter. Catch-22.
>

But not C22 really, math] stays where it is, and we make the best of it.

One thing we could do (once we get done with BCEL IMO, so we can all help
and do the best there), is to release a math 3.6.2 or 4.0.

Gary


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

> On Jun 10, 2016, at 11:00 AM, Jörg Schaible  wrote:
> 
> Hi Gary,
> 
> Gary Gregory wrote:
> 
>> I agree with Jörg's email below. Furthermore, to me, the best chance
>> [math] has a shot to survive and prosper (I'm a glass-half-full kinda guy)
>> is to stay in Commons in its current single module form (KISS) _because_ a
>> bunch of [math] developer's have left. We have a bunch of people in
>> Commons that are smart and _can_ fix _some_ of the problems, can
>> _shepherd_ patches, and _mentor_ newcomers; all of which could not happen
>> in a new TLP unless all Commons committers came along.
> 
> 
> For me, we have two options: Either keep it as one component that contains 
> all of the current stuff or go TLP and split it into individual components.
> 
> Gilles cannot live with the former and we do not have a community left for 
> the latter. Catch-22.
> 

There is no catch-22. Gilles can move Commons Math to a TLP and split it up 
once he has enough of a community to move it.  Until then he can work on 
whatever portions of the code he wants or not as he chooses.

If there is a catch-22 it is that the community that gets built up around the 
current code may not want to split it up.

Ralph



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

Re: [Math] Commons Math (r)evolution

[James Carman]

We already voted to make it go TLP and it passed.  The original chair of
the new project isn't available any more.  Gilles, are you willing to chair
the new project?  Is anyone else willing to help Gilles perhaps take Math
through the incubator to gather more momentum?  Can we perhaps reach out to
the incubator PMC and ask them for guidance on if this is even a good idea?



On Fri, Jun 10, 2016 at 2:22 PM Ralph Goers 
wrote:

>
> > On Jun 10, 2016, at 11:00 AM, Jörg Schaible 
> wrote:
> >
> > Hi Gary,
> >
> > Gary Gregory wrote:
> >
> >> I agree with Jörg's email below. Furthermore, to me, the best chance
> >> [math] has a shot to survive and prosper (I'm a glass-half-full kinda
> guy)
> >> is to stay in Commons in its current single module form (KISS)
> _because_ a
> >> bunch of [math] developer's have left. We have a bunch of people in
> >> Commons that are smart and _can_ fix _some_ of the problems, can
> >> _shepherd_ patches, and _mentor_ newcomers; all of which could not
> happen
> >> in a new TLP unless all Commons committers came along.
> >
> >
> > For me, we have two options: Either keep it as one component that
> contains
> > all of the current stuff or go TLP and split it into individual
> components.
> >
> > Gilles cannot live with the former and we do not have a community left
> for
> > the latter. Catch-22.
> >
>
> There is no catch-22. Gilles can move Commons Math to a TLP and split it
> up once he has enough of a community to move it.  Until then he can work on
> whatever portions of the code he wants or not as he chooses.
>
> If there is a catch-22 it is that the community that gets built up around
> the current code may not want to split it up.
>
> Ralph
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

Not only is the original chair not available, neither is a quorum of the 
proposed PMC.  Why are you pushing this?  I, for one, am perfectly content to 
keep Math here and see if those who have expressed interest in helping out 
actually do and if others are attracted to fill in the gaps.

Ralph

> On Jun 10, 2016, at 11:54 AM, James Carman  wrote:
> 
> We already voted to make it go TLP and it passed.  The original chair of
> the new project isn't available any more.  Gilles, are you willing to chair
> the new project?  Is anyone else willing to help Gilles perhaps take Math
> through the incubator to gather more momentum?  Can we perhaps reach out to
> the incubator PMC and ask them for guidance on if this is even a good idea?
> 
> 
> 
> On Fri, Jun 10, 2016 at 2:22 PM Ralph Goers 
> wrote:
> 
>> 
>>> On Jun 10, 2016, at 11:00 AM, Jörg Schaible 
>> wrote:
>>> 
>>> Hi Gary,
>>> 
>>> Gary Gregory wrote:
>>> 
 I agree with Jörg's email below. Furthermore, to me, the best chance
 [math] has a shot to survive and prosper (I'm a glass-half-full kinda
>> guy)
 is to stay in Commons in its current single module form (KISS)
>> _because_ a
 bunch of [math] developer's have left. We have a bunch of people in
 Commons that are smart and _can_ fix _some_ of the problems, can
 _shepherd_ patches, and _mentor_ newcomers; all of which could not
>> happen
 in a new TLP unless all Commons committers came along.
>>> 
>>> 
>>> For me, we have two options: Either keep it as one component that
>> contains
>>> all of the current stuff or go TLP and split it into individual
>> components.
>>> 
>>> Gilles cannot live with the former and we do not have a community left
>> for
>>> the latter. Catch-22.
>>> 
>> 
>> There is no catch-22. Gilles can move Commons Math to a TLP and split it
>> up once he has enough of a community to move it.  Until then he can work on
>> whatever portions of the code he wants or not as he chooses.
>> 
>> If there is a catch-22 it is that the community that gets built up around
>> the current code may not want to split it up.
>> 
>> Ralph
>> 
>> 
>> 
>> -
>> 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: [Math] Commons Math (r)evolution

[Jochen Wiedmann]

>> On Jun 10, 2016, at 11:54 AM, James Carman  
>> wrote:
>>
>> We already voted to make it go TLP and it passed.  The original chair of
>> the new project isn't available any more.  Gilles, are you willing to chair
>> the new project?  Is anyone else willing to help Gilles perhaps take Math
>> through the incubator to gather more momentum?  Can we perhaps reach out to
>> the incubator PMC and ask them for guidance on if this is even a good idea?

Being the latest member of the IPMC, I will forward that question. I'd
also be willing to act as a mentor, and project member.

Jochen


-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [Math] Commons Math (r)evolution

[James Carman]

On Fri, Jun 10, 2016 at 3:29 PM Ralph Goers 
wrote:

> Not only is the original chair not available, neither is a quorum of the
> proposed PMC.  Why are you pushing this?  I, for one, am perfectly content
> to keep Math here and see if those who have expressed interest in helping
> out actually do and if others are attracted to fill in the gaps.
>
>
I am pushing for it because I think it's the right thing to do for Math
going forward.  Just like I pushed for it for years until we finally had an
affirmative vote.  The fact that the others have left doesn't change my
mind.  It only makes it more important, IMHO.  We need a more diverse
community for Math.  It also needs to self-govern, however it sees fit.
Being its own TLP will help attract more attention (especially with a trip
through the incubator).  I would love to get involved with Math if they'd
have me.  I was a math major in college, but I'm nowhere near the expert
that these guys are I'm sure.  I could provide value as a general Java
language and API resource, though.  If you're interested in Math, Ralph,
why not come join us?

Re: [crypto] Logging dependency

[Torsten Curdt]

>
> > Exactly. It's so simple and it doesn't introduce any deps.
> > Whether that's goal one can align with is another matter.
> > But it means no logging framework discussions anymore ;)
>
> The disadvantage of this approach is that you loose the location
> information - every log event will come from your debug method instead of
> the code actually doing the logging.
>
>
Just pop it off the stack. Not sure that's a valid concern.

Re: [crypto] Logging dependency

[Torsten Curdt]

> Matt, there is a big difference between printing the stack trace and
> walking it to find the info. printing it on every debug call would be
> insane.
>

Why would anyone want to do that?

https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html


And how do you think the logging frameworks get that kind of information? :)

Re: [crypto] Logging dependency

[Torsten Curdt]

> Now we are getting way off topic, but I would argue that a message that
> contains no specific context information would still be a good message.
> There is nothing wrong with a debug message of logger.debug(“User: {},
> userId); as this contains all the context information you need to determine
> where it originated.
>
> Generally it is quite a PITA to constantly have to code:
>
> debug(“Performing action X in method foo in class “ + MyClass.class);
>

1. We are talking about a library.
2. There are ways to access the stack if you really want to



> It is also more expensive since you are doing String concatenation whether
> you want debug messages or not. Logging frameworks exist to a) make logging
> easier and b) to separate generating the log events from what happens with
> them.
>

This is only a problem if you assume to be constantly logging everything -
which you might be a fan of. I am not (for a library).



> The other problem with using a simple debug() construct is that typically
> you will have Application —> library1.method1
> —>library1.method2—>library2.method1—>library3.method1—>debug msg which
> makes it difficult to determine where the message originated if the message
> only contains general information about the error.


Sorry - don't get that.

Re: [crypto] Logging dependency

[Torsten Curdt]

>
> > As a side note: I personally think libraries should return errors - not
> log
> > them. The error logging should happen in the app - not the library. If
> you
> > have to log errors in the framework there is a good chance your API is
> not
> > how it should be.
> >
>
> That's not a good answer for all libraries. For example, I am so happy the
> HttpComponents does logging, it has saved me countless hours and headaches.
>

If you think so that's fine - I am fine to disagree :)
For me it's a sign that the API and/or the error reporting is not quite
right.

Re: [Math] Commons Math (r)evolution

[Gilles]

Hello Jörg.

On Fri, 10 Jun 2016 12:19:56 +0200, Jörg Schaible wrote:

Hi Gilles,

Gilles wrote:


Hi.

On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:


[snip]

MATH-172 is about an enhancement. Unfortunately no-one can 
currently
implement it, so we have to wait until someone can or the issue 
stays

simply
unresolved again. You've requested for help and that was the proper
action.
However, there has been no problem to release 3.0 in this state, so
why
should it be a problem now for 4.0?


Because the context has changed: in 3.0 there was support, now there
isn't.



That does not state the fact, that the code is already released and 
it does

not matter at all if users ask questions for release 3.0 or 4.0.


In practice, you may be right; but I think that it does matter in a
situation such as this one (which is not common - at least, it's the
first time I see a fork).

Let me recall that the [math] consensus has been (for years): one line
of development.
This was changed, without formal consensus, supposedly in order to
_support_ legacy users.

In my mind this support was acceptable for bug-fixes only (according
to the consensus).

This support can still exist and, for v3.6.x, I agree with you.

But for v4.0, I'm not going to give one more minute to maintain code
that is either bad, or outdated.

As others have said, we lost contributors on that fanaticism about
unproven scenarios.

If you want to keep CM as is (for who knows what future), that's fine
for you and anyone who is happy working with that code.

I'm not happy with the status quo.
The fork could have been an opportunity to try something new.


MATH-1735 is a bug report for a problem which is currently not
reproducible.
Again you did the right action, but without more input and without 
a

possibility to reproduce the problem, there's not much we can do.
Again, why
should this issue prevent a release of 4.0?


The code in question should not have been in CM. [That was my 
position

back
then (cf. archive).]



Again, you cannot change history, it is already released. And a new 
release

of the code does not make the situation worse.


Every major release of Commons Math broke (sometimes many) things.
If it didn't, a major release wouldn't have been necessary.

Not making a new release of  is in no way taking something
from the users.


And every bug report for it is a reminder that unmaintainable code
should
not be released.



That is your interpretation. For me it is a normal bug report and we 
can

eigher solve it on our own or have to wait for a contribution.


So, IIUC, you'd release knowingly buggy code.
That makes no sense to me; so, I'm not going to be part of this.


Moreover what could be true for VFS is not for CM where there are
many,
many different areas that have nothing in common (except perhaps
some
ubiquitous very-low utilities which might be worth their own
component
to serve as a, maybe "internal", dependency).

Also, compare the source basic statistics (lines of code):
   VFS  CM
Java code24215   90834
Unit tests8926   95595

All in all, CM is more than 5 times larger than VFS (not even
counting
documentation).


Any why is size suddenly a problem?


Not suddenly.
I've raised this issue for years.  Please look at the archives!



Then: Why is size a problem? It is only a problem if *you* try to 
support

all of it at once. Nobody expects that.


I, as a user, expect that.

I chose to use Commons Math, and advertised it to others (to my
current dismay), because of the *outstanding* support I knew I
would get in case of bugs or requests for enhancement.

I do not want to work on a project that is either going to die,
or become legacy (and then dead/dormant/whatever).


[snip]



Fine. But talk about artifacts, not components. Apache Commons Math
is still
*one* component of Apache Commons. It does not matter if you divide
the code
into different artifacts as long as anything is released together.


I know.

What you can't seem to get to is that I consider it a bad idea to
release
unsupported code.



You've stated that multiple times now.



I think that "I do not know (and nobody else does)" is not an
acceptable
answer to user requests.



See, this is the difference. To me this *is* acceptible. Especially 
if users

have to be kind of experts themselves to use this code.


I don't agree with that.

Moreover, how could a maintainer be confident that a fix provided by 
some

user is correct if he doesn't have the slightest idea about the code?

To get to any level of confidence starting from scratch is a huge time
sink; I don't have this time anymore.


If we _know_ that some parts of the code would be unsupported (such
that it
would elicit this kind of answer for bug reports), then it's
_deceiving_ to
release that code.



A new release does not change the situation at all. With such a 
definition
we could move quite some of our components directly to the attic, 
because
the original authors 

RE: [Math] Commons Math (r)evolution

[Gilles]

Hi Patrick, and others.

On Fri, 10 Jun 2016 07:37:00 -0400, Patrick Meyer wrote:

I think it would be better to spend the time trying to recruit new
contributors than it would be to alienate existing ones.


By what are you alienated?
[This is addressed to all readers and would-be contributors to
the Commons project.]

Are there, among the readers, people who'd step forward to take
all the CM codebase, and start the process towards a TLP?

Are there people, among the CM contributors (or willing to
contribute) opposed to having the "Random Number Generator"
functionality being split off of the CM codebase.

Are there people opposed to the same concerning the functionality
based around the complex numbers?

Are there people opposed to the refactoring of the "o.a.c.m.ml"
package (which is likely to break all applications currently
using it)?


Also, the
effort required to divide the library into smaller parts


In some cases, the effort is worth it.
In the first case I want to submit (RNG), the effort was done already;
and for that reason also (in addition to the objective bonuses), I want
to see this code released sooner than later (or never).


would be
better spent creating patches.


Patches welcome. ;-)


Does anyone have ideas for actively recruiting contributors?


Contributors will (maybe) come to a project they like; as noted
by others, they (certainly) won't come where there is no fun.

Then some people come and ask: "What is the roadmap?". There was
none.  It was impossible because of the unlimited scope, the
lack of resources, the wildly different priorities, etc.


Do you
know of mathematics departments that also teach students Java
programming? A recruiting campaign with the message like "here's what
we do at CM, we'd like your help" could attract new contributors.


What do we do?
Let's see the actual message.

I am well placed to remind that CM as it was "practiced" did not
attract many people. [At a talk (FOSDEM), four years ago, one of the
questions was about the Java version; we were well into the Java 7
era; a telling silence followed Thomas Neidhart's answer that the
"consensus" was to stick to... Java 5. From an audience of more than
60 people, zero contributor.]


It
will take time, but a constructive approach like this one will do 
more

to sustain CM.


This is something to explore.  Are you going to do it?

How are you so sure that "it will do more" that what I propose,
which is in fact quite constructive.

I understand that you may be angry by this long chain of mails.
But please do not shoot at the bearer of bad news.

Regards,
Gilles


Thanks,
Patrick

-Original Message-
From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com]
Sent: Friday, June 10, 2016 6:20 AM
To: dev@commons.apache.org
Subject: Re: [Math] Commons Math (r)evolution

Hi Gilles,

Gilles wrote:


Hi.

On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:


[snip]

MATH-172 is about an enhancement. Unfortunately no-one can 
currently
implement it, so we have to wait until someone can or the issue 
stays

simply unresolved again. You've requested for help and that was the
proper action.
However, there has been no problem to release 3.0 in this state, so
why should it be a problem now for 4.0?


Because the context has changed: in 3.0 there was support, now there
isn't.



That does not state the fact, that the code is already released and
it does not matter at all if users ask questions for release 3.0 or
4.0.



MATH-1735 is a bug report for a problem which is currently not
reproducible.
Again you did the right action, but without more input and without 
a

possibility to reproduce the problem, there's not much we can do.
Again, why
should this issue prevent a release of 4.0?


The code in question should not have been in CM. [That was my 
position

back
then (cf. archive).]



Again, you cannot change history, it is already released. And a new 
release

of the code does not make the situation worse.



And every bug report for it is a reminder that unmaintainable code
should
not be released.



That is your interpretation. For me it is a normal bug report and we 
can

eigher solve it on our own or have to wait for a contribution.



Moreover what could be true for VFS is not for CM where there are
many,
many different areas that have nothing in common (except perhaps
some
ubiquitous very-low utilities which might be worth their own
component
to serve as a, maybe "internal", dependency).

Also, compare the source basic statistics (lines of code):
   VFS  CM
Java code24215   90834
Unit tests8926   95595

All in all, CM is more than 5 times larger than VFS (not even
counting
documentation).


Any why is size suddenly a problem?


Not suddenly.
I've raised this issue for years.  Please look at the archives!



Then: Why is size a problem? It is only a problem if *you* try to 
support

all of it at once. Nobody expects that.

[snip]



Fine. But talk about artifacts, not component

[bcel] console logging

[Gary Gregory]

I see this in [bcel]:

System.out.println(buf.toString());
e.printStackTrace();

Should that be left in there or removed?

Gary

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

[Niall Pemberton]

On Thu, Jun 9, 2016 at 8:22 AM, Benedikt Ritter  wrote:

> Why? This was a good idea.
>

The links didn't get generated properly when I looked at it in the staging
area - instead of "http://commons.apache.org/proper/commons-crypto/"; it was
generating "http://commons.apache.org/crypto/"; and I couldn't see what was
going wrong - so I reverted it for now.

Niall



>
>  schrieb am Do., 9. Juni 2016 um 02:48:
>
> > Author: niallp
> > Date: Thu Jun  9 00:48:17 2016
> > New Revision: 1747476
> >
> > URL: http://svn.apache.org/viewvc?rev=1747476&view=rev
> > Log:
> > Revert Crypto changes
> >
> > Modified:
> > commons/cms-site/trunk/content/site.xml
> > commons/cms-site/trunk/content/xdoc/components.xml
> > commons/cms-site/trunk/content/xdoc/index.xml.vm
> >
> > Modified: commons/cms-site/trunk/content/site.xml
> > URL:
> >
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/site.xml?rev=1747476&r1=1747475&r2=1747476&view=diff
> >
> >
> ==
> > --- commons/cms-site/trunk/content/site.xml (original)
> > +++ commons/cms-site/trunk/content/site.xml Thu Jun  9 00:48:17 2016
> > @@ -54,7 +54,6 @@
> >  
> >  
> >  
> > -
> >  
> >  
> >  
> >
> > Modified: commons/cms-site/trunk/content/xdoc/components.xml
> > URL:
> >
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/components.xml?rev=1747476&r1=1747475&r2=1747476&view=diff
> >
> >
> ==
> > --- commons/cms-site/trunk/content/xdoc/components.xml (original)
> > +++ commons/cms-site/trunk/content/xdoc/components.xml Thu Jun  9
> 00:48:17
> > 2016
> > @@ -55,8 +55,6 @@
> >  Defines an API for working with tar, zip and bzip2
> > files.
> >  Configuration
> >  Reading of configuration/preferences files in various
> > formats.
> > -Crypto
> > -A cryptographic library optimized with AES-NI wrapping
> > Openssl or JCE algorithm implementations
> >  CSV
> >  Component for reading and writing comma separated value
> > files.
> >  Daemon
> >
> > Modified: commons/cms-site/trunk/content/xdoc/index.xml.vm
> > URL:
> >
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/index.xml.vm?rev=1747476&r1=1747475&r2=1747476&view=diff
> >
> >
> ==
> > --- commons/cms-site/trunk/content/xdoc/index.xml.vm (original)
> > +++ commons/cms-site/trunk/content/xdoc/index.xml.vm Thu Jun  9 00:48:17
> > 2016
> > @@ -119,9 +119,6 @@
> >   > href="proper/commons-configuration/">Configuration
> >  Reading of configuration/preferences files in various
> > formats.
> >
> >  ${configurationVersion}${configurationReleased}
> > -Crypto
> > -A cryptographic library optimized with AES-NI wrapping
> > Openssl or JCE algorithm implementations.
> > -${cryptoVersion}${cryptoReleased}
> >  CSV
> >  Component for reading and writing comma separated value
> > files.
> >  ${csvVersion}${csvReleased}
> >
> >
> >
>

Re: [bcel] console logging

[sebb]

On 11 June 2016 at 00:15, Gary Gregory  wrote:
> I see this in [bcel]:
>
> System.out.println(buf.toString());
> e.printStackTrace();
>
> Should that be left in there or removed?

Where is it?

> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

[sebb]

On 11 June 2016 at 00:31, Niall Pemberton  wrote:
> On Thu, Jun 9, 2016 at 8:22 AM, Benedikt Ritter  wrote:
>
>> Why? This was a good idea.
>>
>
> The links didn't get generated properly when I looked at it in the staging
> area - instead of "http://commons.apache.org/proper/commons-crypto/"; it was
> generating "http://commons.apache.org/crypto/"; and I couldn't see what was
> going wrong - so I reverted it for now.

That *was* OK - there's a missing redirect to fix the URL.

http://commons.apache.org/crypto/
should redirect to
http://commons.apache.org/proper/commons-crypto/

as is done for

http://commons.apache.org/lang/

etc.

I should be able to fix that shortly.

> Niall
>
>
>
>>
>>  schrieb am Do., 9. Juni 2016 um 02:48:
>>
>> > Author: niallp
>> > Date: Thu Jun  9 00:48:17 2016
>> > New Revision: 1747476
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1747476&view=rev
>> > Log:
>> > Revert Crypto changes
>> >
>> > Modified:
>> > commons/cms-site/trunk/content/site.xml
>> > commons/cms-site/trunk/content/xdoc/components.xml
>> > commons/cms-site/trunk/content/xdoc/index.xml.vm
>> >
>> > Modified: commons/cms-site/trunk/content/site.xml
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/site.xml?rev=1747476&r1=1747475&r2=1747476&view=diff
>> >
>> >
>> ==
>> > --- commons/cms-site/trunk/content/site.xml (original)
>> > +++ commons/cms-site/trunk/content/site.xml Thu Jun  9 00:48:17 2016
>> > @@ -54,7 +54,6 @@
>> >  
>> >  
>> >  
>> > -
>> >  
>> >  
>> >  
>> >
>> > Modified: commons/cms-site/trunk/content/xdoc/components.xml
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/components.xml?rev=1747476&r1=1747475&r2=1747476&view=diff
>> >
>> >
>> ==
>> > --- commons/cms-site/trunk/content/xdoc/components.xml (original)
>> > +++ commons/cms-site/trunk/content/xdoc/components.xml Thu Jun  9
>> 00:48:17
>> > 2016
>> > @@ -55,8 +55,6 @@
>> >  Defines an API for working with tar, zip and bzip2
>> > files.
>> >  Configuration
>> >  Reading of configuration/preferences files in various
>> > formats.
>> > -Crypto
>> > -A cryptographic library optimized with AES-NI wrapping
>> > Openssl or JCE algorithm implementations
>> >  CSV
>> >  Component for reading and writing comma separated value
>> > files.
>> >  Daemon
>> >
>> > Modified: commons/cms-site/trunk/content/xdoc/index.xml.vm
>> > URL:
>> >
>> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/index.xml.vm?rev=1747476&r1=1747475&r2=1747476&view=diff
>> >
>> >
>> ==
>> > --- commons/cms-site/trunk/content/xdoc/index.xml.vm (original)
>> > +++ commons/cms-site/trunk/content/xdoc/index.xml.vm Thu Jun  9 00:48:17
>> > 2016
>> > @@ -119,9 +119,6 @@
>> >  > > href="proper/commons-configuration/">Configuration
>> >  Reading of configuration/preferences files in various
>> > formats.
>> >
>> >  ${configurationVersion}${configurationReleased}
>> > -Crypto
>> > -A cryptographic library optimized with AES-NI wrapping
>> > Openssl or JCE algorithm implementations.
>> > -${cryptoVersion}${cryptoReleased}
>> >  CSV
>> >  Component for reading and writing comma separated value
>> > files.
>> >  ${csvVersion}${csvReleased}
>> >
>> >
>> >
>>

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

Re: [Math] Commons Math (r)evolution

[Gilles]

Hi James.

On Fri, 10 Jun 2016 20:26:07 +, James Carman wrote:
On Fri, Jun 10, 2016 at 3:29 PM Ralph Goers 


wrote:

Not only is the original chair not available, neither is a quorum of 
the
proposed PMC.  Why are you pushing this?  I, for one, am perfectly 
content
to keep Math here and see if those who have expressed interest in 
helping

out actually do and if others are attracted to fill in the gaps.


I am pushing for it because I think it's the right thing to do for 
Math
going forward.  Just like I pushed for it for years until we finally 
had an
affirmative vote.  The fact that the others have left doesn't change 
my

mind.  It only makes it more important, IMHO.  We need a more diverse
community for Math.  It also needs to self-govern, however it sees 
fit.
Being its own TLP will help attract more attention (especially with a 
trip
through the incubator).  I would love to get involved with Math if 
they'd
have me.  I was a math major in college, but I'm nowhere near the 
expert
that these guys are I'm sure.  I could provide value as a general 
Java
language and API resource, though.  If you're interested in Math, 
Ralph,

why not come join us?


Things moved a few steps further while I was thinking about my two
last posts...

Of course, if the majority considers that TLP is more promising
than new components here, I'm fine, since anything is better than
the status quo.

If it goes that way, I suggest that you become the chairperson,
since
 1. it wouldn't have happened without your intervention, and
 2. from a practical POV, better have someone who knows his way
around Apache...

About the project's contents, I'm still not optimistic that a TLP
does change the underlying reality of the situation which I tried
to describe.
For the sake of the argument, let's assume that Jörg and Ralph
would join us in a TLP that will decide what to do with the
Commons Math codebase, will they now change their mind (in that
parts of it can be released and others not)?

Thanks for succeeding in advancing a discussion that seemed
stuck (perhaps because of my perpetual misunderstanding of
the "Commons" project).

Gilles


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

Re: svn commit: r1747476 - in /commons/cms-site/trunk/content: site.xml xdoc/components.xml xdoc/index.xml.vm

[Niall Pemberton]

On Sat, Jun 11, 2016 at 12:37 AM, sebb  wrote:

> On 11 June 2016 at 00:31, Niall Pemberton 
> wrote:
> > On Thu, Jun 9, 2016 at 8:22 AM, Benedikt Ritter 
> wrote:
> >
> >> Why? This was a good idea.
> >>
> >
> > The links didn't get generated properly when I looked at it in the
> staging
> > area - instead of "http://commons.apache.org/proper/commons-crypto/"; it
> was
> > generating "http://commons.apache.org/crypto/"; and I couldn't see what
> was
> > going wrong - so I reverted it for now.
>
> That *was* OK - there's a missing redirect to fix the URL.
>
> http://commons.apache.org/crypto/
> should redirect to
> http://commons.apache.org/proper/commons-crypto/
>
> as is done for
>
> http://commons.apache.org/lang/
>
> etc.
>
> I should be able to fix that shortly.
>

Thanks Sebb, I've put it back and published the site - links all working

Niall



>
> > Niall
> >
> >
> >
> >>
> >>  schrieb am Do., 9. Juni 2016 um 02:48:
> >>
> >> > Author: niallp
> >> > Date: Thu Jun  9 00:48:17 2016
> >> > New Revision: 1747476
> >> >
> >> > URL: http://svn.apache.org/viewvc?rev=1747476&view=rev
> >> > Log:
> >> > Revert Crypto changes
> >> >
> >> > Modified:
> >> > commons/cms-site/trunk/content/site.xml
> >> > commons/cms-site/trunk/content/xdoc/components.xml
> >> > commons/cms-site/trunk/content/xdoc/index.xml.vm
> >> >
> >> > Modified: commons/cms-site/trunk/content/site.xml
> >> > URL:
> >> >
> >>
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/site.xml?rev=1747476&r1=1747475&r2=1747476&view=diff
> >> >
> >> >
> >>
> ==
> >> > --- commons/cms-site/trunk/content/site.xml (original)
> >> > +++ commons/cms-site/trunk/content/site.xml Thu Jun  9 00:48:17 2016
> >> > @@ -54,7 +54,6 @@
> >> >  
> >> >  
> >> >  
> >> > -
> >> >  
> >> >  
> >> >  
> >> >
> >> > Modified: commons/cms-site/trunk/content/xdoc/components.xml
> >> > URL:
> >> >
> >>
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/components.xml?rev=1747476&r1=1747475&r2=1747476&view=diff
> >> >
> >> >
> >>
> ==
> >> > --- commons/cms-site/trunk/content/xdoc/components.xml (original)
> >> > +++ commons/cms-site/trunk/content/xdoc/components.xml Thu Jun  9
> >> 00:48:17
> >> > 2016
> >> > @@ -55,8 +55,6 @@
> >> >  Defines an API for working with tar, zip and bzip2
> >> > files.
> >> >  Configuration
> >> >  Reading of configuration/preferences files in various
> >> > formats.
> >> > -Crypto
> >> > -A cryptographic library optimized with AES-NI
> wrapping
> >> > Openssl or JCE algorithm implementations
> >> >  CSV
> >> >  Component for reading and writing comma separated
> value
> >> > files.
> >> >  Daemon
> >> >
> >> > Modified: commons/cms-site/trunk/content/xdoc/index.xml.vm
> >> > URL:
> >> >
> >>
> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/index.xml.vm?rev=1747476&r1=1747475&r2=1747476&view=diff
> >> >
> >> >
> >>
> ==
> >> > --- commons/cms-site/trunk/content/xdoc/index.xml.vm (original)
> >> > +++ commons/cms-site/trunk/content/xdoc/index.xml.vm Thu Jun  9
> 00:48:17
> >> > 2016
> >> > @@ -119,9 +119,6 @@
> >> >   >> > href="proper/commons-configuration/">Configuration
> >> >  Reading of configuration/preferences files in various
> >> > formats.
> >> >
> >> >
> ${configurationVersion}${configurationReleased}
> >> > -Crypto
> >> > -A cryptographic library optimized with AES-NI
> wrapping
> >> > Openssl or JCE algorithm implementations.
> >> > -${cryptoVersion}${cryptoReleased}
> >> >  CSV
> >> >  Component for reading and writing comma separated
> value
> >> > files.
> >> >  ${csvVersion}${csvReleased}
> >> >
> >> >
> >> >
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [bcel] console logging

[Gary Gregory]

On Fri, Jun 10, 2016 at 4:33 PM, sebb  wrote:

> On 11 June 2016 at 00:15, Gary Gregory  wrote:
> > I see this in [bcel]:
> >
> > System.out.println(buf.toString());
> > e.printStackTrace();
> >
> > Should that be left in there or removed?
>
> Where is it?
>

org.apache.bcel.classfile.Utility.codeToString(byte[], ConstantPool, int,
int, boolean)

there are a LOT of references to System.out.

Gary


>
> > Gary
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 
> > JUnit in Action, Second Edition 
> > Spring Batch in Action 
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [bcel] console logging

[sebb]

On 11 June 2016 at 01:41, Gary Gregory  wrote:
> On Fri, Jun 10, 2016 at 4:33 PM, sebb  wrote:
>
>> On 11 June 2016 at 00:15, Gary Gregory  wrote:
>> > I see this in [bcel]:
>> >
>> > System.out.println(buf.toString());
>> > e.printStackTrace();
>> >
>> > Should that be left in there or removed?
>>
>> Where is it?
>>
>
> org.apache.bcel.classfile.Utility.codeToString(byte[], ConstantPool, int,
> int, boolean)
>
> there are a LOT of references to System.out.

I counted ONE.
System.err = 2

There are lots of calls to out.println but out is provided by the caller.

> Gary
>
>
>>
>> > Gary
>> >
>> > --
>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> > Java Persistence with Hibernate, Second Edition
>> > 
>> > JUnit in Action, Second Edition 
>> > Spring Batch in Action 
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [Math] Commons Math (r)evolution

[Rob Tompkins]

As someone relatively new to the project, I feel like my statement here may 
have a little weight. First, I do really want to help in whatever capacity I am 
able (given that I’m a tad over-run currently with a new[ish] 2-month-old 
baby). That said, I am perfectly willing to contribute in whatever direction 
folks decide to go. 

Pardon for my potentially restating the obvious, but it seems to me that the 
three main contributors to the project have split off because of what they see 
as headaches in the fact that they were necessarily coupled to Apache Commons. 
Meanwhile, we sit with the code they decided to leave.

Now the two questions standing in my mind are: what will the user base do, and 
what will the Hipparchus folks do if the project was indeed TLP’d? If I had to 
guess at the the first, people using the library may tend towards sticking with 
commons-math simply because it is housed by Apache. Further, I would guess, 
maybe naively through, that without the Apache “brand” Hipparchus may have 
difficulty gaining traction. On the second question, I would hope that if we 
did TLP the project that the Hipparchus folks would return to assist, but maybe 
they find it free-er out there in the “wide open air."

With that all in mind, my thought might be to do something like try to get out 
3.7 and 3.8, while in parallel trying to jump through the requisite hoops to 
become a TLP hoping that more folks hop on board.

Just the thoughts running through my mind, and I my plan is to be willing to 
help regardless of direction.

Hope that helps,
-Rob


> On Jun 10, 2016, at 6:55 PM, Gilles  wrote:
> 
> Hi Patrick, and others.
> 
> On Fri, 10 Jun 2016 07:37:00 -0400, Patrick Meyer wrote:
>> I think it would be better to spend the time trying to recruit new
>> contributors than it would be to alienate existing ones.
> 
> By what are you alienated?
> [This is addressed to all readers and would-be contributors to
> the Commons project.]
> 
> Are there, among the readers, people who'd step forward to take
> all the CM codebase, and start the process towards a TLP?
> 
> Are there people, among the CM contributors (or willing to
> contribute) opposed to having the "Random Number Generator"
> functionality being split off of the CM codebase.
> 
> Are there people opposed to the same concerning the functionality
> based around the complex numbers?
> 
> Are there people opposed to the refactoring of the "o.a.c.m.ml"
> package (which is likely to break all applications currently
> using it)?
> 
>> Also, the
>> effort required to divide the library into smaller parts
> 
> In some cases, the effort is worth it.
> In the first case I want to submit (RNG), the effort was done already;
> and for that reason also (in addition to the objective bonuses), I want
> to see this code released sooner than later (or never).
> 
>> would be
>> better spent creating patches.
> 
> Patches welcome. ;-)
> 
>> Does anyone have ideas for actively recruiting contributors?
> 
> Contributors will (maybe) come to a project they like; as noted
> by others, they (certainly) won't come where there is no fun.
> 
> Then some people come and ask: "What is the roadmap?". There was
> none.  It was impossible because of the unlimited scope, the
> lack of resources, the wildly different priorities, etc.
> 
>> Do you
>> know of mathematics departments that also teach students Java
>> programming? A recruiting campaign with the message like "here's what
>> we do at CM, we'd like your help" could attract new contributors.
> 
> What do we do?
> Let's see the actual message.
> 
> I am well placed to remind that CM as it was "practiced" did not
> attract many people. [At a talk (FOSDEM), four years ago, one of the
> questions was about the Java version; we were well into the Java 7
> era; a telling silence followed Thomas Neidhart's answer that the
> "consensus" was to stick to... Java 5. From an audience of more than
> 60 people, zero contributor.]
> 
>> It
>> will take time, but a constructive approach like this one will do more
>> to sustain CM.
> 
> This is something to explore.  Are you going to do it?
> 
> How are you so sure that "it will do more" that what I propose,
> which is in fact quite constructive.
> 
> I understand that you may be angry by this long chain of mails.
> But please do not shoot at the bearer of bad news.
> 
> Regards,
> Gilles
> 
>> Thanks,
>> Patrick
>> 
>> -Original Message-
>> From: Jörg Schaible [mailto:joerg.schai...@bpm-inspire.com]
>> Sent: Friday, June 10, 2016 6:20 AM
>> To: dev@commons.apache.org
>> Subject: Re: [Math] Commons Math (r)evolution
>> 
>> Hi Gilles,
>> 
>> Gilles wrote:
>> 
>>> Hi.
>>> 
>>> On Fri, 10 Jun 2016 01:48:20 +0200, Jörg Schaible wrote:
>> 
>> [snip]
>> 
 MATH-172 is about an enhancement. Unfortunately no-one can currently
 implement it, so we have to wait until someone can or the issue stays
 simply unresolved again. You've requested for help and that was the
 proper action

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

> On Jun 10, 2016, at 1:26 PM, James Carman  wrote:
> 
> On Fri, Jun 10, 2016 at 3:29 PM Ralph Goers 
> wrote:
> 
>> Not only is the original chair not available, neither is a quorum of the
>> proposed PMC.  Why are you pushing this?  I, for one, am perfectly content
>> to keep Math here and see if those who have expressed interest in helping
>> out actually do and if others are attracted to fill in the gaps.
>> 
>> 
> I am pushing for it because I think it's the right thing to do for Math
> going forward.  Just like I pushed for it for years until we finally had an
> affirmative vote.  The fact that the others have left doesn't change my
> mind.  It only makes it more important, IMHO.  We need a more diverse
> community for Math.  It also needs to self-govern, however it sees fit.
> Being its own TLP will help attract more attention (especially with a trip
> through the incubator).  I would love to get involved with Math if they'd
> have me.  I was a math major in college, but I'm nowhere near the expert
> that these guys are I'm sure.  I could provide value as a general Java
> language and API resource, though.  If you're interested in Math, Ralph,
> why not come join us?

Personally, I think the vote that took place to move Math to a TLP should now 
be considered void since the proposed PMC no longer exists. Furthermore, at the 
moment Math doesn’t have a sufficient number of participants to make it a 
viable candidate for the incubator IMO.  That may change over the next few 
weeks as people volunteer, but until that happens I find the idea of pushing to 
be a TLP to be as foolhardy as Gilles’ proposal.

FWIW, I really have no interest in Math other than to make sure we don’t kill 
it by doing something ill-conceived.

Ralph

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

[VOTE] Move Commons Math to TLP (again)...

[James Carman]

Since it has been suggested that the previously passing vote should be
voided, I propose we vote again to move Commons Math to a TLP:

+1 - Yes, move Commons Math to a TLP
-1 - No, do not move Commons Math to a TLP

The vote will remain open for 72 hours.

Thank you,

James Carman

Re: [Math] Commons Math (r)evolution

[James Carman]

On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers 
wrote:

>
> Personally, I think the vote that took place to move Math to a TLP should
> now be considered void since the proposed PMC no longer exists.
> Furthermore, at the moment Math doesn’t have a sufficient number of
> participants to make it a viable candidate for the incubator IMO.  That may
> change over the next few weeks as people volunteer, but until that happens
> I find the idea of pushing to be a TLP to be as foolhardy as Gilles’
> proposal.
>
>
That's out of line.  Please do not do personal attacks.  Let's cordially
disagree with one another.

Re: [VOTE] Move Commons Math to TLP (again)...

[James Carman]

Here's my +1 (binding).

On Fri, Jun 10, 2016 at 11:47 PM James Carman 
wrote:

> Since it has been suggested that the previously passing vote should be
> voided, I propose we vote again to move Commons Math to a TLP:
>
> +1 - Yes, move Commons Math to a TLP
> -1 - No, do not move Commons Math to a TLP
>
> The vote will remain open for 72 hours.
>
> Thank you,
>
> James Carman
>

Re: [Math] Commons Math (r)evolution

[James Carman]

I like the idea of splitting Math into multiple components.  Even Phil, in
the TLP VOTE thread, said:

"We are probably at the point where we should consider splitting [math]
itself into separately released subcomponents (could be done in Commons,
but starts smelling a little Jakarta-ish when Commons has components with
subcomponents)."

The key phrase there is "separately released", which I wholeheartedly agree
with. Let the different modules within Math have a different lifecycles and
let them be as active (and independent) as they want to be.

+1 from me.

On Sun, Jun 5, 2016 at 8:49 PM Gilles  wrote:

> Hello.
>
> Commons Math as it was in the last official release (v3.6.1) and
> consequently as it is in the current development branch has
> become unmaintainable.
>
> This conclusion is unavoidable when looking at the following:
>   1. codebase statistics (as of today):
>  * src/main/java   90834 lines of Java code (882 files)
>  * src/test/java   95595 lines of Java code (552 files)
>  * src/userguide/java   3493 lines of Java code (19 files)
>   2. number of posts on the "dev" ML (related to [Math]) in the
>  last 2 months:
>  * Gilles74
>  * Artem Barger  20
>  * sebb  15
>  * Rob Tompkins   9
>  * Eric Barnhill  7
>  * 19 other people   46
>   3. development/maintenance activity in the last 4 months:
>  * commits by Gilles  133
>  * commits by others   12
>
> According to JIRA, among 180 issues currently targeted for the
> next major release (v4.0), 139 have been resolved (75 of which
> were not in v3.6.1).
>
> So, on the one hand, a lot of work has been done already, but
> on the other, a lot remains.
> Some issues have been pending for several years, in particular
> those that required a major refactoring (e.g. in the packages
> "o.a.c.m.linear" and "o.a.c.m.optim").
>
> The remaining work is unlikely to be completed soon since the
> fork of Commons Math has drastically reduced the development
> capacity.
>
> Moreover, as whole areas of the codebase have become in effect
> unsupported, it would be deceiving to release a version 4.0 of
> Commons Math that would include all of it.
>
> Of course, anyone who wishes to maintain some of these codes
> (answer user questions, fix bugs, create enhancements, etc.)
> is most welcome to step forward.
>
> But I'm not optimistic that the necessary level of support can
> be achieved in the near future for all the codebase.
> Waiting for that to happen would entail that code that could
> be in a releasable state soon will be on hold for an indefinite
> time.
>
> The purpose of this post is to initiate a discussion about
> splitting Commons Math, along the following lines:
> 1. Identify independent functionality that can be maintained
> even by a small (even a 1-person) team within Commons and
> make it a new component.
> 2. Identify functionality that cannot be maintained anymore
> inside Commons and try to reach out to users of this
> functionality, asking whether they would be willing to
> give a helping hand.
> If there is sufficient interest, and a new development
> team can form, that code would then be transferred to the
> Apache "incubator".
>
> There are numerous advantages to having separate components
> rather than a monolithic library:
>   * Limited and well-defined scope
>   * Immediate visibility of purpose
>   * Lower barrier to entry
>   * Independent development policy
>   * Homogeneous codebase
>   * Independent release schedule
>   * Foster a new community around the component
>
> According to the most recent development activity, the likely
> candidates for becoming a new component are:
>   * Pseudo-random numbers generators (package "o.a.c.m.rng")
>   * Complex numbers (package "o.a.c.m.complex")
>   * Clustering algorithms (package "o.a.c.m.ml.clustering")
>
> Other potential candidates:
>   * "FastMath" (which should be renamed to something like
> "AccurateMath", cf. reports about slowness of some of
> the functions)
>   * Special functions (package "o.a.c.m.special")
>   * Selected "utilities" (package "o.a.c.m.util")
>
>
> Best regards,
> Gilles
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Math] Commons Math (r)evolution

[James Carman]

On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers 
wrote:

>
> Personally, I think the vote that took place to move Math to a TLP should
> now be considered void since the proposed PMC no longer exists.
> Furthermore, at the moment Math doesn’t have a sufficient number of
> participants to make it a viable candidate for the incubator IMO.  That may
> change over the next few weeks as people volunteer, but until that happens
> I find the idea of pushing to be a TLP to be as foolhardy as Gilles’
> proposal.
>
>
There was no proposed PMC in the VOTE thread.  The votes were cast prior to
any PMC members (aside from the obvious Phil perhaps) being identified.
There was a subsequent thread where Phil asked for volunteers for the new
PMC.  Here is the list of folks who said they'd volunteer:

Phil Seitz
Luc Maisonobe
Gary Gregory
Thomas Neidhart
Gilles Sadowski
William Barker
Otmar Ertl

Out of that list, we still have Gary, Gilles, and William (assuming the
others listed on the Hipparchus site are unwilling at this time).
Obviously they may have changed their mind given the circumstances, but I'm
just relaying the facts.  If I have missed anyone, I apologize.  I'm going
off of email archives.

Re: [Math] Commons Math (r)evolution

[James Carman]

On Sat, Jun 11, 2016 at 12:48 AM James Carman 
wrote:

>
> Phil Seitz
> Luc Maisonobe
> Gary Gregory
> Thomas Neidhart
> Gilles Sadowski
> William Barker
> Otmar Ertl
>
>
Apologies to Phil for misspelling his name, Steitz.

Re: [crypto] Logging dependency

[Ralph Goers]

> On Jun 10, 2016, at 2:56 PM, Torsten Curdt  wrote:
> 
>> Matt, there is a big difference between printing the stack trace and
>> walking it to find the info. printing it on every debug call would be
>> insane.
>> 
> 
> Why would anyone want to do that?
> 
> https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html
> 
> 
> And how do you think the logging frameworks get that kind of information? :)

I think you missed Sebb’s suggestion of having the debug method call 
printStackTrace().

Ralph



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

Re: [VOTE] Move Commons Math to TLP (again)...

[Ralph Goers]

-1 (binding)

At least until there are enough people to have a viable PMC.

Ralph

> On Jun 10, 2016, at 8:47 PM, James Carman  wrote:
> 
> Since it has been suggested that the previously passing vote should be
> voided, I propose we vote again to move Commons Math to a TLP:
> 
> +1 - Yes, move Commons Math to a TLP
> -1 - No, do not move Commons Math to a TLP
> 
> The vote will remain open for 72 hours.
> 
> Thank you,
> 
> James Carman



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

Re: [Math] Commons Math (r)evolution

[Ralph Goers]

> On Jun 10, 2016, at 8:48 PM, James Carman  wrote:
> 
> On Fri, Jun 10, 2016 at 11:11 PM Ralph Goers 
> wrote:
> 
>> 
>> Personally, I think the vote that took place to move Math to a TLP should
>> now be considered void since the proposed PMC no longer exists.
>> Furthermore, at the moment Math doesn’t have a sufficient number of
>> participants to make it a viable candidate for the incubator IMO.  That may
>> change over the next few weeks as people volunteer, but until that happens
>> I find the idea of pushing to be a TLP to be as foolhardy as Gilles’
>> proposal.
>> 
>> 
> That's out of line.  Please do not do personal attacks.  Let's cordially
> disagree with one another.

My apologies, you are absolutely correct. I was wrong to have included that 
last sentence.

Ralph



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

Any commons project to refer standard datastructures and algorithms implementation

[venkatesha m]

Hi
I would like to know if there is an umbrella project under which basic 
datastructures and algorithm implementations exist. If there is one please let 
me know
Else;
I am looking at things such as    
   - Apache commons standard / style of interfaces for Trees, Graphs and the 
various algorithms that will need to be implemented and for practical use.
   - Dynamic prgoramming related standard problems which may be of every day use

Most often i am having to have to hand crank these when need arises or look at 
different text book implements. However i feel if there was a commons standard 
project for the same; all might find very good use of the same
Please let me know what you think
thanksvenkat.