Re: [cli]

[Benedikt Ritter]

Hello Pooja,

2016-01-21 6:54 GMT+01:00 Chitnis, Pooja :

> Hi cli dev team,
>
> I recently upgraded to the commons-cli version 1.3.1 where the BasicParser
> is deprecated. So if I sue the DefaultParser instead, my following sample
> code would not work -
>
> public static void main(String[] args) throws Exception {
> Options options = getOptions();
> if (args != null && args.length == 1 && args[0].equals("-?")) {
> CommandLineUtils.printHelp("adfg", options);
> System.exit(2);
> }
> CommandLineParser parser = new DefaultParser();
> CommandLine cmd = parser.parse(options, args);
> String name1 = cmd.getOptionValue("name1");
> String name2 = cmd.getOptionValue("name2");
> String name3 = cmd.getOptionValue("name3");
>
> System.out.println("name1 : " + name1);
> System.out.println("name2 : " + name2);
> System.out.println("name3 : " + name3);
> }
>
> private static Options getOptions() {
> Options options = new Options();
> Option asOption = new Option("name1", true, "name1");
> asOption.setRequired(true);
> options.addOption(asOption);
> Option dsOption = new Option("name2", true, "name2");
> dsOption.setOptionalArg(true);
> dsOption.setRequired(false);
> options.addOption(dsOption);
> Option dcOption = new Option("name3", true, "name3");
> dcOption.setRequired(true);
> options.addOption(dcOption);
> return options;
> }
> The input args passed to main method are: -name1 val1 -name2 -name3 val3
> Note that I have not passed val for the -name2. If I remove the -name2 it
> will work but its user driven. Previously with BasicParser this use to work.
>
> Here it throws following exception
> Exception in thread "main" org.apache.commons.cli.MissingOptionException:
> Missing required option: name3
>at
> org.apache.commons.cli.DefaultParser.checkRequiredOptions(DefaultParser.java:199)
>at
> org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:130)
>at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:76)
>at org.apache.commons.cli.DefaultParser.parse(DefaultParser.java:60)
>at test.DefaultParserTest.main(DefaultParserTest.java:26)
>
> It seems a bug in the DefaultParser. Can you please fix this?
>

You could file an issue in our bug tracker [1]. I haven't seen much
activity in [cli] since the last release, so patches welcome! :-)

Regards,
Benedikt

[1] https://issues.apache.org/jira/browse/cli


>
> Thanks,
> -Pooja
>



-- 
http://home.apache.org/~britter/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [math] Name of the new TLP

[Bertrand Delacretaz]

Hi,

On Sun, Jan 24, 2016 at 10:08 PM, Phil Steitz  wrote:
> We need to agree on a name...

FWIW from the board's point of view, once that's done it's good to
create a https://issues.apache.org/jira/browse/PODLINGNAMESEARCH
ticket to document the name search. It's fine to use that jira project
even though you're not creating a podling.

-Bertrand

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

Re: [math] Name of the new TLP

[luc]

Le 2016-01-25 08:52, Benedikt Ritter a écrit :

Hi,

I very much like the idea of taking the name of a famous mathematician.
If it has to be some thing more descriptive: Apache Commons HttpClient 
went

to Apache HttpComponents. How about Apache Math Components as TLP name?

Benedikt

2016-01-25 8:40 GMT+01:00 Ole Ersoy :


Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an umbrella.  
Some
of the other Apache projects that do math may be interested in moving 
that

piece under the Apache Math umbrella.

Personally I like to see each in a separate repository dedicated to 
the

subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a whole with 
the

documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole


On 01/24/2016 04:41 PM, Phil Steitz wrote:



On Jan 24, 2016, at 3:17 PM, Gilles  
wrote:


Just plain and simple "Apache Math" maybe?
Or is it taken already?


It's not taken; but I thought it was too broad-sounding and in fact
umbrella-ish.  There are other ASF projects that do math-relates 
things.  I

think adding "components" makes it look more like a library of base
components that other math-related projects can use.

Phil


Gilles

On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:



On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going to 
do.



This is slightly jumping the gun, as we do have the opportunity in
forming the new TLP to revisit the initial goals of [math]; but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common 
math

programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release artifacts.
Similar in some ways to what happened with [http], which is why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much like
that idea as whoever you choose, you end up loading some math area
and / or cultural bias into the name.

Phil


Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton? Apache 
Euler?

Apache Euclid?

On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 


wrote:

We need to agree on a name.  My own preference is for a boring,
descriptive name, but I am manifestly not a marketing guy, so 
won't

be offended if others want to be more creative.

My suggestion is

MathComponents


I would be happy with either Math Components or Math.
Also I do favor fancy acronyms that read exactly as well known
names (23 years ago, the name of my first mathematics library was
an acronym that read "Cantor"), it is probably not a good idea for
this new TLP.

In any case, the project will most probably be de facto an umbrella
project as modularizing it seems in the current mood.

best regards,
Luc



Hearkens back to HttpComponents, which has worked pretty well.

Phil




-
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





-
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] Volunteer for the new TLP PMC

[Thomas Neidhart]

On Sun, Jan 24, 2016 at 9:54 PM, Phil Steitz  wrote:

> Please respond to this thread if you are a Commons Committer
> interested in joining the PMC for the new TLP based on [math].
>

Hi Phil,

thanks for pushing this whole issue!

I am happy to volunteer for the new PMC to be formed.

Thomas

Re: [math] Name of the new TLP

[sebb]

On 25 January 2016 at 09:28, luc  wrote:
> Le 2016-01-25 08:52, Benedikt Ritter a écrit :
>>
>> Hi,
>>
>> I very much like the idea of taking the name of a famous mathematician.

In which case it has to be

Euclid or Pythagoras (early)
or
Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number

and everyone has heard of
John Nash (Beautiful Mind)

etc.
In the spirit of recent discussions, how about a RNG to pick the
mathematician's name for each next incarnation?

;-)

>> If it has to be some thing more descriptive: Apache Commons HttpClient
>> went
>> to Apache HttpComponents. How about Apache Math Components as TLP name?

I quite like Apache Epsilon as a non-descriptive but related name.

[ducks behind bikshed]

>>
>> Benedikt
>>
>> 2016-01-25 8:40 GMT+01:00 Ole Ersoy :
>>
>>> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
>>> networks, clustering, monte carlo, simplex...These need an umbrella.
>>> Some
>>> of the other Apache projects that do math may be interested in moving
>>> that
>>> piece under the Apache Math umbrella.
>>>
>>> Personally I like to see each in a separate repository dedicated to the
>>> subject, along with the corresponding documentation, etc  So:
>>> apache-math (Central repository describing the project as a whole with
>>> the
>>> documentation that cuts across modules)
>>> apache-math-linear-real
>>> apache-math-linear-field
>>> apache-math-optimization-genetic
>>> apache-math-optimization-simplex
>>> etc.
>>>
>>> And hopefully:
>>> apache-math-optimization-integer
>>> apache-math-optimization-mixed
>>> And more..
>>>
>>> Cheers,
>>> Ole
>>>
>>>
>>> On 01/24/2016 04:41 PM, Phil Steitz wrote:
>>>

 On Jan 24, 2016, at 3:17 PM, Gilles 
 wrote:
>
>
> Just plain and simple "Apache Math" maybe?
> Or is it taken already?
>
 It's not taken; but I thought it was too broad-sounding and in fact
 umbrella-ish.  There are other ASF projects that do math-relates things.
 I
 think adding "components" makes it look more like a library of base
 components that other math-related projects can use.

 Phil

> Gilles
>
> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
>>
>>
>>> On 1/24/16 2:16 PM, James Carman wrote:
>>> I guess it depends on the scope of what the new TLP is going to do.
>>>
>> This is slightly jumping the gun, as we do have the opportunity in
>> forming the new TLP to revisit the initial goals of [math]; but I
>> suspect that initially at least we will mostly continue to be a
>> general-purpose Java math library, trying to provide IP-clean,
>> easily integrated, standard algorithm-based solutions to common math
>> programming problems.  We have grown to the point where we will
>> almost certainly break the distribution up into separate
>> "components."  No umbrella, but likely multiple release artifacts.
>> Similar in some ways to what happened with [http], which is why I
>> suggested the same approach to naming.
>>
>> Regarding picking a mathematician for the name, I don't much like
>> that idea as whoever you choose, you end up loading some math area
>> and / or cultural bias into the name.
>>
>> Phil
>>
>>> Umbrella projects aren't that popular these days, from what I
>>> understand.
>>> Maybe an homage to a famous mathematician? Apache Newton? Apache
>>> Euler?
>>> Apache Euclid?
>>>
>>> On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 

 wrote:

 We need to agree on a name.  My own preference is for a boring,
 descriptive name, but I am manifestly not a marketing guy, so won't
 be offended if others want to be more creative.

 My suggestion is

 MathComponents
>
>
> I would be happy with either Math Components or Math.
> Also I do favor fancy acronyms that read exactly as well known
> names (23 years ago, the name of my first mathematics library was
> an acronym that read "Cantor"), it is probably not a good idea for
> this new TLP.
>
> In any case, the project will most probably be de facto an umbrella
> project as modularizing it seems in the current mood.
>
> best regards,
> Luc
>
>

 Hearkens back to HttpComponents, which has worked pretty well.

 Phil

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



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

Re: [math] Name of the new TLP

[James Carman]

Epsilon is catchy
On Mon, Jan 25, 2016 at 6:41 AM sebb  wrote:

> On 25 January 2016 at 09:28, luc  wrote:
> > Le 2016-01-25 08:52, Benedikt Ritter a écrit :
> >>
> >> Hi,
> >>
> >> I very much like the idea of taking the name of a famous mathematician.
>
> In which case it has to be
>
> Euclid or Pythagoras (early)
> or
> Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number
>
> and everyone has heard of
> John Nash (Beautiful Mind)
>
> etc.
> In the spirit of recent discussions, how about a RNG to pick the
> mathematician's name for each next incarnation?
>
> ;-)
>
> >> If it has to be some thing more descriptive: Apache Commons HttpClient
> >> went
> >> to Apache HttpComponents. How about Apache Math Components as TLP name?
>
> I quite like Apache Epsilon as a non-descriptive but related name.
>
> [ducks behind bikshed]
>
> >>
> >> Benedikt
> >>
> >> 2016-01-25 8:40 GMT+01:00 Ole Ersoy :
> >>
> >>> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
> >>> networks, clustering, monte carlo, simplex...These need an umbrella.
> >>> Some
> >>> of the other Apache projects that do math may be interested in moving
> >>> that
> >>> piece under the Apache Math umbrella.
> >>>
> >>> Personally I like to see each in a separate repository dedicated to the
> >>> subject, along with the corresponding documentation, etc  So:
> >>> apache-math (Central repository describing the project as a whole with
> >>> the
> >>> documentation that cuts across modules)
> >>> apache-math-linear-real
> >>> apache-math-linear-field
> >>> apache-math-optimization-genetic
> >>> apache-math-optimization-simplex
> >>> etc.
> >>>
> >>> And hopefully:
> >>> apache-math-optimization-integer
> >>> apache-math-optimization-mixed
> >>> And more..
> >>>
> >>> Cheers,
> >>> Ole
> >>>
> >>>
> >>> On 01/24/2016 04:41 PM, Phil Steitz wrote:
> >>>
> 
>  On Jan 24, 2016, at 3:17 PM, Gilles 
>  wrote:
> >
> >
> > Just plain and simple "Apache Math" maybe?
> > Or is it taken already?
> >
>  It's not taken; but I thought it was too broad-sounding and in fact
>  umbrella-ish.  There are other ASF projects that do math-relates
> things.
>  I
>  think adding "components" makes it look more like a library of base
>  components that other math-related projects can use.
> 
>  Phil
> 
> > Gilles
> >
> > On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
> >>
> >>
> >>> On 1/24/16 2:16 PM, James Carman wrote:
> >>> I guess it depends on the scope of what the new TLP is going to do.
> >>>
> >> This is slightly jumping the gun, as we do have the opportunity in
> >> forming the new TLP to revisit the initial goals of [math]; but I
> >> suspect that initially at least we will mostly continue to be a
> >> general-purpose Java math library, trying to provide IP-clean,
> >> easily integrated, standard algorithm-based solutions to common math
> >> programming problems.  We have grown to the point where we will
> >> almost certainly break the distribution up into separate
> >> "components."  No umbrella, but likely multiple release artifacts.
> >> Similar in some ways to what happened with [http], which is why I
> >> suggested the same approach to naming.
> >>
> >> Regarding picking a mathematician for the name, I don't much like
> >> that idea as whoever you choose, you end up loading some math area
> >> and / or cultural bias into the name.
> >>
> >> Phil
> >>
> >>> Umbrella projects aren't that popular these days, from what I
> >>> understand.
> >>> Maybe an homage to a famous mathematician? Apache Newton? Apache
> >>> Euler?
> >>> Apache Euclid?
> >>>
> >>> On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz  >
> 
>  wrote:
> 
>  We need to agree on a name.  My own preference is for a boring,
>  descriptive name, but I am manifestly not a marketing guy, so
> won't
>  be offended if others want to be more creative.
> 
>  My suggestion is
> 
>  MathComponents
> >
> >
> > I would be happy with either Math Components or Math.
> > Also I do favor fancy acronyms that read exactly as well known
> > names (23 years ago, the name of my first mathematics library was
> > an acronym that read "Cantor"), it is probably not a good idea for
> > this new TLP.
> >
> > In any case, the project will most probably be de facto an umbrella
> > project as modularizing it seems in the current mood.
> >
> > best regards,
> > Luc
> >
> >
> 
>  Hearkens back to HttpComponents, which has worked pretty well.
> 
>  Phil
> 
> >>>
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> > --

Re: [math] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 11:40:48 +, sebb wrote:

On 25 January 2016 at 09:28, luc  wrote:

Le 2016-01-25 08:52, Benedikt Ritter a écrit :


Hi,

I very much like the idea of taking the name of a famous 
mathematician.


In which case it has to be

Euclid or Pythagoras (early)
or
Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number

and everyone has heard of
John Nash (Beautiful Mind)


I'd rather not have a person's name for the project; as was said
before, it will carry meaning that could be misleading.


etc.
In the spirit of recent discussions, how about a RNG to pick the
mathematician's name for each next incarnation?

;-)


On the other hand, this is really a good idea for naming releases! :-)

If it has to be some thing more descriptive: Apache Commons 
HttpClient

went
to Apache HttpComponents. How about Apache Math Components as TLP 
name?


I quite like Apache Epsilon as a non-descriptive but related name.

[ducks behind bikshed]


What about
 * MathBlocks
 * MathModules
 * modMath
 * AJaMa
?

The last one is short while fully descriptive:
  AJaMa
   is
the Apache JAva MAthematics library


Regards,
Gilles



Benedikt

2016-01-25 8:40 GMT+01:00 Ole Ersoy :


Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an 
umbrella.

Some
of the other Apache projects that do math may be interested in 
moving

that
piece under the Apache Math umbrella.

Personally I like to see each in a separate repository dedicated 
to the

subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a whole 
with

the
documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole


On 01/24/2016 04:41 PM, Phil Steitz wrote:



On Jan 24, 2016, at 3:17 PM, Gilles 


wrote:



Just plain and simple "Apache Math" maybe?
Or is it taken already?

It's not taken; but I thought it was too broad-sounding and in 
fact
umbrella-ish.  There are other ASF projects that do math-relates 
things.

I
think adding "components" makes it look more like a library of 
base

components that other math-related projects can use.

Phil


Gilles

On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:




On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going 
to do.


This is slightly jumping the gun, as we do have the opportunity 
in
forming the new TLP to revisit the initial goals of [math]; but 
I

suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common 
math

programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release 
artifacts.
Similar in some ways to what happened with [http], which is why 
I

suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much 
like
that idea as whoever you choose, you end up loading some math 
area

and / or cultural bias into the name.

Phil


Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton? 
Apache

Euler?
Apache Euclid?

On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 



wrote:

We need to agree on a name.  My own preference is for a 
boring,
descriptive name, but I am manifestly not a marketing guy, so 
won't

be offended if others want to be more creative.

My suggestion is

MathComponents



I would be happy with either Math Components or Math.
Also I do favor fancy acronyms that read exactly as well known
names (23 years ago, the name of my first mathematics library was
an acronym that read "Cantor"), it is probably not a good idea for
this new TLP.

In any case, the project will most probably be de facto an umbrella
project as modularizing it seems in the current mood.

best regards,
Luc




Hearkens back to HttpComponents, which has worked pretty 
well.


Phil




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

Re: [math] Name of the new TLP

[Emmanuel Bourg]

Le 25/01/2016 13:21, Gilles a écrit :

>  * AJaMa
> ?
> 
> The last one is short while fully descriptive:
>   AJaMa
>is
> the Apache JAva MAthematics library

This one will probably sound too similar with Jama, another math library:

http://math.nist.gov/javanumerics/jama/


Will the new TLP focus on Java libraries exclusively or will it be open
to implementations in other languages?

Emmanuel Bourg


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

Re: [math] Volunteer for the new TLP PMC

[Gilles]

On Sun, 24 Jan 2016 13:54:51 -0700, Phil Steitz wrote:

Please respond to this thread if you are a Commons Committer
interested in joining the PMC for the new TLP based on [math].

Thanks!

Phil


I'm interested in as much as I'm being curious to see if it
will change anything! :-}

There were a few "negative" arguments, that is was better to
stop "annoying" the other Commons projects. [To which some
responded that they'd prefer the status quo.]

The rationale concerning the size, scope, and management of
Commons Math, (and how different it was from all the other
Commons components), I had brought up on several occasions in
the past.

What has changed?

What are the "positive" arguments?

To be crystal-clear, if the new PMC is composed of the same
people who are the regular contributors to the Commons Math
project, i.e. with the same confronting blocks, I don't see
from where the incentive towards a different development policy
will come.

Various points have been brought up in (too often heated)
discussions (JDK version, development and release policies
such as compatibility, refactoring, multi-threading, exception
handling, etc.).

I think that the volunteers for the new PMC should list their
opinion on fundamental issues that obviously define a "vision"
of the project.

Lacking clear goals[1] is not going to help in any way.
At this point, we can expect administrative chores.
Wouldn't it be a pity to do all that work just to get a new
name?


Regards,
Gilles

[1] There can be seemingly contradictory goals as long as they
are acknowledged and do not hamper each other (like I've
expressed in other posts) and sufficient resources exist to
handle them.


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

Re: [math] Name of the new TLP

[luc]

Le 2016-01-25 12:49, James Carman a écrit :

Epsilon is catchy


I like it too.  As we have a tendency to chase down accuracy, it seems
a good fit. The logo would be easy to select ...

It would do well with the existing (despite quite stagnant)
Apache Commons Nabla .


Luc


On Mon, Jan 25, 2016 at 6:41 AM sebb  wrote:


On 25 January 2016 at 09:28, luc  wrote:
> Le 2016-01-25 08:52, Benedikt Ritter a écrit :
>>
>> Hi,
>>
>> I very much like the idea of taking the name of a famous mathematician.

In which case it has to be

Euclid or Pythagoras (early)
or
Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number

and everyone has heard of
John Nash (Beautiful Mind)

etc.
In the spirit of recent discussions, how about a RNG to pick the
mathematician's name for each next incarnation?

;-)

>> If it has to be some thing more descriptive: Apache Commons HttpClient
>> went
>> to Apache HttpComponents. How about Apache Math Components as TLP name?

I quite like Apache Epsilon as a non-descriptive but related name.

[ducks behind bikshed]

>>
>> Benedikt
>>
>> 2016-01-25 8:40 GMT+01:00 Ole Ersoy :
>>
>>> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
>>> networks, clustering, monte carlo, simplex...These need an umbrella.
>>> Some
>>> of the other Apache projects that do math may be interested in moving
>>> that
>>> piece under the Apache Math umbrella.
>>>
>>> Personally I like to see each in a separate repository dedicated to the
>>> subject, along with the corresponding documentation, etc  So:
>>> apache-math (Central repository describing the project as a whole with
>>> the
>>> documentation that cuts across modules)
>>> apache-math-linear-real
>>> apache-math-linear-field
>>> apache-math-optimization-genetic
>>> apache-math-optimization-simplex
>>> etc.
>>>
>>> And hopefully:
>>> apache-math-optimization-integer
>>> apache-math-optimization-mixed
>>> And more..
>>>
>>> Cheers,
>>> Ole
>>>
>>>
>>> On 01/24/2016 04:41 PM, Phil Steitz wrote:
>>>

 On Jan 24, 2016, at 3:17 PM, Gilles 
 wrote:
>
>
> Just plain and simple "Apache Math" maybe?
> Or is it taken already?
>
 It's not taken; but I thought it was too broad-sounding and in fact
 umbrella-ish.  There are other ASF projects that do math-relates
things.
 I
 think adding "components" makes it look more like a library of base
 components that other math-related projects can use.

 Phil

> Gilles
>
> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
>>
>>
>>> On 1/24/16 2:16 PM, James Carman wrote:
>>> I guess it depends on the scope of what the new TLP is going to do.
>>>
>> This is slightly jumping the gun, as we do have the opportunity in
>> forming the new TLP to revisit the initial goals of [math]; but I
>> suspect that initially at least we will mostly continue to be a
>> general-purpose Java math library, trying to provide IP-clean,
>> easily integrated, standard algorithm-based solutions to common math
>> programming problems.  We have grown to the point where we will
>> almost certainly break the distribution up into separate
>> "components."  No umbrella, but likely multiple release artifacts.
>> Similar in some ways to what happened with [http], which is why I
>> suggested the same approach to naming.
>>
>> Regarding picking a mathematician for the name, I don't much like
>> that idea as whoever you choose, you end up loading some math area
>> and / or cultural bias into the name.
>>
>> Phil
>>
>>> Umbrella projects aren't that popular these days, from what I
>>> understand.
>>> Maybe an homage to a famous mathematician? Apache Newton? Apache
>>> Euler?
>>> Apache Euclid?
>>>
>>> On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 

 wrote:

 We need to agree on a name.  My own preference is for a boring,
 descriptive name, but I am manifestly not a marketing guy, so
won't
 be offended if others want to be more creative.

 My suggestion is

 MathComponents
>
>
> I would be happy with either Math Components or Math.
> Also I do favor fancy acronyms that read exactly as well known
> names (23 years ago, the name of my first mathematics library was
> an acronym that read "Cantor"), it is probably not a good idea for
> this new TLP.
>
> In any case, the project will most probably be de facto an umbrella
> project as modularizing it seems in the current mood.
>
> best regards,
> Luc
>
>

 Hearkens back to HttpComponents, which has worked pretty well.

 Phil

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

Re: [math] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 13:41:46 +0100, Emmanuel Bourg wrote:

Le 25/01/2016 13:21, Gilles a écrit :


 * AJaMa
?

The last one is short while fully descriptive:
  AJaMa
   is
the Apache JAva MAthematics library


This one will probably sound too similar with Jama, another math 
library:


http://math.nist.gov/javanumerics/jama/


I made the proposal knowing about this.

A few years ago, the JAMA project had been declared dead (although I do 
not

find the announcement page).
Anyways, it has not been updated since November 2012.
To be sure we could ask them.

A similar sounding name could be taken as a tribute... ;-)

Will the new TLP focus on Java libraries exclusively or will it be 
open

to implementations in other languages?


This is also a fundamental question.

Given that we could not even agree to evolve with the JDK (last release 
of
CM had to be Java *5* source-compatible!), it would be a (bad) joke (or 
a

revolution!) to throw other languages into the discussion.

Gilles



Emmanuel Bourg



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

Re: [math] Name of the new TLP

[Phil Steitz]

On 1/25/16 12:40 AM, Ole Ersoy wrote:
> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
> networks, clustering, monte carlo, simplex...These need an
> umbrella.  Some of the other Apache projects that do math may be
> interested in moving that piece under the Apache Math umbrella.

The ASF does not look favorably on "umbrella" projects.  This is
because in these projects, the individual volunteers making up the
PMC inevitably lose sight of the full project.  The governance model
that we have at Apache has no layers in it beneath the PMC.  That
means PMCs need to be focused.  "All things X" PMCs don't work.  The
canonical example of that was Jakarta, which started as "all things
Java" and was eventually split up.  We should definitely not try to
be "all things math" at the ASF.  A better focus would be a nice set
math components in Java that other math-related projects inside and
outside the ASF can use.  Kind of like, um, Commons Math as its own
TLP :)

Phil
>
> Personally I like to see each in a separate repository dedicated
> to the subject, along with the corresponding documentation, etc  So:
> apache-math (Central repository describing the project as a whole
> with the documentation that cuts across modules)
> apache-math-linear-real
> apache-math-linear-field
> apache-math-optimization-genetic
> apache-math-optimization-simplex
> etc.
>
> And hopefully:
> apache-math-optimization-integer
> apache-math-optimization-mixed
> And more..
>
> Cheers,
> Ole
>
> On 01/24/2016 04:41 PM, Phil Steitz wrote:
>>
>>> On Jan 24, 2016, at 3:17 PM, Gilles
>>>  wrote:
>>>
>>> Just plain and simple "Apache Math" maybe?
>>> Or is it taken already?
>> It's not taken; but I thought it was too broad-sounding and in
>> fact umbrella-ish.  There are other ASF projects that do
>> math-relates things.  I think adding "components" makes it look
>> more like a library of base components that other math-related
>> projects can use.
>>
>> Phil
>>> Gilles
>>>
 On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
> On 1/24/16 2:16 PM, James Carman wrote:
> I guess it depends on the scope of what the new TLP is going
> to do.
 This is slightly jumping the gun, as we do have the opportunity in
 forming the new TLP to revisit the initial goals of [math]; but I
 suspect that initially at least we will mostly continue to be a
 general-purpose Java math library, trying to provide IP-clean,
 easily integrated, standard algorithm-based solutions to common
 math
 programming problems.  We have grown to the point where we will
 almost certainly break the distribution up into separate
 "components."  No umbrella, but likely multiple release artifacts.
 Similar in some ways to what happened with [http], which is why I
 suggested the same approach to naming.

 Regarding picking a mathematician for the name, I don't much like
 that idea as whoever you choose, you end up loading some math area
 and / or cultural bias into the name.

 Phil
> Umbrella projects aren't that popular these days, from what I
> understand.
> Maybe an homage to a famous mathematician? Apache Newton?
> Apache Euler?
> Apache Euclid?
>
>> On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz
>>  wrote:
>>
>> We need to agree on a name.  My own preference is for a boring,
>> descriptive name, but I am manifestly not a marketing guy, so
>> won't
>> be offended if others want to be more creative.
>>
>> My suggestion is
>>
>> MathComponents
>>
>> Hearkens back to HttpComponents, which has worked pretty well.
>>
>> Phil
>>>
>>> -
>>>
>>> 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
>>
>>
>
>
> -
> 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] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 06:47:40 -0700, Phil Steitz wrote:

On 1/25/16 12:40 AM, Ole Ersoy wrote:

Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an
umbrella.  Some of the other Apache projects that do math may be
interested in moving that piece under the Apache Math umbrella.


The ASF does not look favorably on "umbrella" projects.  This is
because in these projects, the individual volunteers making up the
PMC inevitably lose sight of the full project.  The governance model
that we have at Apache has no layers in it beneath the PMC.  That
means PMCs need to be focused.  "All things X" PMCs don't work.  The
canonical example of that was Jakarta, which started as "all things
Java" and was eventually split up.  We should definitely not try to
be "all things math" at the ASF.  A better focus would be a nice set
math components in Java that other math-related projects inside and
outside the ASF can use.  Kind of like, um, Commons Math as its own
TLP :)


The problem is that Commons Math is "all things math-related that the
PMC agreed to put in".  It is an umbrella in the sense you describe 
here

(even if obviously cannot preclude other project to implement math
routines).

We have seen that a CM-like project has advantages and drawbacks, for
developers and users.

It makes sense to dig further into Ole's proposal towards 
modularization

because, if it is as you say above, then different modules may have to
become different projects!

If they don't have to, then I don't understand your argument.

Or it is a fight on the use of the word "umbrella"?

Gilles



Phil


Personally I like to see each in a separate repository dedicated
to the subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a whole
with the documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole

On 01/24/2016 04:41 PM, Phil Steitz wrote:



On Jan 24, 2016, at 3:17 PM, Gilles
 wrote:

Just plain and simple "Apache Math" maybe?
Or is it taken already?

It's not taken; but I thought it was too broad-sounding and in
fact umbrella-ish.  There are other ASF projects that do
math-relates things.  I think adding "components" makes it look
more like a library of base components that other math-related
projects can use.

Phil

Gilles


On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:

On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going
to do.
This is slightly jumping the gun, as we do have the opportunity 
in

forming the new TLP to revisit the initial goals of [math]; but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common
math
programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release 
artifacts.

Similar in some ways to what happened with [http], which is why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much like
that idea as whoever you choose, you end up loading some math 
area

and / or cultural bias into the name.

Phil

Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton?
Apache Euler?
Apache Euclid?


On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz
 wrote:

We need to agree on a name.  My own preference is for a boring,
descriptive name, but I am manifestly not a marketing guy, so
won't
be offended if others want to be more creative.

My suggestion is

MathComponents

Hearkens back to HttpComponents, which has worked pretty well.

Phil



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

Re: [math] Name of the new TLP

[Phil Steitz]

On 1/25/16 2:28 AM, luc wrote:
> Le 2016-01-25 08:52, Benedikt Ritter a écrit :
>> Hi,
>>
>> I very much like the idea of taking the name of a famous
>> mathematician.
>> If it has to be some thing more descriptive: Apache Commons
>> HttpClient went
>> to Apache HttpComponents. How about Apache Math Components as TLP
>> name?
>>
>> Benedikt
>>
>> 2016-01-25 8:40 GMT+01:00 Ole Ersoy :
>>
>>> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
>>> networks, clustering, monte carlo, simplex...These need an
>>> umbrella.  Some
>>> of the other Apache projects that do math may be interested in
>>> moving that
>>> piece under the Apache Math umbrella.
>>>
>>> Personally I like to see each in a separate repository dedicated
>>> to the
>>> subject, along with the corresponding documentation, etc  So:
>>> apache-math (Central repository describing the project as a
>>> whole with the
>>> documentation that cuts across modules)
>>> apache-math-linear-real
>>> apache-math-linear-field
>>> apache-math-optimization-genetic
>>> apache-math-optimization-simplex
>>> etc.
>>>
>>> And hopefully:
>>> apache-math-optimization-integer
>>> apache-math-optimization-mixed
>>> And more..
>>>
>>> Cheers,
>>> Ole
>>>
>>>
>>> On 01/24/2016 04:41 PM, Phil Steitz wrote:
>>>

 On Jan 24, 2016, at 3:17 PM, Gilles
  wrote:
>
> Just plain and simple "Apache Math" maybe?
> Or is it taken already?
>
 It's not taken; but I thought it was too broad-sounding and in
 fact
 umbrella-ish.  There are other ASF projects that do
 math-relates things.  I
 think adding "components" makes it look more like a library of
 base
 components that other math-related projects can use.

 Phil

> Gilles
>
> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
>>
>>> On 1/24/16 2:16 PM, James Carman wrote:
>>> I guess it depends on the scope of what the new TLP is going
>>> to do.
>>>
>> This is slightly jumping the gun, as we do have the
>> opportunity in
>> forming the new TLP to revisit the initial goals of [math];
>> but I
>> suspect that initially at least we will mostly continue to be a
>> general-purpose Java math library, trying to provide IP-clean,
>> easily integrated, standard algorithm-based solutions to
>> common math
>> programming problems.  We have grown to the point where we will
>> almost certainly break the distribution up into separate
>> "components."  No umbrella, but likely multiple release
>> artifacts.
>> Similar in some ways to what happened with [http], which is
>> why I
>> suggested the same approach to naming.
>>
>> Regarding picking a mathematician for the name, I don't much
>> like
>> that idea as whoever you choose, you end up loading some math
>> area
>> and / or cultural bias into the name.
>>
>> Phil
>>
>>> Umbrella projects aren't that popular these days, from what I
>>> understand.
>>> Maybe an homage to a famous mathematician? Apache Newton?
>>> Apache Euler?
>>> Apache Euclid?
>>>
>>> On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz
>>> 
 wrote:

 We need to agree on a name.  My own preference is for a
 boring,
 descriptive name, but I am manifestly not a marketing guy,
 so won't
 be offended if others want to be more creative.

 My suggestion is

 MathComponents
>
> I would be happy with either Math Components or Math.
> Also I do favor fancy acronyms that read exactly as well known
> names

One that I thought of kind of like that was another current ASF name
ripoff:

JAML (Java Apache Math Library) imitating JAMES.

> (23 years ago, the name of my first mathematics library was
> an acronym that read "Cantor"), it is probably not a good idea for
> this new TLP.
>
> In any case, the project will most probably be de facto an umbrella
> project as modularizing it seems in the current mood.

Modularization does not mean becoming an umbrella project.  It just
means we distribute multiple jars.   In any case, the scope
limitation that I thought good to somehow imply in the name was that
what we aim to produce is a base library in Java.

Phil
>
> best regards,
> Luc
>

 Hearkens back to HttpComponents, which has worked pretty well.

 Phil

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



>>>
>>> -
>>>
>>> T

Re: [math] Name of the new TLP

[Phil Steitz]

On 1/25/16 6:24 AM, Gilles wrote:
> On Mon, 25 Jan 2016 13:41:46 +0100, Emmanuel Bourg wrote:
>> Le 25/01/2016 13:21, Gilles a écrit :
>>
>>>  * AJaMa
>>> ?
>>>
>>> The last one is short while fully descriptive:
>>>   AJaMa
>>>is
>>> the Apache JAva MAthematics library
>>
>> This one will probably sound too similar with Jama, another math
>> library:
>>
>> http://math.nist.gov/javanumerics/jama/
>
> I made the proposal knowing about this.
>
> A few years ago, the JAMA project had been declared dead (although
> I do not
> find the announcement page).
> Anyways, it has not been updated since November 2012.
> To be sure we could ask them.
>
> A similar sounding name could be taken as a tribute... ;-)

Wow!  I should have read this before I just posted the same idea. 
Actually, some of the code in our linear package is adapted from
JAMA.  We did contact them years ago when we were incorporating that
code.

Phil


>
>> Will the new TLP focus on Java libraries exclusively or will it
>> be open
>> to implementations in other languages?
>
> This is also a fundamental question.
>
> Given that we could not even agree to evolve with the JDK (last
> release of
> CM had to be Java *5* source-compatible!), it would be a (bad)
> joke (or a
> revolution!) to throw other languages into the discussion.
>
> Gilles
>
>
>> Emmanuel Bourg
>
>
> -
> 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] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 07:01:38 -0700, Phil Steitz wrote:

On 1/25/16 2:28 AM, luc wrote:

Le 2016-01-25 08:52, Benedikt Ritter a écrit :

Hi,

I very much like the idea of taking the name of a famous
mathematician.
If it has to be some thing more descriptive: Apache Commons
HttpClient went
to Apache HttpComponents. How about Apache Math Components as TLP
name?

Benedikt

2016-01-25 8:40 GMT+01:00 Ole Ersoy :


Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an
umbrella.  Some
of the other Apache projects that do math may be interested in
moving that
piece under the Apache Math umbrella.

Personally I like to see each in a separate repository dedicated
to the
subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a
whole with the
documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole


On 01/24/2016 04:41 PM, Phil Steitz wrote:



On Jan 24, 2016, at 3:17 PM, Gilles
 wrote:


Just plain and simple "Apache Math" maybe?
Or is it taken already?


It's not taken; but I thought it was too broad-sounding and in
fact
umbrella-ish.  There are other ASF projects that do
math-relates things.  I
think adding "components" makes it look more like a library of
base
components that other math-related projects can use.

Phil


Gilles

On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:



On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going
to do.


This is slightly jumping the gun, as we do have the
opportunity in
forming the new TLP to revisit the initial goals of [math];
but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to
common math
programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release
artifacts.
Similar in some ways to what happened with [http], which is
why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much
like
that idea as whoever you choose, you end up loading some math
area
and / or cultural bias into the name.

Phil


Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton?
Apache Euler?
Apache Euclid?

On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz


wrote:

We need to agree on a name.  My own preference is for a
boring,
descriptive name, but I am manifestly not a marketing guy,
so won't
be offended if others want to be more creative.

My suggestion is

MathComponents


I would be happy with either Math Components or Math.
Also I do favor fancy acronyms that read exactly as well known
names


One that I thought of kind of like that was another current ASF name
ripoff:

JAML (Java Apache Math Library) imitating JAMES.


Oh no, too close to YAML! ;-)
And, as an ending, "ML" is usually acronym for "markup language".

:-P


(23 years ago, the name of my first mathematics library was
an acronym that read "Cantor"), it is probably not a good idea for
this new TLP.

In any case, the project will most probably be de facto an umbrella
project as modularizing it seems in the current mood.


Modularization does not mean becoming an umbrella project.  It just
means we distribute multiple jars.   In any case, the scope
limitation that I thought good to somehow imply in the name was that
what we aim to produce is a base library in Java.


"Base library" is much too blurred.
Currently, what CM actually is a toolbox collection of what the PMC
agreed to put in, not more not less. Some things are pretty basic in
some sense (MathArrays), some are pretty not basic at all (BSP).

It would make it much clearer if we could agree to think deeply about
the requirements and purpose of modularization.

That could help a lot in defining the scope(s).


Gilles



Phil


best regards,
Luc



Hearkens back to HttpComponents, which has worked pretty 
well.


Phil






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

Re: [math] Name of the new TLP

[Phil Steitz]

On 1/25/16 7:01 AM, Gilles wrote:
> On Mon, 25 Jan 2016 06:47:40 -0700, Phil Steitz wrote:
>> On 1/25/16 12:40 AM, Ole Ersoy wrote:
>>> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
>>> networks, clustering, monte carlo, simplex...These need an
>>> umbrella.  Some of the other Apache projects that do math may be
>>> interested in moving that piece under the Apache Math umbrella.
>>
>> The ASF does not look favorably on "umbrella" projects.  This is
>> because in these projects, the individual volunteers making up the
>> PMC inevitably lose sight of the full project.  The governance model
>> that we have at Apache has no layers in it beneath the PMC.  That
>> means PMCs need to be focused.  "All things X" PMCs don't work.  The
>> canonical example of that was Jakarta, which started as "all things
>> Java" and was eventually split up.  We should definitely not try to
>> be "all things math" at the ASF.  A better focus would be a nice set
>> math components in Java that other math-related projects inside and
>> outside the ASF can use.  Kind of like, um, Commons Math as its own
>> TLP :)
>
> The problem is that Commons Math is "all things math-related that the
> PMC agreed to put in".  It is an umbrella in the sense you
> describe here
> (even if obviously cannot preclude other project to implement math
> routines).
>
> We have seen that a CM-like project has advantages and drawbacks, for
> developers and users.
>
> It makes sense to dig further into Ole's proposal towards
> modularization
> because, if it is as you say above, then different modules may
> have to
> become different projects!
>
> If they don't have to, then I don't understand your argument.
>
> Or it is a fight on the use of the word "umbrella"?

The ASF principle is simple:  the PMC has to provide active
oversight of the project.  That means that you can't have a single
project effectively split into several smaller ones with individual
PMC members providing oversight to parts, but not the whole.  When
that starts to happen, you need to break the project apart.  Just
distributing separate jars does not force that to happen. 

Phil
>
> Gilles
>
>
>> Phil
>>>
>>> Personally I like to see each in a separate repository dedicated
>>> to the subject, along with the corresponding documentation, etc 
>>> So:
>>> apache-math (Central repository describing the project as a whole
>>> with the documentation that cuts across modules)
>>> apache-math-linear-real
>>> apache-math-linear-field
>>> apache-math-optimization-genetic
>>> apache-math-optimization-simplex
>>> etc.
>>>
>>> And hopefully:
>>> apache-math-optimization-integer
>>> apache-math-optimization-mixed
>>> And more..
>>>
>>> Cheers,
>>> Ole
>>>
>>> On 01/24/2016 04:41 PM, Phil Steitz wrote:

> On Jan 24, 2016, at 3:17 PM, Gilles
>  wrote:
>
> Just plain and simple "Apache Math" maybe?
> Or is it taken already?
 It's not taken; but I thought it was too broad-sounding and in
 fact umbrella-ish.  There are other ASF projects that do
 math-relates things.  I think adding "components" makes it look
 more like a library of base components that other math-related
 projects can use.

 Phil
> Gilles
>
>> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
>>> On 1/24/16 2:16 PM, James Carman wrote:
>>> I guess it depends on the scope of what the new TLP is going
>>> to do.
>> This is slightly jumping the gun, as we do have the
>> opportunity in
>> forming the new TLP to revisit the initial goals of [math];
>> but I
>> suspect that initially at least we will mostly continue to be a
>> general-purpose Java math library, trying to provide IP-clean,
>> easily integrated, standard algorithm-based solutions to common
>> math
>> programming problems.  We have grown to the point where we will
>> almost certainly break the distribution up into separate
>> "components."  No umbrella, but likely multiple release
>> artifacts.
>> Similar in some ways to what happened with [http], which is
>> why I
>> suggested the same approach to naming.
>>
>> Regarding picking a mathematician for the name, I don't much
>> like
>> that idea as whoever you choose, you end up loading some math
>> area
>> and / or cultural bias into the name.
>>
>> Phil
>>> Umbrella projects aren't that popular these days, from what I
>>> understand.
>>> Maybe an homage to a famous mathematician? Apache Newton?
>>> Apache Euler?
>>> Apache Euclid?
>>>
 On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz
  wrote:

 We need to agree on a name.  My own preference is for a
 boring,
 descriptive name, but I am manifestly not a marketing guy, so
 won't
 be offended if others want to be more creative.

 My suggestion is

 MathComponents

 Hear

Re: [math] Name of the new TLP

[Hasan Diwan]

Megginson is a Souix mathematician , so perhaps Meggison.apache.org ? -- H

On 24 January 2016 at 23:52, Benedikt Ritter  wrote:

> Hi,
>
> I very much like the idea of taking the name of a famous mathematician.
> If it has to be some thing more descriptive: Apache Commons HttpClient went
> to Apache HttpComponents. How about Apache Math Components as TLP name?
>
> Benedikt
>
> 2016-01-25 8:40 GMT+01:00 Ole Ersoy :
>
> > Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
> > networks, clustering, monte carlo, simplex...These need an umbrella.
> Some
> > of the other Apache projects that do math may be interested in moving
> that
> > piece under the Apache Math umbrella.
> >
> > Personally I like to see each in a separate repository dedicated to the
> > subject, along with the corresponding documentation, etc  So:
> > apache-math (Central repository describing the project as a whole with
> the
> > documentation that cuts across modules)
> > apache-math-linear-real
> > apache-math-linear-field
> > apache-math-optimization-genetic
> > apache-math-optimization-simplex
> > etc.
> >
> > And hopefully:
> > apache-math-optimization-integer
> > apache-math-optimization-mixed
> > And more..
> >
> > Cheers,
> > Ole
> >
> >
> > On 01/24/2016 04:41 PM, Phil Steitz wrote:
> >
> >>
> >> On Jan 24, 2016, at 3:17 PM, Gilles 
> wrote:
> >>>
> >>> Just plain and simple "Apache Math" maybe?
> >>> Or is it taken already?
> >>>
> >> It's not taken; but I thought it was too broad-sounding and in fact
> >> umbrella-ish.  There are other ASF projects that do math-relates
> things.  I
> >> think adding "components" makes it look more like a library of base
> >> components that other math-related projects can use.
> >>
> >> Phil
> >>
> >>> Gilles
> >>>
> >>> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
> 
> > On 1/24/16 2:16 PM, James Carman wrote:
> > I guess it depends on the scope of what the new TLP is going to do.
> >
>  This is slightly jumping the gun, as we do have the opportunity in
>  forming the new TLP to revisit the initial goals of [math]; but I
>  suspect that initially at least we will mostly continue to be a
>  general-purpose Java math library, trying to provide IP-clean,
>  easily integrated, standard algorithm-based solutions to common math
>  programming problems.  We have grown to the point where we will
>  almost certainly break the distribution up into separate
>  "components."  No umbrella, but likely multiple release artifacts.
>  Similar in some ways to what happened with [http], which is why I
>  suggested the same approach to naming.
> 
>  Regarding picking a mathematician for the name, I don't much like
>  that idea as whoever you choose, you end up loading some math area
>  and / or cultural bias into the name.
> 
>  Phil
> 
> > Umbrella projects aren't that popular these days, from what I
> > understand.
> > Maybe an homage to a famous mathematician? Apache Newton? Apache
> Euler?
> > Apache Euclid?
> >
> > On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 
> >> wrote:
> >>
> >> We need to agree on a name.  My own preference is for a boring,
> >> descriptive name, but I am manifestly not a marketing guy, so won't
> >> be offended if others want to be more creative.
> >>
> >> My suggestion is
> >>
> >> MathComponents
> >>
> >> Hearkens back to HttpComponents, which has worked pretty well.
> >>
> >> Phil
> >>
> >
> >>> -
> >>> 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
> >>
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> http://home.apache.org/~britter/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>



-- 
OpenPGP: https://hasan.d8u.us/gpg.key
Sent from my mobile device
Envoyé de mon portable

Re: [math] Name of the new TLP

[Schalk Cronjé]

By matter of assocation (and some expressive freedom).

Ajama -> Adama -> Battlestar Galactica -> Galactica -> Mathelactica.

And thus: Mathelactica the Apache Mathematics library

I think that name can fly (pun intented).

Regards

On 25/01/2016 13:24, Gilles wrote:

On Mon, 25 Jan 2016 13:41:46 +0100, Emmanuel Bourg wrote:

Le 25/01/2016 13:21, Gilles a écrit :


 * AJaMa
?

The last one is short while fully descriptive:
  AJaMa
   is
the Apache JAva MAthematics library


This one will probably sound too similar with Jama, another math 
library:


http://math.nist.gov/javanumerics/jama/


I made the proposal knowing about this.

A few years ago, the JAMA project had been declared dead (although I 
do not

find the announcement page).
Anyways, it has not been updated since November 2012.
To be sure we could ask them.

A similar sounding name could be taken as a tribute... ;-)


Will the new TLP focus on Java libraries exclusively or will it be open
to implementations in other languages?


This is also a fundamental question.

Given that we could not even agree to evolve with the JDK (last 
release of

CM had to be Java *5* source-compatible!), it would be a (bad) joke (or a
revolution!) to throw other languages into the discussion.

Gilles



Emmanuel Bourg



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




--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r


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

Re: [math] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 07:15:20 -0700, Phil Steitz wrote:

On 1/25/16 7:01 AM, Gilles wrote:

On Mon, 25 Jan 2016 06:47:40 -0700, Phil Steitz wrote:

On 1/25/16 12:40 AM, Ole Ersoy wrote:

Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an
umbrella.  Some of the other Apache projects that do math may be
interested in moving that piece under the Apache Math umbrella.


The ASF does not look favorably on "umbrella" projects.  This is
because in these projects, the individual volunteers making up the
PMC inevitably lose sight of the full project.  The governance 
model

that we have at Apache has no layers in it beneath the PMC.  That
means PMCs need to be focused.  "All things X" PMCs don't work.  
The

canonical example of that was Jakarta, which started as "all things
Java" and was eventually split up.  We should definitely not try to
be "all things math" at the ASF.  A better focus would be a nice 
set

math components in Java that other math-related projects inside and
outside the ASF can use.  Kind of like, um, Commons Math as its own
TLP :)


The problem is that Commons Math is "all things math-related that 
the

PMC agreed to put in".  It is an umbrella in the sense you
describe here
(even if obviously cannot preclude other project to implement math
routines).

We have seen that a CM-like project has advantages and drawbacks, 
for

developers and users.

It makes sense to dig further into Ole's proposal towards
modularization
because, if it is as you say above, then different modules may
have to
become different projects!

If they don't have to, then I don't understand your argument.

Or it is a fight on the use of the word "umbrella"?


The ASF principle is simple:  the PMC has to provide active
oversight of the project.  That means that you can't have a single
project effectively split into several smaller ones with individual
PMC members providing oversight to parts, but not the whole.  When
that starts to happen, you need to break the project apart.  Just
distributing separate jars does not force that to happen.


It is a sound principle.
But is it always applicable in practice?

I mean, for CM precisely, it is not true that everyone oversees
to whole code base.  The following situations happened:
* single individuals coded (or refactored) almost everything in a
  package and nobody else participated in the design, or reviewed
  the resulting code
* some packages are too venerable to be touched by newbies
* code contained crippling bugs, that have gone unnoticed for a long
  time
* some people want to refactor part or the whole of a package but
  others block it on non-technical ground

Hence, without bypassing the good principle, it could be made clear
that some people are more interested or knowledgeable in some area
of the library, and thus the primary (informal) responsible for its
design, not precluding the binding advice of other PMC members.
There should be consensus... (?) on the principle of how to adapt the
principle to reality.

Then modules with better defined scopes could be developed according
to possibly different policies (see "PMC volunteering" thread).


Gilles




Phil


Gilles



Phil


Personally I like to see each in a separate repository dedicated
to the subject, along with the corresponding documentation, etc
So:
apache-math (Central repository describing the project as a whole
with the documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole

On 01/24/2016 04:41 PM, Phil Steitz wrote:



On Jan 24, 2016, at 3:17 PM, Gilles
 wrote:

Just plain and simple "Apache Math" maybe?
Or is it taken already?

It's not taken; but I thought it was too broad-sounding and in
fact umbrella-ish.  There are other ASF projects that do
math-relates things.  I think adding "components" makes it look
more like a library of base components that other math-related
projects can use.

Phil

Gilles


On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:

On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going
to do.

This is slightly jumping the gun, as we do have the
opportunity in
forming the new TLP to revisit the initial goals of [math];
but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common
math
programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release
artifacts.
Similar in some ways to what happened with [http], which is
why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don

Re: [math] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 14:38:42 +, Schalk Cronjé wrote:

By matter of assocation (and some expressive freedom).

Ajama -> Adama -> Battlestar Galactica -> Galactica -> 
Mathelactica.


And thus: Mathelactica the Apache Mathematics library


Sounds more adapted to a milk factory... ;-)

Gilles


I think that name can fly (pun intented).

Regards

On 25/01/2016 13:24, Gilles wrote:

On Mon, 25 Jan 2016 13:41:46 +0100, Emmanuel Bourg wrote:

Le 25/01/2016 13:21, Gilles a écrit :


 * AJaMa
?

The last one is short while fully descriptive:
  AJaMa
   is
the Apache JAva MAthematics library


This one will probably sound too similar with Jama, another math 
library:


http://math.nist.gov/javanumerics/jama/


I made the proposal knowing about this.

A few years ago, the JAMA project had been declared dead (although I 
do not

find the announcement page).
Anyways, it has not been updated since November 2012.
To be sure we could ask them.

A similar sounding name could be taken as a tribute... ;-)

Will the new TLP focus on Java libraries exclusively or will it be 
open

to implementations in other languages?


This is also a fundamental question.

Given that we could not even agree to evolve with the JDK (last 
release of
CM had to be Java *5* source-compatible!), it would be a (bad) joke 
(or a

revolution!) to throw other languages into the discussion.

Gilles



Emmanuel Bourg




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




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

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Matt Benson]

On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory  wrote:
> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory 
> wrote:
>
>> Antlib's Clirr report has a lot of errors:
>> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
>>
>> This is not documented in the release notes.
>>
>
> I am not -1'ing this but it needs an explanation.

Thanks for catching this. However, I am at a loss except to say that,
largely, these results are incorrect. The various classes belonging to
the org.apache.tools.* namespace  are Ant classes that were
accidentally shaded in with the 1.1 release (Ant artifacts had to be
promoted to compile scope so that clirr could even run), so their
removal was deliberate--I'm sure I don't need to explain why our
Antlib shouldn't bundle Ant's own classes. Several more claimed
removals are of classes that were shaded in from commons-lang3 and
Geronimo's xbean-finder libraries. I expect that these are incorrect
anyway, but as they don't truly constitute part of the public API of
the Antlib I would argue that they are immaterial here as long as the
integration tests succeed, which they do. The remaining claimed
removals are of classes shaded from the commons-weaver-processor
artifact; I have verified that all the classes named remain in the jar
so I have no idea why the report would generate false positives.

With that information in hand, where do you now stand on this, Gary?

Matt

>
> Gary
>
>
>>
>> Gary
>>
>> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson  wrote:
>>
>>> I would like to release the [weaver] component.
>>>
>>> Apache Commons Weaver 1.2 RC2 is available for review at:
>>>   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).
>>>
>>> Maven artifacts are at:
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1141
>>> .
>>>
>>> Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
>>>
>>> The Subversion tag is:
>>>   http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
>>> (r1726007
>>> 
>>> ).
>>>
>>> Site (note some links may be broken; this will be fixed when the site
>>> is deployed):
>>>   http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
>>>
>>> RAT Report:
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
>>>
>>> Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
>>>
>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html
>>>
>>> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
>>>
>>> Please review the release candidate and vote.
>>>   This vote will close no sooner than 72 hours from now, i.e. after
>>> 1900UTC 24-January 2016
>>>
>>>   [ ] +1 Release these artifacts
>>>   [ ] +0 OK, but...
>>>   [ ] -0 OK, but really should fix...
>>>   [ ] -1 I oppose this release because...
>>>
>>>   Thanks!
>>>
>>> -
>>> 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
>>
>
>
>
> --
> 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: 

Re: [math] Volunteer for the new TLP PMC

[Phil Steitz]

On 1/25/16 6:05 AM, Gilles wrote:
> On Sun, 24 Jan 2016 13:54:51 -0700, Phil Steitz wrote:
>> Please respond to this thread if you are a Commons Committer
>> interested in joining the PMC for the new TLP based on [math].
>>
>> Thanks!
>>
>> Phil
>
> I'm interested in as much as I'm being curious to see if it
> will change anything! :-}

Does this mean you are volunteering for the PMC? 

Phil
>
> There were a few "negative" arguments, that is was better to
> stop "annoying" the other Commons projects. [To which some
> responded that they'd prefer the status quo.]
>
> The rationale concerning the size, scope, and management of
> Commons Math, (and how different it was from all the other
> Commons components), I had brought up on several occasions in
> the past.
>
> What has changed?
>
> What are the "positive" arguments?
>
> To be crystal-clear, if the new PMC is composed of the same
> people who are the regular contributors to the Commons Math
> project, i.e. with the same confronting blocks, I don't see
> from where the incentive towards a different development policy
> will come.
>
> Various points have been brought up in (too often heated)
> discussions (JDK version, development and release policies
> such as compatibility, refactoring, multi-threading, exception
> handling, etc.).
>
> I think that the volunteers for the new PMC should list their
> opinion on fundamental issues that obviously define a "vision"
> of the project.
>
> Lacking clear goals[1] is not going to help in any way.
> At this point, we can expect administrative chores.
> Wouldn't it be a pity to do all that work just to get a new
> name?
>
>
> Regards,
> Gilles
>
> [1] There can be seemingly contradictory goals as long as they
> are acknowledged and do not hamper each other (like I've
> expressed in other posts) and sufficient resources exist to
> handle them.
>
>
> -
> 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] Name of the new TLP

[Ole Ersoy]

I like any name that is simple (It's also good if it has a nice ring to it).  
If we are hoping to incorporate more modules from other projects then perhaps 
'apache-davinci'?  I like 'apache-epsilon' as well.

On 01/25/2016 05:40 AM, sebb wrote:

On 25 January 2016 at 09:28, luc  wrote:

Le 2016-01-25 08:52, Benedikt Ritter a écrit :

Hi,

I very much like the idea of taking the name of a famous mathematician.

In which case it has to be

Euclid or Pythagoras (early)
or
Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number

and everyone has heard of
John Nash (Beautiful Mind)

etc.
In the spirit of recent discussions, how about a RNG to pick the
mathematician's name for each next incarnation?

;-)


If it has to be some thing more descriptive: Apache Commons HttpClient
went
to Apache HttpComponents. How about Apache Math Components as TLP name?

I quite like Apache Epsilon as a non-descriptive but related name.

[ducks behind bikshed]


Benedikt

2016-01-25 8:40 GMT+01:00 Ole Ersoy :


Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an umbrella.
Some
of the other Apache projects that do math may be interested in moving
that
piece under the Apache Math umbrella.

Personally I like to see each in a separate repository dedicated to the
subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a whole with
the
documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole


On 01/24/2016 04:41 PM, Phil Steitz wrote:


On Jan 24, 2016, at 3:17 PM, Gilles 
wrote:


Just plain and simple "Apache Math" maybe?
Or is it taken already?


It's not taken; but I thought it was too broad-sounding and in fact
umbrella-ish.  There are other ASF projects that do math-relates things.
I
think adding "components" makes it look more like a library of base
components that other math-related projects can use.

Phil


Gilles

On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:



On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going to do.


This is slightly jumping the gun, as we do have the opportunity in
forming the new TLP to revisit the initial goals of [math]; but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common math
programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release artifacts.
Similar in some ways to what happened with [http], which is why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much like
that idea as whoever you choose, you end up loading some math area
and / or cultural bias into the name.

Phil


Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton? Apache
Euler?
Apache Euclid?

On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 

wrote:

We need to agree on a name.  My own preference is for a boring,
descriptive name, but I am manifestly not a marketing guy, so won't
be offended if others want to be more creative.

My suggestion is

MathComponents


I would be happy with either Math Components or Math.
Also I do favor fancy acronyms that read exactly as well known
names (23 years ago, the name of my first mathematics library was
an acronym that read "Cantor"), it is probably not a good idea for
this new TLP.

In any case, the project will most probably be de facto an umbrella
project as modularizing it seems in the current mood.

best regards,
Luc



Hearkens back to HttpComponents, which has worked pretty well.

Phil


-
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




-
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


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

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[sebb]

On 25 January 2016 at 15:47, Matt Benson  wrote:
> On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory  wrote:
>> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory 
>> wrote:
>>
>>> Antlib's Clirr report has a lot of errors:
>>> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
>>>
>>> This is not documented in the release notes.
>>>
>>
>> I am not -1'ing this but it needs an explanation.
>
> Thanks for catching this. However, I am at a loss except to say that,
> largely, these results are incorrect. The various classes belonging to
> the org.apache.tools.* namespace  are Ant classes that were
> accidentally shaded in with the 1.1 release (Ant artifacts had to be
> promoted to compile scope so that clirr could even run), so their
> removal was deliberate--I'm sure I don't need to explain why our
> Antlib shouldn't bundle Ant's own classes. Several more claimed
> removals are of classes that were shaded in from commons-lang3 and
> Geronimo's xbean-finder libraries. I expect that these are incorrect
> anyway, but as they don't truly constitute part of the public API of
> the Antlib I would argue that they are immaterial here as long as the
> integration tests succeed, which they do. The remaining claimed
> removals are of classes shaded from the commons-weaver-processor
> artifact; I have verified that all the classes named remain in the jar
> so I have no idea why the report would generate false positives.
>
> With that information in hand, where do you now stand on this, Gary?

The information is now at hand in this e-mail thread.

However if the Clirr report is published without correction, that
won't help people who come across the Clirr report.

The release notes is one place to document the issue; there may be others.

> Matt
>
>>
>> Gary
>>
>>
>>>
>>> Gary
>>>
>>> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson  wrote:
>>>
 I would like to release the [weaver] component.

 Apache Commons Weaver 1.2 RC2 is available for review at:
   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).

 Maven artifacts are at:

 https://repository.apache.org/content/repositories/orgapachecommons-1141
 .

 Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.

 The Subversion tag is:
   http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
 (r1726007
 
 ).

 Site (note some links may be broken; this will be fixed when the site
 is deployed):
   http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html

 RAT Report:

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html

 Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html

 http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html

 Keys: https://dist.apache.org/repos/dist/release/commons/KEYS

 Please review the release candidate and vote.
   This vote will close no sooner than 72 hours from now, i.e. after
 1900UTC 24-January 2016

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

   Thanks!

 -
 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
>>>
>>
>>
>>
>> --
>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>> Java Persistence with Hibernate, Second Edition
>> 

Re: [math] Name of the new TLP

[Gary Gregory]

Note that we can change the name Apache Commons Math to Apache Commons
Cutesy name as well as turn it into a multi-module project. You do not need
a TLP to do that.

I see lots of email about name change but not many about why this component
would better serve its community under a TLP and/or different PMC and/or
policies.

Where's the beef?! ;-)

Gary
On Jan 25, 2016 9:00 AM, "Ole Ersoy"  wrote:

> I like any name that is simple (It's also good if it has a nice ring to
> it).  If we are hoping to incorporate more modules from other projects then
> perhaps 'apache-davinci'?  I like 'apache-epsilon' as well.
>
> On 01/25/2016 05:40 AM, sebb wrote:
>
>> On 25 January 2016 at 09:28, luc  wrote:
>>
>>> Le 2016-01-25 08:52, Benedikt Ritter a écrit :
>>>
 Hi,

 I very much like the idea of taking the name of a famous mathematician.

>>> In which case it has to be
>>
>> Euclid or Pythagoras (early)
>> or
>> Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number
>>
>> and everyone has heard of
>> John Nash (Beautiful Mind)
>>
>> etc.
>> In the spirit of recent discussions, how about a RNG to pick the
>> mathematician's name for each next incarnation?
>>
>> ;-)
>>
>> If it has to be some thing more descriptive: Apache Commons HttpClient
 went
 to Apache HttpComponents. How about Apache Math Components as TLP name?

>>> I quite like Apache Epsilon as a non-descriptive but related name.
>>
>> [ducks behind bikshed]
>>
>> Benedikt

 2016-01-25 8:40 GMT+01:00 Ole Ersoy :

 Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
> networks, clustering, monte carlo, simplex...These need an umbrella.
> Some
> of the other Apache projects that do math may be interested in moving
> that
> piece under the Apache Math umbrella.
>
> Personally I like to see each in a separate repository dedicated to the
> subject, along with the corresponding documentation, etc  So:
> apache-math (Central repository describing the project as a whole with
> the
> documentation that cuts across modules)
> apache-math-linear-real
> apache-math-linear-field
> apache-math-optimization-genetic
> apache-math-optimization-simplex
> etc.
>
> And hopefully:
> apache-math-optimization-integer
> apache-math-optimization-mixed
> And more..
>
> Cheers,
> Ole
>
>
> On 01/24/2016 04:41 PM, Phil Steitz wrote:
>
> On Jan 24, 2016, at 3:17 PM, Gilles 
>> wrote:
>>
>>>
>>> Just plain and simple "Apache Math" maybe?
>>> Or is it taken already?
>>>
>>> It's not taken; but I thought it was too broad-sounding and in fact
>> umbrella-ish.  There are other ASF projects that do math-relates
>> things.
>> I
>> think adding "components" makes it look more like a library of base
>> components that other math-related projects can use.
>>
>> Phil
>>
>> Gilles
>>>
>>> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
>>>

 On 1/24/16 2:16 PM, James Carman wrote:
> I guess it depends on the scope of what the new TLP is going to do.
>
> This is slightly jumping the gun, as we do have the opportunity in
 forming the new TLP to revisit the initial goals of [math]; but I
 suspect that initially at least we will mostly continue to be a
 general-purpose Java math library, trying to provide IP-clean,
 easily integrated, standard algorithm-based solutions to common math
 programming problems.  We have grown to the point where we will
 almost certainly break the distribution up into separate
 "components."  No umbrella, but likely multiple release artifacts.
 Similar in some ways to what happened with [http], which is why I
 suggested the same approach to naming.

 Regarding picking a mathematician for the name, I don't much like
 that idea as whoever you choose, you end up loading some math area
 and / or cultural bias into the name.

 Phil

 Umbrella projects aren't that popular these days, from what I
> understand.
> Maybe an homage to a famous mathematician? Apache Newton? Apache
> Euler?
> Apache Euclid?
>
> On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz  >
>
>> wrote:
>>
>> We need to agree on a name.  My own preference is for a boring,
>> descriptive name, but I am manifestly not a marketing guy, so
>> won't
>> be offended if others want to be more creative.
>>
>> My suggestion is
>>
>> MathComponents
>>
>
>>> I would be happy with either Math Components or Math.
>>> Also I do favor fancy acronyms that read exactly as well known
>>> names (23 years ago, the name of my first mathematics library was
>>

Re: [math] Name of the new TLP

[Gilles]

On Mon, 25 Jan 2016 09:17:43 -0800, Gary Gregory wrote:
Note that we can change the name Apache Commons Math to Apache 
Commons
Cutesy name as well as turn it into a multi-module project. You do 
not need

a TLP to do that.


AFAICT, the real issue is one of policy: Commons is supposed to be 
stable,

stable, stable and stable (IIUC).

And CM is far from being mature as a programming project, when 
considering
design and scope, and not only the quality of its results and 
performance

(which are both good in many cases).
So stability (as in using JDK 5 only) is not a good perspective (surely 
not

developers and probably not for users either IMO).

If this does not change, what's the point indeed?

I see lots of email about name change but not many about why this 
component
would better serve its community under a TLP and/or different PMC 
and/or

policies.


My take on that has been shared on several occasions.

You are right quite right that the people who previously opposed the
creation of a different TLP did not say much, if anything, about what
has changed since then.
And, more importantly, what will change, as you point out here and as
I did in the other thread ("Volunteer for the new TLP PMC").


Gilles


Where's the beef?! ;-)

Gary
On Jan 25, 2016 9:00 AM, "Ole Ersoy"  wrote:

I like any name that is simple (It's also good if it has a nice ring 
to
it).  If we are hoping to incorporate more modules from other 
projects then

perhaps 'apache-davinci'?  I like 'apache-epsilon' as well.

On 01/25/2016 05:40 AM, sebb wrote:


On 25 January 2016 at 09:28, luc  wrote:


Le 2016-01-25 08:52, Benedikt Ritter a écrit :


Hi,

I very much like the idea of taking the name of a famous 
mathematician.



In which case it has to be


Euclid or Pythagoras (early)
or
Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number

and everyone has heard of
John Nash (Beautiful Mind)

etc.
In the spirit of recent discussions, how about a RNG to pick the
mathematician's name for each next incarnation?

;-)

If it has to be some thing more descriptive: Apache Commons 
HttpClient

went
to Apache HttpComponents. How about Apache Math Components as TLP 
name?



I quite like Apache Epsilon as a non-descriptive but related name.


[ducks behind bikshed]

Benedikt


2016-01-25 8:40 GMT+01:00 Ole Ersoy :

Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an 
umbrella.

Some
of the other Apache projects that do math may be interested in 
moving

that
piece under the Apache Math umbrella.

Personally I like to see each in a separate repository dedicated 
to the

subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a 
whole with

the
documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole


On 01/24/2016 04:41 PM, Phil Steitz wrote:

On Jan 24, 2016, at 3:17 PM, Gilles 


wrote:



Just plain and simple "Apache Math" maybe?
Or is it taken already?

It's not taken; but I thought it was too broad-sounding and in 
fact
umbrella-ish.  There are other ASF projects that do 
math-relates

things.
I
think adding "components" makes it look more like a library of 
base

components that other math-related projects can use.

Phil

Gilles


On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:



On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going 
to do.


This is slightly jumping the gun, as we do have the 
opportunity in
forming the new TLP to revisit the initial goals of [math]; 
but I
suspect that initially at least we will mostly continue to be 
a
general-purpose Java math library, trying to provide 
IP-clean,
easily integrated, standard algorithm-based solutions to 
common math
programming problems.  We have grown to the point where we 
will

almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release 
artifacts.
Similar in some ways to what happened with [http], which is 
why I

suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much 
like
that idea as whoever you choose, you end up loading some math 
area

and / or cultural bias into the name.

Phil

Umbrella projects aren't that popular these days, from what I

understand.
Maybe an homage to a famous mathematician? Apache Newton? 
Apache

Euler?
Apache Euclid?

On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 

>


wrote:

We need to agree on a name.  My own preference is for a 
boring,
descriptive name, but I am manifestly not a marketing guy, 
so

won't
be offended if others want to be more creative.

My suggestion is

MathComponents




I would be happy with either Math Components or Math.
Also I

Re: [math] Name of the new TLP

[Ole Ersoy]

The general pattern that I'm seeing within the NodeJS community is that big 
projects are being broken up into smaller projects and those smaller projects 
are being broken up yet again, etc.  What I find refreshing about that is that 
it's pretty simple to find a component / module that I need for which I can 
read the example and get up to speed in 5 minutes and if needed read the source 
code in less than an hour.

In contrast I'm spending a fairly significant amount of time attempting to 
break up CM into smaller, simpler, more easily digestible pieces.  Once 
something becomes a big library it's very hard to manage it elegantly. Small 
projects are easy to manage.  For example I'm combining Twitter Bootstrap and 
SUIT-CSS into a framework called superfly-css.  If you search for it on npmjs 
all the modules pop up (A combination of tools and css components):

https://www.npmjs.com/search?q=superfly-css

Each module links back to the parent module for usage documentation, install, 
design guidelines, etc.  The superfly-css organization landing page is going to 
outline all the tool and component modules.  Each module can have a gh-pages 
branch containing the site for the module if necessary.

I have a very easy time managing this and anyone who uses it gets precisely 
what they need.  It's like ordering Sushi :) and the process for using the 
modules is almost that simple.

This is the best argument I have seen for taking a modular approach:
https://github.com/substack/browserify-handbook#module-philosophy

As an example directly related to CM have a look at the now fairly complete 
firefly-math-exceptions module:
https://github.com/firefly-math/firefly-math-exceptions

Anyone on this list can probably read the source in about 10 minutes.  It's 
very easy to integrate / extend this into any (CM or non CM) math project.  So 
if we create an organization structure targeting small simple modules I think 
we will have a lot more fun with this.

Cheers,
Ole


On 01/25/2016 07:47 AM, Phil Steitz wrote:

On 1/25/16 12:40 AM, Ole Ersoy wrote:

Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an
umbrella.  Some of the other Apache projects that do math may be
interested in moving that piece under the Apache Math umbrella.

The ASF does not look favorably on "umbrella" projects.  This is
because in these projects, the individual volunteers making up the
PMC inevitably lose sight of the full project.  The governance model
that we have at Apache has no layers in it beneath the PMC.  That
means PMCs need to be focused.  "All things X" PMCs don't work.  The
canonical example of that was Jakarta, which started as "all things
Java" and was eventually split up.  We should definitely not try to
be "all things math" at the ASF.  A better focus would be a nice set
math components in Java that other math-related projects inside and
outside the ASF can use.  Kind of like, um, Commons Math as its own
TLP :)

Phil

Personally I like to see each in a separate repository dedicated
to the subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a whole
with the documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole

On 01/24/2016 04:41 PM, Phil Steitz wrote:

On Jan 24, 2016, at 3:17 PM, Gilles
 wrote:

Just plain and simple "Apache Math" maybe?
Or is it taken already?

It's not taken; but I thought it was too broad-sounding and in
fact umbrella-ish.  There are other ASF projects that do
math-relates things.  I think adding "components" makes it look
more like a library of base components that other math-related
projects can use.

Phil

Gilles


On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:

On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going
to do.

This is slightly jumping the gun, as we do have the opportunity in
forming the new TLP to revisit the initial goals of [math]; but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common
math
programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release artifacts.
Similar in some ways to what happened with [http], which is why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much like
that idea as whoever you choose, you end up loading some math area
and / or cultural bias into the name.

Phil

Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a fam

Re: [math] Name of the new TLP

[Emmanuel Bourg]

Le 25/01/2016 18:52, Gilles a écrit :

> AFAICT, the real issue is one of policy: Commons is supposed to be stable,
> stable, stable and stable (IIUC).
> 
> And CM is far from being mature as a programming project, when considering
> design and scope, and not only the quality of its results and performance
> (which are both good in many cases).
> So stability (as in using JDK 5 only) is not a good perspective (surely not
> developers and probably not for users either IMO).
> 
> If this does not change, what's the point indeed?

I hope that a motivation behind the TLP isn't to break the compatibility
on every release, otherwise this will quickly turn into a nightmare for
the users. Bouncycastle plays this game and it isn't really fun to follow :(

Emmanuel Bourg


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

Re: [math] Name of the new TLP

[Gary Gregory]

On Jan 25, 2016 10:11 AM, "Emmanuel Bourg"  wrote:
>
> Le 25/01/2016 18:52, Gilles a écrit :
>
> > AFAICT, the real issue is one of policy: Commons is supposed to be
stable,
> > stable, stable and stable (IIUC).
> >
> > And CM is far from being mature as a programming project, when
considering
> > design and scope, and not only the quality of its results and
performance
> > (which are both good in many cases).
> > So stability (as in using JDK 5 only) is not a good perspective (surely
not
> > developers and probably not for users either IMO).
> >
> > If this does not change, what's the point indeed?
>
> I hope that a motivation behind the TLP isn't to break the compatibility
> on every release, otherwise this will quickly turn into a nightmare for
> the users. Bouncycastle plays this game and it isn't really fun to follow
:(

WRT compatibility, the only thing that matters is not creating jar hell for
users. You can break compatibility if you change package and maven
coordinates. It's up to the project to create enough alphas and betas to
get to a stable public API before a release. That's just basic project
management IMO. Anything less will leave a lot users unhappy.

Gary

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

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Gary Gregory]

On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson  wrote:
>
> On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory 
wrote:
> > On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory 
> > wrote:
> >
> >> Antlib's Clirr report has a lot of errors:
> >>
https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
> >>
> >> This is not documented in the release notes.
> >>
> >
> > I am not -1'ing this but it needs an explanation.
>
> Thanks for catching this. However, I am at a loss except to say that,
> largely, these results are incorrect. The various classes belonging to
> the org.apache.tools.* namespace  are Ant classes that were
> accidentally shaded in with the 1.1 release (Ant artifacts had to be
> promoted to compile scope so that clirr could even run), so their
> removal was deliberate--I'm sure I don't need to explain why our
> Antlib shouldn't bundle Ant's own classes. Several more claimed
> removals are of classes that were shaded in from commons-lang3 and
> Geronimo's xbean-finder libraries. I expect that these are incorrect
> anyway, but as they don't truly constitute part of the public API of
> the Antlib I would argue that they are immaterial here as long as the
> integration tests succeed, which they do. The remaining claimed
> removals are of classes shaded from the commons-weaver-processor
> artifact; I have verified that all the classes named remain in the jar
> so I have no idea why the report would generate false positives.
>
> With that information in hand, where do you now stand on this, Gary?

This needs to be explained clearly in the release notes. Like Sebb said,
there might be other places to document this as well.

Gary

>
>
> Matt
>
> >
> > Gary
> >
> >
> >>
> >> Gary
> >>
> >> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
wrote:
> >>
> >>> I would like to release the [weaver] component.
> >>>
> >>> Apache Commons Weaver 1.2 RC2 is available for review at:
> >>>   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).
> >>>
> >>> Maven artifacts are at:
> >>>
> >>>
https://repository.apache.org/content/repositories/orgapachecommons-1141
> >>> .
> >>>
> >>> Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
> >>>
> >>> The Subversion tag is:
> >>>   http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
> >>> (r1726007
> >>> <
http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/(r1726007
>
> >>> ).
> >>>
> >>> Site (note some links may be broken; this will be fixed when the site
> >>> is deployed):
> >>>   http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
> >>>
> >>> RAT Report:
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
> >>>
> >>> Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
> >>>
> >>>
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html
> >>>
> >>> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
> >>>
> >>> Please review the release candidate and vote.
> >>>   This vote will close no sooner than 72 hours from now, i.e. after
> >>> 1900UTC 24-January 2016
> >>>
> >>>   [ ] +1 Release these artifacts
> >>>   [ ] +0 OK, but...
> >>>   [ ] -0 OK, but really should fix...
> >>>   [ ] -1 I oppose this release because...
> >>>
> >>>   Thanks!
> >>>
> >>> -
> >>> 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
> >>
> >
> >
> >
> > --
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> > Java Persistence with Hibernate, Second Edition
> > 

Re: [math] Name of the new TLP

[Thomas Neidhart]

On 01/25/2016 09:27 PM, Gary Gregory wrote:
> On Jan 25, 2016 10:11 AM, "Emmanuel Bourg"  wrote:
>>
>> Le 25/01/2016 18:52, Gilles a écrit :
>>
>>> AFAICT, the real issue is one of policy: Commons is supposed to be
> stable,
>>> stable, stable and stable (IIUC).
>>>
>>> And CM is far from being mature as a programming project, when
> considering
>>> design and scope, and not only the quality of its results and
> performance
>>> (which are both good in many cases).
>>> So stability (as in using JDK 5 only) is not a good perspective (surely
> not
>>> developers and probably not for users either IMO).
>>>
>>> If this does not change, what's the point indeed?
>>
>> I hope that a motivation behind the TLP isn't to break the compatibility
>> on every release, otherwise this will quickly turn into a nightmare for
>> the users. Bouncycastle plays this game and it isn't really fun to follow
> :(
> 
> WRT compatibility, the only thing that matters is not creating jar hell for
> users. You can break compatibility if you change package and maven
> coordinates. It's up to the project to create enough alphas and betas to
> get to a stable public API before a release. That's just basic project
> management IMO. Anything less will leave a lot users unhappy.

What you describe is the mantra of Commons and while I perfectly agree
with it for certain wide-spread libraries like lang, collections or
logging, the same can not be applied to any other type of library in
existence.

A library like CM is much less used and the danger of creating a jar
hell because of it does not justify such a strict policy. In fact the
Commons policy is one of the reasons why the vote to move to a TLP was
started originally.

There are also other, very respected and mature libraries (like
joda-time) that allow non-compatible changes in major version without
changing package / artefact ids, and the world did not collapse because
of it.

The key point is to be reasonable about the audience of a library, and
CM does not play in the same league as lang or collections for example.
Also a better modularization of the project might help in this respect,
as certain modules might have different maturity levels and users can
expect them to not change much over time, whereas others are more likely
to change but their use is mainly in very specific applications (think
about the optimization package in CM).

We certainly need to think about and express the way we want to organize
CM as a TLP, which really needs to be different to the status quo. I
really hope that the people willing to contribute to CM as a TLP take
this into account, as otherwise there is no point in doing it as Gilles
pointed out correctly.

Thomas

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

Re: [math] Name of the new TLP

[Gary Gregory]

On Jan 25, 2016 12:59 PM, "Thomas Neidhart" 
wrote:
>
> On 01/25/2016 09:27 PM, Gary Gregory wrote:
> > On Jan 25, 2016 10:11 AM, "Emmanuel Bourg"  wrote:
> >>
> >> Le 25/01/2016 18:52, Gilles a écrit :
> >>
> >>> AFAICT, the real issue is one of policy: Commons is supposed to be
> > stable,
> >>> stable, stable and stable (IIUC).
> >>>
> >>> And CM is far from being mature as a programming project, when
> > considering
> >>> design and scope, and not only the quality of its results and
> > performance
> >>> (which are both good in many cases).
> >>> So stability (as in using JDK 5 only) is not a good perspective
(surely
> > not
> >>> developers and probably not for users either IMO).
> >>>
> >>> If this does not change, what's the point indeed?
> >>
> >> I hope that a motivation behind the TLP isn't to break the
compatibility
> >> on every release, otherwise this will quickly turn into a nightmare for
> >> the users. Bouncycastle plays this game and it isn't really fun to
follow
> > :(
> >
> > WRT compatibility, the only thing that matters is not creating jar hell
for
> > users. You can break compatibility if you change package and maven
> > coordinates. It's up to the project to create enough alphas and betas to
> > get to a stable public API before a release. That's just basic project
> > management IMO. Anything less will leave a lot users unhappy.
>
> What you describe is the mantra of Commons and while I perfectly agree
> with it for certain wide-spread libraries like lang, collections or
> logging, the same can not be applied to any other type of library in
> existence.

Must discuss over beers and laughs, just so I do not come across as I'm not
sure what!

The POV about is just not realistic, no matter the library. I know from
personal experience with Apache CXF 2 vs. 3, where CXF did not repackage,
and oh the pain.

What is painful is when you operate in a large stack, say depending on CXF,
Jetty, ActiveMQ, Commons, Teiid and a bunch more. In stacks like these you
do not control all transitive deps, and may the good lord help you if
different parts of the stack depend on diffetent versions of the same
conponents that are not binary compatible. Adding OSGi and/or your own
class losder hacks is not how I want to spend my time.

If everybody plays by the same BC rules, all is well.

Gary

>
> A library like CM is much less used and the danger of creating a jar
> hell because of it does not justify such a strict policy. In fact the
> Commons policy is one of the reasons why the vote to move to a TLP was
> started originally.
>
> There are also other, very respected and mature libraries (like
> joda-time) that allow non-compatible changes in major version without
> changing package / artefact ids, and the world did not collapse because
> of it.
>
> The key point is to be reasonable about the audience of a library, and
> CM does not play in the same league as lang or collections for example.
> Also a better modularization of the project might help in this respect,
> as certain modules might have different maturity levels and users can
> expect them to not change much over time, whereas others are more likely
> to change but their use is mainly in very specific applications (think
> about the optimization package in CM).
>
> We certainly need to think about and express the way we want to organize
> CM as a TLP, which really needs to be different to the status quo. I
> really hope that the people willing to contribute to CM as a TLP take
> this into account, as otherwise there is no point in doing it as Gilles
> pointed out correctly.
>
> Thomas
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Phil Steitz]

On 1/25/16 1:30 PM, Gary Gregory wrote:
> On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson  wrote:
>> On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory 
> wrote:
>>> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory 
>>> wrote:
>>>
 Antlib's Clirr report has a lot of errors:

> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
 This is not documented in the release notes.

>>> I am not -1'ing this but it needs an explanation.
>> Thanks for catching this. However, I am at a loss except to say that,
>> largely, these results are incorrect. The various classes belonging to
>> the org.apache.tools.* namespace  are Ant classes that were
>> accidentally shaded in with the 1.1 release (Ant artifacts had to be
>> promoted to compile scope so that clirr could even run), so their
>> removal was deliberate--I'm sure I don't need to explain why our
>> Antlib shouldn't bundle Ant's own classes. Several more claimed
>> removals are of classes that were shaded in from commons-lang3 and
>> Geronimo's xbean-finder libraries. I expect that these are incorrect
>> anyway, but as they don't truly constitute part of the public API of
>> the Antlib I would argue that they are immaterial here as long as the
>> integration tests succeed, which they do. The remaining claimed
>> removals are of classes shaded from the commons-weaver-processor
>> artifact; I have verified that all the classes named remain in the jar
>> so I have no idea why the report would generate false positives.
>>
>> With that information in hand, where do you now stand on this, Gary?
> This needs to be explained clearly in the release notes. Like Sebb said,
> there might be other places to document this as well.

I don't see the site bundled with the release, unless I am missing
it somewhere.  We release software, not websites.  I see no reason
to clutter the release notes about false positives in maven reports
not included with the release.  I would say fix whatever it is
before republishing the site and move on.

Phil
>
> Gary
>
>>
>> Matt
>>
>>> Gary
>>>
>>>
 Gary

 On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
> wrote:
> I would like to release the [weaver] component.
>
> Apache Commons Weaver 1.2 RC2 is available for review at:
>   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).
>
> Maven artifacts are at:
>
>
> https://repository.apache.org/content/repositories/orgapachecommons-1141
> .
>
> Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
>
> The Subversion tag is:
>   http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
> (r1726007
> <
> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/(r1726007
> ).
>
> Site (note some links may be broken; this will be fixed when the site
> is deployed):
>   http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
>
> RAT Report:
>
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
> Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):
>
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html
> Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
>
> Please review the release candidate and vote.
>   This vote will close no sooner than 72 hours from now, i.e. after
> 1900UTC 24-January 2016
>
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
>   Thanks!
>
> -
> 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 

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Romain Manni-Bucau]

+1, weaver is for now mainly an internal for other asf projects - which are
BTW blocked by this vote - and the binaries are fine. The site can be fixed
anyway when pushed to no reason to hold this release.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Github  |
LinkedIn  | Tomitriber


2016-01-25 23:19 GMT+01:00 Phil Steitz :

> On 1/25/16 1:30 PM, Gary Gregory wrote:
> > On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson  wrote:
> >> On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory 
> > wrote:
> >>> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory 
> >>> wrote:
> >>>
>  Antlib's Clirr report has a lot of errors:
> 
> >
> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
>  This is not documented in the release notes.
> 
> >>> I am not -1'ing this but it needs an explanation.
> >> Thanks for catching this. However, I am at a loss except to say that,
> >> largely, these results are incorrect. The various classes belonging to
> >> the org.apache.tools.* namespace  are Ant classes that were
> >> accidentally shaded in with the 1.1 release (Ant artifacts had to be
> >> promoted to compile scope so that clirr could even run), so their
> >> removal was deliberate--I'm sure I don't need to explain why our
> >> Antlib shouldn't bundle Ant's own classes. Several more claimed
> >> removals are of classes that were shaded in from commons-lang3 and
> >> Geronimo's xbean-finder libraries. I expect that these are incorrect
> >> anyway, but as they don't truly constitute part of the public API of
> >> the Antlib I would argue that they are immaterial here as long as the
> >> integration tests succeed, which they do. The remaining claimed
> >> removals are of classes shaded from the commons-weaver-processor
> >> artifact; I have verified that all the classes named remain in the jar
> >> so I have no idea why the report would generate false positives.
> >>
> >> With that information in hand, where do you now stand on this, Gary?
> > This needs to be explained clearly in the release notes. Like Sebb said,
> > there might be other places to document this as well.
>
> I don't see the site bundled with the release, unless I am missing
> it somewhere.  We release software, not websites.  I see no reason
> to clutter the release notes about false positives in maven reports
> not included with the release.  I would say fix whatever it is
> before republishing the site and move on.
>
> Phil
> >
> > Gary
> >
> >>
> >> Matt
> >>
> >>> Gary
> >>>
> >>>
>  Gary
> 
>  On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
> > wrote:
> > I would like to release the [weaver] component.
> >
> > Apache Commons Weaver 1.2 RC2 is available for review at:
> >   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).
> >
> > Maven artifacts are at:
> >
> >
> > https://repository.apache.org/content/repositories/orgapachecommons-1141
> > .
> >
> > Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
> >
> > The Subversion tag is:
> >
> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
> > (r1726007
> > <
> >
> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/(r1726007
> > ).
> >
> > Site (note some links may be broken; this will be fixed when the site
> > is deployed):
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
> >
> > RAT Report:
> >
> >
> > http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
> > Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):
> >
> >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
> >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
> >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
> >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
> >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html
> >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html
> > Keys: https://dist.apache.org/repos/dist/release/commons/KEYS
> >
> > Please review the release candidate and vote.
> >   This vote will close no sooner than 72

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Gary Gregory]

But the binaries are not BC. Even if that was a silly mistake, the release
notes must note the break in BC.

Gary

On Mon, Jan 25, 2016 at 2:24 PM, Romain Manni-Bucau 
wrote:

> +1, weaver is for now mainly an internal for other asf projects - which are
> BTW blocked by this vote - and the binaries are fine. The site can be fixed
> anyway when pushed to no reason to hold this release.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
> 
>
> 2016-01-25 23:19 GMT+01:00 Phil Steitz :
>
> > On 1/25/16 1:30 PM, Gary Gregory wrote:
> > > On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson 
> wrote:
> > >> On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory  >
> > > wrote:
> > >>> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory <
> garydgreg...@gmail.com>
> > >>> wrote:
> > >>>
> >  Antlib's Clirr report has a lot of errors:
> > 
> > >
> >
> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
> >  This is not documented in the release notes.
> > 
> > >>> I am not -1'ing this but it needs an explanation.
> > >> Thanks for catching this. However, I am at a loss except to say that,
> > >> largely, these results are incorrect. The various classes belonging to
> > >> the org.apache.tools.* namespace  are Ant classes that were
> > >> accidentally shaded in with the 1.1 release (Ant artifacts had to be
> > >> promoted to compile scope so that clirr could even run), so their
> > >> removal was deliberate--I'm sure I don't need to explain why our
> > >> Antlib shouldn't bundle Ant's own classes. Several more claimed
> > >> removals are of classes that were shaded in from commons-lang3 and
> > >> Geronimo's xbean-finder libraries. I expect that these are incorrect
> > >> anyway, but as they don't truly constitute part of the public API of
> > >> the Antlib I would argue that they are immaterial here as long as the
> > >> integration tests succeed, which they do. The remaining claimed
> > >> removals are of classes shaded from the commons-weaver-processor
> > >> artifact; I have verified that all the classes named remain in the jar
> > >> so I have no idea why the report would generate false positives.
> > >>
> > >> With that information in hand, where do you now stand on this, Gary?
> > > This needs to be explained clearly in the release notes. Like Sebb
> said,
> > > there might be other places to document this as well.
> >
> > I don't see the site bundled with the release, unless I am missing
> > it somewhere.  We release software, not websites.  I see no reason
> > to clutter the release notes about false positives in maven reports
> > not included with the release.  I would say fix whatever it is
> > before republishing the site and move on.
> >
> > Phil
> > >
> > > Gary
> > >
> > >>
> > >> Matt
> > >>
> > >>> Gary
> > >>>
> > >>>
> >  Gary
> > 
> >  On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
> > > wrote:
> > > I would like to release the [weaver] component.
> > >
> > > Apache Commons Weaver 1.2 RC2 is available for review at:
> > >   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).
> > >
> > > Maven artifacts are at:
> > >
> > >
> > >
> https://repository.apache.org/content/repositories/orgapachecommons-1141
> > > .
> > >
> > > Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
> > >
> > > The Subversion tag is:
> > >
> > http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
> > > (r1726007
> > > <
> > >
> >
> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/(r1726007
> > > ).
> > >
> > > Site (note some links may be broken; this will be fixed when the
> site
> > > is deployed):
> > >
> > http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
> > >
> > > RAT Report:
> > >
> > >
> > >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
> > > Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):
> > >
> > >
> > >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
> > >
> > >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
> > >
> > >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
> > >
> > >
> >
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html
> > 

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Phil Steitz]

On 1/25/16 3:57 PM, Gary Gregory wrote:
> But the binaries are not BC. Even if that was a silly mistake, the release
> notes must note the break in BC.

I may have misunderstood what Matt said, but IIUC there is no actual
BC break.  Could any applications break as a result of what Clirr is
reporting?

Phil
>
> Gary
>
> On Mon, Jan 25, 2016 at 2:24 PM, Romain Manni-Bucau 
> wrote:
>
>> +1, weaver is for now mainly an internal for other asf projects - which are
>> BTW blocked by this vote - and the binaries are fine. The site can be fixed
>> anyway when pushed to no reason to hold this release.
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Github <
>> https://github.com/rmannibucau> |
>> LinkedIn  | Tomitriber
>> 
>>
>> 2016-01-25 23:19 GMT+01:00 Phil Steitz :
>>
>>> On 1/25/16 1:30 PM, Gary Gregory wrote:
 On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson 
>> wrote:
> On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory >>> wrote:
>> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory <
>> garydgreg...@gmail.com>
>> wrote:
>>
>>> Antlib's Clirr report has a lot of errors:
>>>
>> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
>>> This is not documented in the release notes.
>>>
>> I am not -1'ing this but it needs an explanation.
> Thanks for catching this. However, I am at a loss except to say that,
> largely, these results are incorrect. The various classes belonging to
> the org.apache.tools.* namespace  are Ant classes that were
> accidentally shaded in with the 1.1 release (Ant artifacts had to be
> promoted to compile scope so that clirr could even run), so their
> removal was deliberate--I'm sure I don't need to explain why our
> Antlib shouldn't bundle Ant's own classes. Several more claimed
> removals are of classes that were shaded in from commons-lang3 and
> Geronimo's xbean-finder libraries. I expect that these are incorrect
> anyway, but as they don't truly constitute part of the public API of
> the Antlib I would argue that they are immaterial here as long as the
> integration tests succeed, which they do. The remaining claimed
> removals are of classes shaded from the commons-weaver-processor
> artifact; I have verified that all the classes named remain in the jar
> so I have no idea why the report would generate false positives.
>
> With that information in hand, where do you now stand on this, Gary?
 This needs to be explained clearly in the release notes. Like Sebb
>> said,
 there might be other places to document this as well.
>>> I don't see the site bundled with the release, unless I am missing
>>> it somewhere.  We release software, not websites.  I see no reason
>>> to clutter the release notes about false positives in maven reports
>>> not included with the release.  I would say fix whatever it is
>>> before republishing the site and move on.
>>>
>>> Phil
 Gary

> Matt
>
>> Gary
>>
>>
>>> Gary
>>>
>>> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
 wrote:
 I would like to release the [weaver] component.

 Apache Commons Weaver 1.2 RC2 is available for review at:
   https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).

 Maven artifacts are at:


>> https://repository.apache.org/content/repositories/orgapachecommons-1141
 .

 Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.

 The Subversion tag is:

>>> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
 (r1726007
 <
>> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/(r1726007
 ).

 Site (note some links may be broken; this will be fixed when the
>> site
 is deployed):

>>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
 RAT Report:


>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
 Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):


>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html
>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html
>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normal

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Gary Gregory]

Did I misread that the 1.1 jar included shaded code from other jars?

Gary

On Mon, Jan 25, 2016 at 3:02 PM, Phil Steitz  wrote:

> On 1/25/16 3:57 PM, Gary Gregory wrote:
> > But the binaries are not BC. Even if that was a silly mistake, the
> release
> > notes must note the break in BC.
>
> I may have misunderstood what Matt said, but IIUC there is no actual
> BC break.  Could any applications break as a result of what Clirr is
> reporting?
>
> Phil
> >
> > Gary
> >
> > On Mon, Jan 25, 2016 at 2:24 PM, Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> >> +1, weaver is for now mainly an internal for other asf projects - which
> are
> >> BTW blocked by this vote - and the binaries are fine. The site can be
> fixed
> >> anyway when pushed to no reason to hold this release.
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Github <
> >> https://github.com/rmannibucau> |
> >> LinkedIn  | Tomitriber
> >> 
> >>
> >> 2016-01-25 23:19 GMT+01:00 Phil Steitz :
> >>
> >>> On 1/25/16 1:30 PM, Gary Gregory wrote:
>  On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson 
> >> wrote:
> > On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory <
> garydgreg...@gmail.com
>  wrote:
> >> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory <
> >> garydgreg...@gmail.com>
> >> wrote:
> >>
> >>> Antlib's Clirr report has a lot of errors:
> >>>
> >>
> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
> >>> This is not documented in the release notes.
> >>>
> >> I am not -1'ing this but it needs an explanation.
> > Thanks for catching this. However, I am at a loss except to say that,
> > largely, these results are incorrect. The various classes belonging
> to
> > the org.apache.tools.* namespace  are Ant classes that were
> > accidentally shaded in with the 1.1 release (Ant artifacts had to be
> > promoted to compile scope so that clirr could even run), so their
> > removal was deliberate--I'm sure I don't need to explain why our
> > Antlib shouldn't bundle Ant's own classes. Several more claimed
> > removals are of classes that were shaded in from commons-lang3 and
> > Geronimo's xbean-finder libraries. I expect that these are incorrect
> > anyway, but as they don't truly constitute part of the public API of
> > the Antlib I would argue that they are immaterial here as long as the
> > integration tests succeed, which they do. The remaining claimed
> > removals are of classes shaded from the commons-weaver-processor
> > artifact; I have verified that all the classes named remain in the
> jar
> > so I have no idea why the report would generate false positives.
> >
> > With that information in hand, where do you now stand on this, Gary?
>  This needs to be explained clearly in the release notes. Like Sebb
> >> said,
>  there might be other places to document this as well.
> >>> I don't see the site bundled with the release, unless I am missing
> >>> it somewhere.  We release software, not websites.  I see no reason
> >>> to clutter the release notes about false positives in maven reports
> >>> not included with the release.  I would say fix whatever it is
> >>> before republishing the site and move on.
> >>>
> >>> Phil
>  Gary
> 
> > Matt
> >
> >> Gary
> >>
> >>
> >>> Gary
> >>>
> >>> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
>  wrote:
>  I would like to release the [weaver] component.
> 
>  Apache Commons Weaver 1.2 RC2 is available for review at:
>    https://dist.apache.org/repos/dist/dev/commons/weaver/
> (r11994).
> 
>  Maven artifacts are at:
> 
> 
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1141
>  .
> 
>  Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.
> 
>  The Subversion tag is:
> 
> >>> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
>  (r1726007
>  <
> >>
> http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/(r1726007
>  ).
> 
>  Site (note some links may be broken; this will be fixed when the
> >> site
>  is deployed):
> 
> >>> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html
>  RAT Report:
> 
> 
> >>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html
>  Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):
> 
> 
> >>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html
> >>
> http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Matt Benson]

In practice it is most likely that a user of the 1.1 version of the
Antlib (firstly, doesn't exist, but if they did) would see no effect
because Ant's own classes are loaded in the parent CL of the Antlib's
CL, therefore the Ant classes, correctly, would not be used. While the
jar is technically not BC, there was never any intent for those
classes to be included (this only happened because the clirr report
wasn't smart enough to handle provided dependencies and therefore
couldn't be run to compare 1.1 to 1.0). The only way there could be a
problem is if the user ran the entire Ant process from the 1.1
cw-antlib jar, which would take some doing, and which certainly should
not IMO be considered a supported use case. And since the release
process is so onerous, I don't think we really have to worry about any
newer Commons component picking up enough traction for any changes to
affect any users of any type, ever. :P However, since releases cannot
be vetoed and Phil and Romain have made viable suggestions as to how
to handle this, my inclination is to conclude this vote as having
passed.

Matt

On Mon, Jan 25, 2016 at 5:08 PM, Gary Gregory  wrote:
> Did I misread that the 1.1 jar included shaded code from other jars?
>
> Gary
>
> On Mon, Jan 25, 2016 at 3:02 PM, Phil Steitz  wrote:
>
>> On 1/25/16 3:57 PM, Gary Gregory wrote:
>> > But the binaries are not BC. Even if that was a silly mistake, the
>> release
>> > notes must note the break in BC.
>>
>> I may have misunderstood what Matt said, but IIUC there is no actual
>> BC break.  Could any applications break as a result of what Clirr is
>> reporting?
>>
>> Phil
>> >
>> > Gary
>> >
>> > On Mon, Jan 25, 2016 at 2:24 PM, Romain Manni-Bucau <
>> rmannibu...@gmail.com>
>> > wrote:
>> >
>> >> +1, weaver is for now mainly an internal for other asf projects - which
>> are
>> >> BTW blocked by this vote - and the binaries are fine. The site can be
>> fixed
>> >> anyway when pushed to no reason to hold this release.
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> @rmannibucau  |  Blog
>> >>  | Github <
>> >> https://github.com/rmannibucau> |
>> >> LinkedIn  | Tomitriber
>> >> 
>> >>
>> >> 2016-01-25 23:19 GMT+01:00 Phil Steitz :
>> >>
>> >>> On 1/25/16 1:30 PM, Gary Gregory wrote:
>>  On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson 
>> >> wrote:
>> > On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory <
>> garydgreg...@gmail.com
>>  wrote:
>> >> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory <
>> >> garydgreg...@gmail.com>
>> >> wrote:
>> >>
>> >>> Antlib's Clirr report has a lot of errors:
>> >>>
>> >>
>> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
>> >>> This is not documented in the release notes.
>> >>>
>> >> I am not -1'ing this but it needs an explanation.
>> > Thanks for catching this. However, I am at a loss except to say that,
>> > largely, these results are incorrect. The various classes belonging
>> to
>> > the org.apache.tools.* namespace  are Ant classes that were
>> > accidentally shaded in with the 1.1 release (Ant artifacts had to be
>> > promoted to compile scope so that clirr could even run), so their
>> > removal was deliberate--I'm sure I don't need to explain why our
>> > Antlib shouldn't bundle Ant's own classes. Several more claimed
>> > removals are of classes that were shaded in from commons-lang3 and
>> > Geronimo's xbean-finder libraries. I expect that these are incorrect
>> > anyway, but as they don't truly constitute part of the public API of
>> > the Antlib I would argue that they are immaterial here as long as the
>> > integration tests succeed, which they do. The remaining claimed
>> > removals are of classes shaded from the commons-weaver-processor
>> > artifact; I have verified that all the classes named remain in the
>> jar
>> > so I have no idea why the report would generate false positives.
>> >
>> > With that information in hand, where do you now stand on this, Gary?
>>  This needs to be explained clearly in the release notes. Like Sebb
>> >> said,
>>  there might be other places to document this as well.
>> >>> I don't see the site bundled with the release, unless I am missing
>> >>> it somewhere.  We release software, not websites.  I see no reason
>> >>> to clutter the release notes about false positives in maven reports
>> >>> not included with the release.  I would say fix whatever it is
>> >>> before republishing the site and move on.
>> >>>
>> >>> Phil
>>  Gary
>> 
>> > Matt
>> >
>> >> Gary
>> >>
>> >>
>> >>> Gary
>> >>>
>> >>> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson 
>>  wrote:
>>  I would like to release the [weaver] component.
>> 
>>  Apach

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[Gary Gregory]

On Mon, Jan 25, 2016 at 3:37 PM, Matt Benson  wrote:

> In practice it is most likely that a user of the 1.1 version of the
> Antlib (firstly, doesn't exist, but if they did) would see no effect
> because Ant's own classes are loaded in the parent CL of the Antlib's
> CL, therefore the Ant classes, correctly, would not be used. While the
> jar is technically not BC, there was never any intent for those
> classes to be included (this only happened because the clirr report
> wasn't smart enough to handle provided dependencies and therefore
> couldn't be run to compare 1.1 to 1.0). The only way there could be a
> problem is if the user ran the entire Ant process from the 1.1
> cw-antlib jar, which would take some doing, and which certainly should
> not IMO be considered a supported use case. And since the release
> process is so onerous, I don't think we really have to worry about any
> newer Commons component picking up enough traction for any changes to
> affect any users of any type, ever. :P However, since releases cannot
> be vetoed and Phil and Romain have made viable suggestions as to how
> to handle this, my inclination is to conclude this vote as having
> passed.
>

This is all great information. If I were RM, I would update the release
notes (and the site where appropriate) and re-spin the RC.

Gary


>
> Matt
>
> On Mon, Jan 25, 2016 at 5:08 PM, Gary Gregory 
> wrote:
> > Did I misread that the 1.1 jar included shaded code from other jars?
> >
> > Gary
> >
> > On Mon, Jan 25, 2016 at 3:02 PM, Phil Steitz 
> wrote:
> >
> >> On 1/25/16 3:57 PM, Gary Gregory wrote:
> >> > But the binaries are not BC. Even if that was a silly mistake, the
> >> release
> >> > notes must note the break in BC.
> >>
> >> I may have misunderstood what Matt said, but IIUC there is no actual
> >> BC break.  Could any applications break as a result of what Clirr is
> >> reporting?
> >>
> >> Phil
> >> >
> >> > Gary
> >> >
> >> > On Mon, Jan 25, 2016 at 2:24 PM, Romain Manni-Bucau <
> >> rmannibu...@gmail.com>
> >> > wrote:
> >> >
> >> >> +1, weaver is for now mainly an internal for other asf projects -
> which
> >> are
> >> >> BTW blocked by this vote - and the binaries are fine. The site can be
> >> fixed
> >> >> anyway when pushed to no reason to hold this release.
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau  |  Blog
> >> >>  | Github <
> >> >> https://github.com/rmannibucau> |
> >> >> LinkedIn  | Tomitriber
> >> >> 
> >> >>
> >> >> 2016-01-25 23:19 GMT+01:00 Phil Steitz :
> >> >>
> >> >>> On 1/25/16 1:30 PM, Gary Gregory wrote:
> >>  On Mon, Jan 25, 2016 at 7:47 AM, Matt Benson 
> >> >> wrote:
> >> > On Sun, Jan 24, 2016 at 9:37 PM, Gary Gregory <
> >> garydgreg...@gmail.com
> >>  wrote:
> >> >> On Sun, Jan 24, 2016 at 7:36 PM, Gary Gregory <
> >> >> garydgreg...@gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Antlib's Clirr report has a lot of errors:
> >> >>>
> >> >>
> >>
> https://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/clirr-report.html
> >> >>> This is not documented in the release notes.
> >> >>>
> >> >> I am not -1'ing this but it needs an explanation.
> >> > Thanks for catching this. However, I am at a loss except to say
> that,
> >> > largely, these results are incorrect. The various classes
> belonging
> >> to
> >> > the org.apache.tools.* namespace  are Ant classes that were
> >> > accidentally shaded in with the 1.1 release (Ant artifacts had to
> be
> >> > promoted to compile scope so that clirr could even run), so their
> >> > removal was deliberate--I'm sure I don't need to explain why our
> >> > Antlib shouldn't bundle Ant's own classes. Several more claimed
> >> > removals are of classes that were shaded in from commons-lang3 and
> >> > Geronimo's xbean-finder libraries. I expect that these are
> incorrect
> >> > anyway, but as they don't truly constitute part of the public API
> of
> >> > the Antlib I would argue that they are immaterial here as long as
> the
> >> > integration tests succeed, which they do. The remaining claimed
> >> > removals are of classes shaded from the commons-weaver-processor
> >> > artifact; I have verified that all the classes named remain in the
> >> jar
> >> > so I have no idea why the report would generate false positives.
> >> >
> >> > With that information in hand, where do you now stand on this,
> Gary?
> >>  This needs to be explained clearly in the release notes. Like Sebb
> >> >> said,
> >>  there might be other places to document this as well.
> >> >>> I don't see the site bundled with the release, unless I am missing
> >> >>> it somewhere.  We release software, not websites.  I see no reason
> >> >>> to clutter the release notes about false positives in 

[Math] JDK "Random" and "BitsStreamGenerator"

[Gilles]

Hi.

In CM, a base class "BitsStreamGenerator" contains methods for
generating various primitive types from a bit source (to be
implemented by subclasses by overriding the "next(int bits)"
method).
For example, to get a random "long" value, the following code
is called:
---CUT---
public long nextLong() {
final long high  = ((long) next(32)) << 32;
final long  low  = (next(32)) & 0xL;
return high | low;
}
---CUT---

If the bit source were provided by the JDK's "Random" class,
is it assumed that the "long" value generated by the above
code will always be equal to the "long" value generated by
the call to JDK's "Random" class?

In other words, how "standard" are the default implementations
of the methods defined in "BitsStreamGenerator"?

And what are the compatibility requirements with respect to
reproducibility of the sequences (between releases of the
library)?


Regards,
Gilles


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

Re: [math] Name of the new TLP

[Ole Ersoy]

Also if each module is very simple and isolated alphas, betas, etc. matter less 
(If at all).  Most devs releasing to npm rely on semver only.

Cheers,
Ole

On 01/25/2016 02:27 PM, Gary Gregory wrote:

On Jan 25, 2016 10:11 AM, "Emmanuel Bourg"  wrote:

Le 25/01/2016 18:52, Gilles a écrit :


AFAICT, the real issue is one of policy: Commons is supposed to be

stable,

stable, stable and stable (IIUC).

And CM is far from being mature as a programming project, when

considering

design and scope, and not only the quality of its results and

performance

(which are both good in many cases).
So stability (as in using JDK 5 only) is not a good perspective (surely

not

developers and probably not for users either IMO).

If this does not change, what's the point indeed?

I hope that a motivation behind the TLP isn't to break the compatibility
on every release, otherwise this will quickly turn into a nightmare for
the users. Bouncycastle plays this game and it isn't really fun to follow

:(

WRT compatibility, the only thing that matters is not creating jar hell for
users. You can break compatibility if you change package and maven
coordinates. It's up to the project to create enough alphas and betas to
get to a stable public API before a release. That's just basic project
management IMO. Anything less will leave a lot users unhappy.

Gary


Emmanuel Bourg


-
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] Name of the new TLP

[Gary Gregory]

If you decide to break up math into modules, I encourage you to also
provide an all-in-one jar.

Gary
On Jan 25, 2016 4:22 PM, "Ole Ersoy"  wrote:

> Also if each module is very simple and isolated alphas, betas, etc. matter
> less (If at all).  Most devs releasing to npm rely on semver only.
>
> Cheers,
> Ole
>
> On 01/25/2016 02:27 PM, Gary Gregory wrote:
>
>> On Jan 25, 2016 10:11 AM, "Emmanuel Bourg"  wrote:
>>
>>> Le 25/01/2016 18:52, Gilles a écrit :
>>>
>>> AFAICT, the real issue is one of policy: Commons is supposed to be

>>> stable,
>>
>>> stable, stable and stable (IIUC).

 And CM is far from being mature as a programming project, when

>>> considering
>>
>>> design and scope, and not only the quality of its results and

>>> performance
>>
>>> (which are both good in many cases).
 So stability (as in using JDK 5 only) is not a good perspective (surely

>>> not
>>
>>> developers and probably not for users either IMO).

 If this does not change, what's the point indeed?

>>> I hope that a motivation behind the TLP isn't to break the compatibility
>>> on every release, otherwise this will quickly turn into a nightmare for
>>> the users. Bouncycastle plays this game and it isn't really fun to follow
>>>
>> :(
>>
>> WRT compatibility, the only thing that matters is not creating jar hell
>> for
>> users. You can break compatibility if you change package and maven
>> coordinates. It's up to the project to create enough alphas and betas to
>> get to a stable public API before a release. That's just basic project
>> management IMO. Anything less will leave a lot users unhappy.
>>
>> Gary
>>
>> Emmanuel Bourg
>>>
>>>
>>> -
>>> 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] Name of the new TLP

[Ole Ersoy]

It's very easy to create one, but I think we should focus on small high quality 
simple to use modules and let third parties provide assemblies.  I think most 
of us will feel better about providing solutions that explicitly declare the 
modules used.  This gives maintainers a more precise target.  Keeping an uber 
jar also gets more and more difficult to maintain with each new module release. 
For example with superfly-css I change modules all the time and I'm planning on 
adding a lot of new ones.  If I also add a uber module I have to maintain that 
as well.  That's not my main concern though. I think an uber jar / module can 
easily cause headaches.  It's the opposite of allowing JDK 9 or osgi manage 
dependencies and corresponding contexts.  The less indirection the better.

Cheers,
Ole


On 01/25/2016 06:38 PM, Gary Gregory wrote:

If you decide to break up math into modules, I encourage you to also
provide an all-in-one jar.

Gary
On Jan 25, 2016 4:22 PM, "Ole Ersoy"  wrote:


Also if each module is very simple and isolated alphas, betas, etc. matter
less (If at all).  Most devs releasing to npm rely on semver only.

Cheers,
Ole

On 01/25/2016 02:27 PM, Gary Gregory wrote:


On Jan 25, 2016 10:11 AM, "Emmanuel Bourg"  wrote:


Le 25/01/2016 18:52, Gilles a écrit :

AFAICT, the real issue is one of policy: Commons is supposed to be
stable,
stable, stable and stable (IIUC).

And CM is far from being mature as a programming project, when


considering
design and scope, and not only the quality of its results and
performance
(which are both good in many cases).

So stability (as in using JDK 5 only) is not a good perspective (surely


not
developers and probably not for users either IMO).

If this does not change, what's the point indeed?


I hope that a motivation behind the TLP isn't to break the compatibility
on every release, otherwise this will quickly turn into a nightmare for
the users. Bouncycastle plays this game and it isn't really fun to follow


:(

WRT compatibility, the only thing that matters is not creating jar hell
for
users. You can break compatibility if you change package and maven
coordinates. It's up to the project to create enough alphas and betas to
get to a stable public API before a release. That's just basic project
management IMO. Anything less will leave a lot users unhappy.

Gary

Emmanuel Bourg


-
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





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

Re: [math] Name of the new TLP

[Henri Yandell]

Any reason why you're not going with Apache Math - math.apache.org?

No one is going to wince if you have other language implementations in the
same project, and if it needs to break up over time because there is Apache
Math GroupTheory, Apache Math Fluid Dynamics etc etc; then more power to
y'all.

Hen


On Sun, Jan 24, 2016 at 1:08 PM, Phil Steitz  wrote:

> We need to agree on a name.  My own preference is for a boring,
> descriptive name, but I am manifestly not a marketing guy, so won't
> be offended if others want to be more creative.
>
> My suggestion is
>
> MathComponents
>
> Hearkens back to HttpComponents, which has worked pretty well.
>
> Phil
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [math] Name of the new TLP

[Gary Gregory]

On Mon, Jan 25, 2016 at 9:21 PM, Henri Yandell  wrote:

> Any reason why you're not going with Apache Math - math.apache.org?
>

+1!

Gary

>
> No one is going to wince if you have other language implementations in the
> same project, and if it needs to break up over time because there is Apache
> Math GroupTheory, Apache Math Fluid Dynamics etc etc; then more power to
> y'all.
>
> Hen
>
>
> On Sun, Jan 24, 2016 at 1:08 PM, Phil Steitz 
> wrote:
>
> > We need to agree on a name.  My own preference is for a boring,
> > descriptive name, but I am manifestly not a marketing guy, so won't
> > be offended if others want to be more creative.
> >
> > My suggestion is
> >
> > MathComponents
> >
> > Hearkens back to HttpComponents, which has worked pretty well.
> >
> > Phil
> >
> > -
> > 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] Name of the new TLP

[Chas Honton]

Using the list from https://en.m.wikipedia.org/wiki/Areas_of_mathematics, the 
current commons math appears to be a sub-set of numerical analysis algorithms.  
Is this correct?  Will this continue be the focus of a math tlp? 

Unfortunately, Apache Numerical Analysis does not trip off the tongue. 

Chas

> On Jan 25, 2016, at 9:21 PM, Henri Yandell  wrote:
> 
> Any reason why you're not going with Apache Math - math.apache.org?
> 
> No one is going to wince if you have other language implementations in the
> same project, and if it needs to break up over time because there is Apache
> Math GroupTheory, Apache Math Fluid Dynamics etc etc; then more power to
> y'all.
> 
> Hen
> 
> 
>> On Sun, Jan 24, 2016 at 1:08 PM, Phil Steitz  wrote:
>> 
>> We need to agree on a name.  My own preference is for a boring,
>> descriptive name, but I am manifestly not a marketing guy, so won't
>> be offended if others want to be more creative.
>> 
>> My suggestion is
>> 
>> MathComponents
>> 
>> Hearkens back to HttpComponents, which has worked pretty well.
>> 
>> Phil
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
>> 

Re: [lang] release 3.5

[Loic Guibert]

I'm currently pretty busy at work, i don't have much time to work on
Commons-Lang too.
Sorry.
Regards,

Loic Guibert
PGP : 0x65EB4F33

Le 18/01/2016 15:52, Benedikt Ritter a écrit :
> Hi,
>
> 2016-01-16 6:41 GMT+01:00 Loic Guibert :
>
>> Hi, great !
>>
>> There are some ticket/PR open and handled by committers.
>> Perhaps we can resolve those can be done quickly before releasing ?
>>
> I currently don't have the time to work on [lang]. Please feel free to fix
> any issues I have assigned to myself.
>
> Regards,
> Benedikt
>
>
>> AFAIAC, i've this one on which we have to discuss about some
>> implementation points :
>> https://github.com/apache/commons-lang/pull/75
>> https://issues.apache.org/jira/browse/LANG-1124
>>
>> Regards,
>>
>> Loic Guibert
>> PGP : 0x65EB4F33
>>
>> Le 16/01/2016 04:21, Gary Gregory a écrit :
>>> Shall we have a go at releasing 3.5? There is quite a change set to push
>>> out :-)
>>>
>>> Gary
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>


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

Re: [math] Volunteer for the new TLP PMC

[William Barker]

On Monday, January 25, 2016, Gilles  wrote:

> On Sun, 24 Jan 2016 13:54:51 -0700, Phil Steitz wrote:
>
>> Please respond to this thread if you are a Commons Committer
>> interested in joining the PMC for the new TLP based on [math].
>>
>> Thanks!
>>
>> Phil
>>
>
> I'm interested in as much as I'm being curious to see if it
> will change anything! :-}
>
> There were a few "negative" arguments, that is was better to
> stop "annoying" the other Commons projects. [To which some
> responded that they'd prefer the status quo.]
>
> The rationale concerning the size, scope, and management of
> Commons Math, (and how different it was from all the other
> Commons components), I had brought up on several occasions in
> the past.
>
> What has changed?
>
> What are the "positive" arguments?
>
> To be crystal-clear, if the new PMC is composed of the same
> people who are the regular contributors to the Commons Math
> project, i.e. with the same confronting blocks, I don't see
> from where the incentive towards a different development policy
> will come.
>
> Various points have been brought up in (too often heated)
> discussions (JDK version, development and release policies
> such as compatibility, refactoring, multi-threading, exception
> handling, etc.).
>
> I think that the volunteers for the new PMC should list their
> opinion on fundamental issues that obviously define a "vision"
> of the project.


Until there is a new PMC there isn't  anyone to vote on campaign platforms
:). That is a discussion for the new PMC

Lacking clear goals[1] is not going to help in any way.
> At this point, we can expect administrative chores.
> Wouldn't it be a pity to do all that work just to get a new
> name?
>
>
> Regards,
> Gilles
>
> [1] There can be seemingly contradictory goals as long as they
> are acknowledged and do not hamper each other (like I've
> expressed in other posts) and sufficient resources exist to
> handle them.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>